Re: [Intel-gfx] [PATCH] drm/i915: HDMI audio gets the TMDS clock by crtc_clock

[Yang, Libin]

This patch is based on drm/i915: set proper N/M in modeset

Regards,
Libin


> -Original Message-
> From: libin.y...@linux.intel.com [mailto:libin.y...@linux.intel.com]
> Sent: Tuesday, August 2, 2016 2:18 PM
> To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com;
> ville.syrj...@linux.intel.com; Vetter, Daniel ;
> ti...@suse.de
> Cc: Yang, Libin ; Libin Yang
> 
> Subject: [PATCH] drm/i915: HDMI audio gets the TMDS clock by crtc_clock
> 
> From: Libin Yang 
> 
> HDMI audio should use crtc_clock to get the TMDS clock.
> 
> Besides, this patch renames mode to adjusted_mode to unify the name.
> 
> Signed-off-by: Libin Yang 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index de55ecf..a291a31 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -146,7 +146,7 @@ static int audio_config_get_n(struct intel_crtc *crtc,
>   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) {
>   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
>   if ((rate == aud_ncts[i].sample_rate) &&
> - (adjusted_mode->clock == aud_ncts[i].clock)) {
> + (adjusted_mode->crtc_clock == aud_ncts[i].clock)) {
>   return aud_ncts[i].n;
>   }
>   }
> @@ -215,8 +215,8 @@ static uint32_t audio_config_setup_m_reg(struct
> intel_crtc *crtc,  static bool audio_rate_need_prog(struct intel_crtc *crtc,
>const struct drm_display_mode
> *adjusted_mode)  {
> - if (((adjusted_mode->clock == TMDS_297M) ||
> -  (adjusted_mode->clock == TMDS_296M)) &&
> + if (((adjusted_mode->crtc_clock == TMDS_297M) ||
> +  (adjusted_mode->crtc_clock == TMDS_296M)) &&
>   intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI))
>   return true;
>   else if (((crtc->config->port_clock == LC_540M) || @@ -711,7 +711,7
> @@ static int i915_audio_component_sync_audio_rate(struct device *dev,
>   struct drm_i915_private *dev_priv = dev_to_i915(dev);
>   struct intel_encoder *intel_encoder;
>   struct intel_crtc *crtc;
> - struct drm_display_mode *mode;
> + struct drm_display_mode *adjusted_mode;
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   enum pipe pipe = INVALID_PIPE;
>   u32 tmp, m;
> @@ -747,20 +747,20 @@ static int
> i915_audio_component_sync_audio_rate(struct device *dev,
> 
>   DRM_DEBUG_KMS("pipe %c connects port %c\n",
> pipe_name(pipe), port_name(port));
> - mode = &crtc->config->base.adjusted_mode;
> + adjusted_mode = &crtc->config->base.adjusted_mode;
> 
>   /* port must be valid now, otherwise the pipe will be invalid */
>   acomp->aud_sample_rate[port] = rate;
> 
>   /* 2. check whether to set the N/CTS/M manually or not */
> - if (!audio_rate_need_prog(crtc, mode)) {
> + if (!audio_rate_need_prog(crtc, adjusted_mode)) {
>   tmp = I915_READ(HSW_AUD_CFG(pipe));
>   tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
>   I915_WRITE(HSW_AUD_CFG(pipe), tmp);
>   goto unlock;
>   }
> 
> - n = audio_config_get_n(crtc, mode, rate);
> + n = audio_config_get_n(crtc, adjusted_mode, rate);
>   if (n == 0) {
>   DRM_DEBUG_KMS("Using automatic mode for N value on
> port %c\n",
> port_name(port));
> --
> 1.9.1

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

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences

[Jani Nikula]

On Mon, 01 Aug 2016, Dave Gordon  wrote:
> On 01/08/16 14:54, Jani Nikula wrote:
>> On Fri, 22 Jul 2016, Dave Gordon  wrote:
>>> -   } else if (i915.enable_guc_submission > 1) {
>>> +   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {
>>
>> I like the patches in general, but now these >= and <= seem rather out
>> of place. How about using == and != exclusively?
>>
>> BR,
>> Jani.
>
> That would leave us with undefined behaviour for values outside the 
> recognised range. This way it clips out-of-range values to the nearest 
> extremum. Of course we could make it fail completely for invalid values, 
> but that's just really annoying for the developer or admin who's 
> mistyped -1 as -2 or forgotten what the maximum supported value is in 
> this release. Alternatively we could convert all out-of-range values to 
> "system default" i.e. ignored, which might still be annoying but not 
> quite as much.

I'm not a huge fan of making assumptions about what the user possibly
meant when giving incorrect input, "as a convenience". It teaches the
user to be sloppy about it, and might lead to super annoying surprises
when we actually start using those values for something else.

> Any other suggestions for how to handle out-of-range values?
>
> But if we were changing the policy shouldn't that be a separate patch? 
> This patch is supposed to change only the way the code is written, with 
> no effect to existing behaviour!

Oh, completely agreed here, while I didn't spell this out in my first
reply. This shouldn't block the patch.

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] Disable power management on i915

[Joonas Lahtinen]

On ma, 2016-08-01 at 20:08 +, Sanchez, AdolfoX wrote:
> Hello.
>  
> I would like to know what is the best way to disable power management
> on the GPU unit, the purpose is to avoid GPU power transitions to
> avoid voltage swings.

i915.enable_rc6=0 would be a start. Do you also want to fix the GPU
frequency?

May I also ask why you want to do such thing?

Regards, Joonas

>  
> Additional information:
> Platform: Bay Trail J1900
> O.S: Linux Kernel 4.4
>  
> Any help would be appreciated.
>  
> Best Regards,
> Adolfo Sanchez.
>  
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Consistent struct device naming

[Joonas Lahtinen]

On ma, 2016-08-01 at 19:57 +0100, Chris Wilson wrote:
> On Mon, Aug 01, 2016 at 06:38:53PM +0300, David Weinehall wrote:
> > 
> > We currently have a mix of struct device *device, struct device *kdev,
> > and struct device *dev (the latter forcing us to refer to
> > struct drm_device as something else than the normal dev).
> > 
> > To simplify things, always use kdev when referring to struct device.
> > 
> > Signed-off-by: David Weinehall 
> kdev may be confused with kdev_t, but seems reasonable due to kobj.
> 
> This patch is an improvement, so
> Reviewed-by: Chris Wilson 
> 
> but I was wondering if
> 
> struct device *dev;
> struct drm_device *drm;
> struct i915_device *i915;
> 

I'd vote for this scheme.

Regards, Joonas

> (struct i915_device is move apt now than drm_i915_private due to the
> subclassing)
> 
> made more sense as a longterm goal?
> -Chris
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Consistent drm_minor use

[Joonas Lahtinen]

On ma, 2016-08-01 at 20:01 +0100, Chris Wilson wrote:
> On Mon, Aug 01, 2016 at 06:38:54PM +0300, David Weinehall wrote:
> > 
> > Use consistent naming for drm_minor, and always use kdev_to_drm_minor()
> > to convert kdev to drm_minor.
> > 
> > Signed-off-by: David Weinehall 
> I would have gone with struct drm_minor *minor, since there is no
> confusion here (and dminor is a note ;)
> 

I think depending on if we end up with kdev or dev, then match with
dminor/minor.

Regards, Joonas

-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Antoine, Peter]

This patch has nothing to do with HuC. It is changing the GuC code to allow for 
generic usage.
But, I will change the "GuC" in the messages for "uC".

I'll let you  add  the patch yourself as you seem to have other 
renames/refactors on the mailing list.

Peter.

-Original Message-
From: Gordon, David S 
Sent: Friday, July 29, 2016 12:19 PM
To: Antoine, Peter ; intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper 
functions general

On 06/07/16 15:24, Peter Antoine wrote:
> Rename some of the GuC fw loading code to make them more general. We 
> will utilise them for HuC loading as well.
>  s/intel_guc_fw/intel_uc_fw/g
>  s/GUC_FIRMWARE/UC_FIRMWARE/g
>
> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, 
> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for 
> same purpose.
>
> v2: rebased on top of nightly.
> reapplied the search/replace as upstream code as changed.
> v3: rebased again on drm-nightly.
>
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
>  drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
>  drivers/gpu/drm/i915/intel_guc.h   |  39 
>  drivers/gpu/drm/i915/intel_guc_loader.c| 146 
> ++---
>  4 files changed, 101 insertions(+), 100 deletions(-)

As of yesterday, the odd-numbered patches 1 & 3 no longer apply cleanly and 
will need rebasing (again).

Also (as of last week's Tech Forum) any series containing more than a single 
patch should preferably have a cover letter that at least gives a summary of 
the patchset as a whole.

However the main problem with this patch it not what it changes, as what it 
fails to change. As I previously suggested (and provided code for) you need to 
change all the messages so they don't say "GuC" when we're actually dealing 
with the HuC. Updated fixup-patch attached ...

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

[Intel-gfx] [PATCH] drm/i915: fix WaInsertDummyPushConstPs

[Matthew Auld]

As pointed out by Chris Harris, we are using the wrong WA name, it
should in fact be WaToEnableHwFixForPushConstHWBug, also it should be
applied from C0 onwards for both BXT and KBL.

Fixes: 7b9005cd45f3 ("drm/i915: Add WaInsertDummyPushConstP for bxt and kbl")

Cc: Chris Harris 
Cc: Mika Kuoppala 
Reported-by: Chris Harris 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 15acaf6..0df7381 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1173,8 +1173,8 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
I915_WRITE(GEN8_L3SQCREG1, L3_GENERAL_PRIO_CREDITS(62) |
   L3_HIGH_PRIO_CREDITS(2));
 
-   /* WaInsertDummyPushConstPs:bxt */
-   if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_B0))
+   /* WaToEnableHwFixForPushConstHWBug:bxt */
+   if (IS_BXT_REVID(dev_priv, BXT_REVID_C0, REVID_FOREVER))
WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
  GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
 
@@ -1217,8 +1217,8 @@ static int kbl_init_workarounds(struct intel_engine_cs 
*engine)
I915_WRITE(GEN8_L3SQCREG4, I915_READ(GEN8_L3SQCREG4) |
   GEN8_LQSC_RO_PERF_DIS);
 
-   /* WaInsertDummyPushConstPs:kbl */
-   if (IS_KBL_REVID(dev_priv, 0, KBL_REVID_B0))
+   /* WaToEnableHwFixForPushConstHWBug:kbl */
+   if (IS_KBL_REVID(dev_priv, KBL_REVID_C0, REVID_FOREVER))
WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
  GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Consistent struct device naming

[Jani Nikula]

On Tue, 02 Aug 2016, Joonas Lahtinen  wrote:
> On ma, 2016-08-01 at 19:57 +0100, Chris Wilson wrote:
>> On Mon, Aug 01, 2016 at 06:38:53PM +0300, David Weinehall wrote:
>> > 
>> > We currently have a mix of struct device *device, struct device *kdev,
>> > and struct device *dev (the latter forcing us to refer to
>> > struct drm_device as something else than the normal dev).
>> > 
>> > To simplify things, always use kdev when referring to struct device.
>> > 
>> > Signed-off-by: David Weinehall 
>> kdev may be confused with kdev_t, but seems reasonable due to kobj.
>> 
>> This patch is an improvement, so
>> Reviewed-by: Chris Wilson 
>> 
>> but I was wondering if
>> 
>> struct device *dev;
>> struct drm_device *drm;
>> struct i915_device *i915;
>> 
>
> I'd vote for this scheme.

In the driver,

30 out of 52 struct device * decls use "dev".

1233 out of 1251 struct drm_device * decls use "dev".

2112 out of 2154 struct drm_i915_private * decls use "dev_priv".

By all means change struct device *dev to something else, like kdev, or
whatever.

But do we really not have better things to do than come up with ways to
create tons of rename churn, increasing the cognitive burden of
developers, forcing rebases of tons of in-flight code making it harder
to get code in, creating conflicts for backporting fixes, and so on?

I'm firmly behind sticking with struct drm_i915_private *dev_priv and
struct drm_device *dev.


BR,
Jani.

>
> Regards, Joonas
>
>> (struct i915_device is move apt now than drm_i915_private due to the
>> subclassing)
>> 
>> made more sense as a longterm goal?
>> -Chris
>> 

-- 
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] ✗ Ro.CI.BAT: failure for drm/i915: fix WaInsertDummyPushConstPs

[Patchwork]

== Series Details ==

Series: drm/i915: fix WaInsertDummyPushConstPs
URL   : https://patchwork.freedesktop.org/series/10492/
State : failure

== Summary ==

Series 10492v1 drm/i915: fix WaInsertDummyPushConstPs
http://patchwork.freedesktop.org/api/1.0/series/10492/revisions/1/mbox

Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
fail   -> PASS   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (fi-hsw-i7-4770k)
fail   -> PASS   (fi-skl-i7-6700k)
pass   -> FAIL   (ro-snb-i7-2620M)
pass   -> FAIL   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-hsw-i7-4770r)
fail   -> PASS   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (ro-bdw-i7-5557U)

fi-hsw-i7-4770k  total:240  pass:218  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-qkkr  total:240  pass:182  dwarn:29  dfail:0   fail:3   skip:26 
fi-skl-i5-6260u  total:240  pass:224  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:240  pass:209  dwarn:0   dfail:0   fail:3   skip:28 
fi-snb-i7-2600   total:240  pass:198  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:4   dfail:0   fail:1   skip:16 
ro-bdw-i7-5557U  total:240  pass:223  dwarn:1   dfail:0   fail:0   skip:16 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:172  dwarn:1   dfail:0   fail:2   skip:65 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:197  dwarn:0   dfail:0   fail:2   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1664/

6f87e85 drm-intel-nightly: 2016y-08m-01d-14h-53m-17s UTC integration manifest
f78fc40 drm/i915: fix WaInsertDummyPushConstPs

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

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

[Dave Gordon]

On 01/08/16 17:32, Chris Wilson wrote:

On Mon, Aug 01, 2016 at 05:28:34PM +0300, Joonas Lahtinen wrote:

On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote:

On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote:


On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:


Space reservation is already safe with respect to the ring->size
modulus, but hardware only expects to see values in the range
0...ring->size-1 (inclusive) and so requires the modulus to prevent us
writing the value ring->size instead of 0. As this is only required for
the register itself, we can defer the modulus to the register update and
not perform it after every command packet. We keep the
intel_ring_advance() around in the code to provide demarcation for the
end-of-packet (which then can be compared against intel_ring_begin() as
the number of dwords emitted must match the reserved space).

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
 drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
 3 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bf42a66d6624..824f7efe4e64 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -373,7 +373,7 @@ static void execlists_update_context(struct 
drm_i915_gem_request *rq)
struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;

-   reg_state[CTX_RING_TAIL+1] = rq->tail;
+   reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, rq->tail);

/* True 32b PPGTT with dynamic page allocation: update PDP
 * registers and point the unallocated PDPs to scratch page.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3142085b5cc0..21d5e8209400 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
drm_i915_gem_request *request)
 {
struct drm_i915_private *dev_priv = request->i915;

-   I915_WRITE_TAIL(request->engine, request->tail);
+   I915_WRITE_TAIL(request->engine,
+   intel_ring_offset(request->ring, request->tail));
 }

 static void
@@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
drm_i915_gem_request *request)
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");

/* Now that the ring is fully powered up, update the tail */
-   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), request->tail);
+   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
+ intel_ring_offset(request->ring, request->tail));
POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));

/* Let the ring send IDLE messages to the GT again,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 14d2ea36fb88..9ac96ddb01ee 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct intel_ring 
*ring, i915_reg_t reg)

 static inline void intel_ring_advance(struct intel_ring *ring)
 {
+   /* Dummy function.
+*
+* This serves as a placeholder in the code so that the reader
+* can compare against the preceding intel_ring_begin() and
+* check that the number of dwords emitted matches the space
+* reserved for the command packet (i.e. the value passed to
+* intel_ring_begin()).
+*/
+}
+
+static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
+{
/* The modulus is required so that we avoid writing
 * request->tail == ring->size, rather than the expected 0,
 * into the RING_TAIL register as that can cause a GPU hang.
-* As this is only strictly required for the request->tail,
-* and only then as we write the value into hardware, we can
-* one day remove the modulus after every command packet.
 */
-   ring->tail &= ring->size - 1;
+   return value & (ring->size - 1);
 }

The comment seems outdated-ish as it speaks of modulus which is nowhere
to be seen. I'd speak of 'masking'. With that,

The operation is a modulus. The common optimisation for moduli with
a power-of-two divisor being applied.


Yes, I'm perfectly aware of that, but as discussed in IRC, that
information would be good to be local. Modulus in this case a trick to
achieve value == ring->size ? 0 : value; Which would again be more
informative, we do not expect wrap, but we have one special value.


Ditch all the verbage, and go with the single line:
/* Don't write ring->size (equivalent to 0) as that hangs some GPUs. */
that just fits into 80cols

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences

[Dave Gordon]

On 01/08/16 19:57, Dave Gordon wrote:

On 01/08/16 14:54, Jani Nikula wrote:

On Fri, 22 Jul 2016, Dave Gordon  wrote:

The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (which could be confusing for
maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
submission options that the user can select (-1, 0, 1, 2
respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_guc_loader.c| 15 ---
 drivers/gpu/drm/i915/intel_lrc.c   |  6 +++---
 4 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 01c1c16..e564c976 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -971,7 +971,7 @@ int i915_guc_submission_init(struct
drm_i915_private *dev_priv)
 bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
 i915_guc_submission_disable(dev_priv);

-if (!i915.enable_guc_submission)
+if (i915.enable_guc_submission == GUC_SUBMISSION_DISABLED)
 return 0; /* not enabled  */

 if (guc->ctx_pool_obj)
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743..52ecbba 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,6 +90,12 @@ struct i915_guc_client {
 uint64_t submissions[I915_NUM_ENGINES];
 };

+enum {
+GUC_SUBMISSION_DEFAULT = -1,
+GUC_SUBMISSION_DISABLED = 0,
+GUC_SUBMISSION_PREFERRED,
+GUC_SUBMISSION_MANDATORY
+};
 enum intel_guc_fw_status {
 GUC_FIRMWARE_FAIL = -1,
 GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index b883efd..d8bd4cb 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -189,7 +189,7 @@ static void set_guc_init_params(struct
drm_i915_private *dev_priv)
 }

 /* If GuC submission is enabled, set up additional parameters
here */
-if (i915.enable_guc_submission) {
+if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
 u32 pgs = i915_gem_obj_ggtt_offset(dev_priv->guc.ctx_pool_obj);
 u32 ctx_in_16 = GUC_MAX_GPU_CONTEXTS / 16;

@@ -495,7 +495,7 @@ int intel_guc_setup(struct drm_device *dev)
 intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
 intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));

-if (i915.enable_guc_submission) {
+if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
 err = i915_guc_submission_enable(dev_priv);
 if (err)
 goto fail;
@@ -523,7 +523,7 @@ int intel_guc_setup(struct drm_device *dev)
  */
 if (i915.enable_guc_loading > 1) {
 ret = -EIO;
-} else if (i915.enable_guc_submission > 1) {
+} else if (i915.enable_guc_submission >=
GUC_SUBMISSION_MANDATORY) {


I like the patches in general, but now these >= and <= seem rather out
of place. How about using == and != exclusively?

BR,
Jani.


That would leave us with undefined behaviour for values outside the
recognised range. This way it clips out-of-range values to the nearest
extremum. Of course we could make it fail completely for invalid values,
but that's just really annoying for the developer or admin who's
mistyped -1 as -2 or forgotten what the maximum supported value is in
this release. Alternatively we could convert all out-of-range values to
"system default" i.e. ignored, which might still be annoying but not
quite as much.

Any other suggestions for how to handle out-of-range values?

But if we were changing the policy shouldn't that be a separate patch?
This patch is supposed to change only the way the code is written, with
no effect to existing behaviour!

.Dave.


Also, if you look ahead to the next patch, you'll see there's a big 
explanatory comment about the use of signed and ordered enums:


+/*
+ * These signed ranges represent user-requested preferences.
+ * Out-of-range values from the user will be clipped towards
+ * zero: any negative value is treated as -1, anything over 2
+ * is just 2. ANY user-supplied value also taints the kernel.
+ */
 enum {
GUC_SUBMISSION_DEFAULT = -1,
GUC_SUBMISSION_DISABLED = 0,
GUC_SUBMISSION_PREFERRED,
GUC_SUBMISSION_MANDATORY
 };
+enum {
+   FIRMWARE_LOAD_DEFAULT = -1,
+   FIRMWARE_LOAD_DISABLED = 0,
+   FIRMWARE_LOAD_PREFERRED,
+   FIRMWARE_LOAD_MANDATORY
+};
+
+/* These represent the actual firmware status  */
 enum intel_guc_fw_status {
GU

Re: [Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

[Dave Gordon]

On 21/07/16 18:10, Dave Gordon wrote:

On 21/07/16 11:38, Tvrtko Ursulin wrote:


On 20/07/16 22:07, Rodrigo Vivi wrote:

please kill this _ucode variation that is just a alias to guc
instead


Not sure, it was added with a particular goal. Cc Dave in case he wants
to comment.

Regards,
Tvrtko


The comment is already in the source code, just above the lines that
this patch changes.

.Dave.


Which is to say that,
+   having a GuC that can be used for command submission
+   having a GuC that requires firmware before use
are logically distinct properties, and are both subsets of
* having GuC hardware.

We can *imagine* products that might:

(1) have a GuC that requires firmware before use ...
(2) have a GuC with predefined but reloadable firmware ...
(3) have a GuC that contains a permanent firmware image ...
 x
(a) ... which supports command submission but not SLPC
(b) ... which supports both command submission and SLPC
(c) ... which supports SLPC but not command submission

where all combinations are logically plausible, even though we only have 
(1a) in today's devices. So we might as well make future development 
easier rather than more difficult; it is always easier to make different 
things equivalent than to separate identical things into different cases.


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

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

[Chris Wilson]

On Tue, Aug 02, 2016 at 10:42:47AM +0100, Dave Gordon wrote:
> On 01/08/16 17:32, Chris Wilson wrote:
> >On Mon, Aug 01, 2016 at 05:28:34PM +0300, Joonas Lahtinen wrote:
> >>On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote:
> >>>On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote:
> 
> On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> >
> >Space reservation is already safe with respect to the ring->size
> >modulus, but hardware only expects to see values in the range
> >0...ring->size-1 (inclusive) and so requires the modulus to prevent us
> >writing the value ring->size instead of 0. As this is only required for
> >the register itself, we can defer the modulus to the register update and
> >not perform it after every command packet. We keep the
> >intel_ring_advance() around in the code to provide demarcation for the
> >end-of-packet (which then can be compared against intel_ring_begin() as
> >the number of dwords emitted must match the reserved space).
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Joonas Lahtinen 
> >Cc: Dave Gordon 
> >---
> > drivers/gpu/drm/i915/intel_lrc.c|  2 +-
> > drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
> > 3 files changed, 18 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index bf42a66d6624..824f7efe4e64 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -373,7 +373,7 @@ static void execlists_update_context(struct 
> >drm_i915_gem_request *rq)
> > struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
> > uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
> >
> >-reg_state[CTX_RING_TAIL+1] = rq->tail;
> >+reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, 
> >rq->tail);
> >
> > /* True 32b PPGTT with dynamic page allocation: update PDP
> >  * registers and point the unallocated PDPs to scratch page.
> >diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> >b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >index 3142085b5cc0..21d5e8209400 100644
> >--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >@@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
> >drm_i915_gem_request *request)
> > {
> > struct drm_i915_private *dev_priv = request->i915;
> >
> >-I915_WRITE_TAIL(request->engine, request->tail);
> >+I915_WRITE_TAIL(request->engine,
> >+intel_ring_offset(request->ring, 
> >request->tail));
> > }
> >
> > static void
> >@@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
> >drm_i915_gem_request *request)
> > DRM_ERROR("timed out waiting for the BSD ring to wake 
> > up\n");
> >
> > /* Now that the ring is fully powered up, update the tail */
> >-I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), 
> >request->tail);
> >+I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
> >+  intel_ring_offset(request->ring, request->tail));
> > POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
> >
> > /* Let the ring send IDLE messages to the GT again,
> >diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> >b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >index 14d2ea36fb88..9ac96ddb01ee 100644
> >--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> >+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >@@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct 
> >intel_ring *ring, i915_reg_t reg)
> >
> > static inline void intel_ring_advance(struct intel_ring *ring)
> > {
> >+/* Dummy function.
> >+ *
> >+ * This serves as a placeholder in the code so that the reader
> >+ * can compare against the preceding intel_ring_begin() and
> >+ * check that the number of dwords emitted matches the space
> >+ * reserved for the command packet (i.e. the value passed to
> >+ * intel_ring_begin()).
> >+ */
> >+}
> >+
> >+static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
> >+{
> > /* The modulus is required so that we avoid writing
> >  * request->tail == ring->size, rather than the expected 0,
> >  * into the RING_TAIL register as that can cause a GPU hang.
> >- * As this is only strictly required for the request->tail,
> >- * and only then as we write the value into hardware, we can
> >- * one day remove the modulus afte

[Intel-gfx] [PATCH] drm/i915: Protect older gen against intel_gt_init_powersave()

[Chris Wilson]

In the middle of intel_gt_init_powersave() we have an if-chain that ends
with a universal else clause to read gen6+ registers. Older platforms
like Pineview that end up here do not like those registers and may even
OOPS whilst reading them!

Fixes: 3a45b05c4517 ("drm/i915: Preserve current RPS frequency across init")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1ac32428d4db..86e136c23ac2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6493,7 +6493,7 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
cherryview_init_gt_powersave(dev_priv);
else if (IS_VALLEYVIEW(dev_priv))
valleyview_init_gt_powersave(dev_priv);
-   else
+   else if (INTEL_GEN(dev_priv) >= 6)
gen6_init_rps_frequencies(dev_priv);
 
/* Derive initial user preferences/limits from the hardware limits */
-- 
2.8.1

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

Re: [Intel-gfx] [Beignet] [Patch V3] intel: Export pooled EU and min no. of eus in a pool.

[Arun Siluvery]

On 02/08/2016 07:20, Yang, Rong R wrote:

I sent a new version, could you check this and give comments/ACK?


Cc: Daniel, intel-gfx mailing list.

regards
Arun


Thanks,
Yang Rong


-Original Message-
From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
Yang Rong
Sent: Tuesday, August 2, 2016 15:51
To: beig...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Yang, Rong R 
Subject: [Beignet] [Patch V3] intel: Export pooled EU and min no. of eus in a
pool.

Update kernel interface with new I915_GETPARAM ioctl entries for pooled
EU and min no. of eus in a pool. Add a wrapping function for each parameter.
Userspace drivers need these values when decide the thread count. This
kernel enabled pooled eu by default for BXT and for fused down 2x6 parts it
is advised to turn it off.

But there is another HW issue in these parts (fused down 2x6 parts) before
C0 that requires Pooled EU to be enabled as a workaround. In this case the
pool configuration changes depending upon which subslice is disabled and
the no. of eus in a pool is different, So userspace need to know min no. of
eus in a pool.

V2: use return value as the query results.
 ret < 0 when error, ret = 0 when not support, and ret > 0 indicate
 query results.(Chris)
V3: Correct V2 errors.

Signed-off-by: Yang Rong 
---
  include/drm/i915_drm.h   |  2 ++
  intel/intel_bufmgr.h |  3 +++
  intel/intel_bufmgr_gem.c | 30 ++
  3 files changed, 35 insertions(+)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index
c4ce6b2..eb611a7 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -357,6 +357,8 @@ typedef struct drm_i915_irq_wait {
  #define I915_PARAM_HAS_GPU_RESET   35
  #define I915_PARAM_HAS_RESOURCE_STREAMER 36
  #define I915_PARAM_HAS_EXEC_SOFTPIN37
+#define I915_PARAM_HAS_POOLED_EU 38
+#define I915_PARAM_MIN_EU_IN_POOL39

  typedef struct drm_i915_getparam {
__s32 param;
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h index
a1abbcd..96a4d9d 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -273,6 +273,9 @@ int drm_intel_get_reset_stats(drm_intel_context
*ctx,  int drm_intel_get_subslice_total(int fd, unsigned int *subslice_total);
int drm_intel_get_eu_total(int fd, unsigned int *eu_total);

+int drm_intel_get_pooled_eu(int fd);
+int drm_intel_get_min_eu_in_pool(int fd);
+
  /** @{ Compatibility defines to keep old code building despite the symbol
rename
   * from dri_* to drm_intel_*
   */
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index
0a4012b..b0a0eb9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3237,6 +3237,36 @@ drm_intel_get_eu_total(int fd, unsigned int
*eu_total)
return 0;
  }

+int
+drm_intel_get_pooled_eu(int fd)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memclear(gp);
+   gp.param = I915_PARAM_HAS_POOLED_EU;
+   gp.value = &ret;
+   if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp))
+   return -errno;
+
+   return ret;
+}
+
+int
+drm_intel_get_min_eu_in_pool(int fd)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memclear(gp);
+   gp.param = I915_PARAM_MIN_EU_IN_POOL;
+   gp.value = &ret;
+   if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp))
+   return -errno;
+
+   return ret;
+}
+
  /**
   * Annotate the given bo for use in aub dumping.
   *
--
2.1.4

___
Beignet mailing list
beig...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet


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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Protect older gen against intel_gt_init_powersave()

[Patchwork]

== Series Details ==

Series: drm/i915: Protect older gen against intel_gt_init_powersave()
URL   : https://patchwork.freedesktop.org/series/10499/
State : failure

== Summary ==

Series 10499v1 drm/i915: Protect older gen against intel_gt_init_powersave()
http://patchwork.freedesktop.org/api/1.0/series/10499/revisions/1/mbox

Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (fi-hsw-i7-4770k)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-hsw-i7-4770r)
pass   -> FAIL   (ro-snb-i7-2620M)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)

fi-hsw-i7-4770k  total:213  pass:192  dwarn:0   dfail:0   fail:0   skip:20 
fi-kbl-qkkr  total:240  pass:181  dwarn:29  dfail:0   fail:3   skip:27 
fi-skl-i5-6260u  total:240  pass:224  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:240  pass:208  dwarn:0   dfail:0   fail:4   skip:28 
fi-snb-i7-2600   total:240  pass:198  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:4   dfail:0   fail:1   skip:16 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:196  dwarn:0   dfail:0   fail:4   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:173  dwarn:1   dfail:0   fail:1   skip:65 
ro-ilk1-i5-650   total:235  pass:172  dwarn:0   dfail:0   fail:3   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:197  dwarn:0   dfail:0   fail:2   skip:41 
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1665/

6f87e85 drm-intel-nightly: 2016y-08m-01d-14h-53m-17s UTC integration manifest
442d7a4 drm/i915: Protect older gen against intel_gt_init_powersave()

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

Re: [Intel-gfx] [PATCH] drm/i915: set proper N/M in modeset

[Ville Syrjälä]

On Tue, Aug 02, 2016 at 09:35:10AM +0800, libin.y...@linux.intel.com wrote:
> From: Libin Yang 
> 
> When modeset occurs and the LS_CLK is set to some
> special values in DP mode, the N/M need to be set
> manually if audio is playing.
> 
> The relationship of Maud and Naud is expressed in
> the following equation:
> Maud/Naud = 512 * fs / f_LS_Clk
> 
> Please refer VESA DisplayPort Standard spec for details.
> 
> Also, the patch applies
> commit 7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset")
> to APL platform.
> 
> Signed-off-by: Libin Yang 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|   6 ++
>  drivers/gpu/drm/i915/intel_audio.c | 122 
> +++--
>  2 files changed, 111 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8bfde75..2f9d00e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7351,6 +7351,12 @@ enum {
>  #define _HSW_AUD_CONFIG_B0x65100
>  #define HSW_AUD_CFG(pipe)_MMIO_PIPE(pipe, _HSW_AUD_CONFIG_A, 
> _HSW_AUD_CONFIG_B)
>  
> +#define _HSW_AUD_M_CTS_ENABLE_A  0x65028
> +#define _HSW_AUD_M_CTS_ENABLE_B  0x65128
> +#define HSW_AUD_M_CTS_ENABLE(pipe)   _MMIO_PIPE(pipe, 
> _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> +#define   AUD_M_CTS_M_VALUE_INDEX(1 << 21)
> +#define   AUD_M_CTS_M_PROG_ENABLE(1 << 20)
> +
>  #define _HSW_AUD_MISC_CTRL_A 0x65010
>  #define _HSW_AUD_MISC_CTRL_B 0x65110
>  #define HSW_AUD_MISC_CTRL(pipe)  _MMIO_PIPE(pipe, 
> _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 6700a7b..de55ecf 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -98,6 +98,22 @@ static const struct {
>   { 192000, TMDS_297M, 20480, 247500 },
>  };
>  
> +#define LC_540M 54
> +#define LC_162M 162000

Do we have some explanation why 2.7 doesn't need M/N programming,
but 1.62 and 5.4 do?

And I see you're only doing this on HSW+. Earlier platforms don't need
this?

> +static const struct {
> + int sample_rate;
> + int clock;
> + int n;
> + int m;

Can save a bit of space by using u16 for m and n.

> +} aud_nm[] = {
> + {48000, LC_540M, 5625, 256},`
> + {44100, LC_540M, 9375, 392},
> + {32000, LC_540M, 16875, 512},
> + {48000, LC_162M, 3375, 512},
> + {44100, LC_162M, 5625, 784},
> + {32000, LC_162M, 10125, 1024
> +};

The numbers look good, but what about other sample rates? For HDMI we go
up to 192kHz, why not for DP?

> +
>  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
>  static u32 audio_config_hdmi_pixel_clock(const struct drm_display_mode 
> *adjusted_mode)
>  {
> @@ -121,20 +137,50 @@ static u32 audio_config_hdmi_pixel_clock(const struct 
> drm_display_mode *adjusted
>   return hdmi_audio_clock[i].config;
>  }
>  
> -static int audio_config_get_n(const struct drm_display_mode *mode, int rate)
> +static int audio_config_get_n(struct intel_crtc *crtc,
> +   const struct drm_display_mode *adjusted_mode,
> +   int rate)
> +{
> + int i;
> +
> + if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) {
> + for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> + if ((rate == aud_ncts[i].sample_rate) &&
> + (adjusted_mode->clock == aud_ncts[i].clock)) {
> + return aud_ncts[i].n;
> + }
> + }
> + }
> +
> + if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DP)) {
> + for (i = 0; i < ARRAY_SIZE(aud_nm); i++) {
> + if ((rate == aud_nm[i].sample_rate) &&
> + (crtc->config->port_clock == aud_nm[i].clock)) {
> + return aud_nm[i].n;
> + }
> + }
> + }
> + return 0;
> +}
> +
> +static int audio_config_get_m(struct intel_crtc *crtc, int rate)
>  {
>   int i;
>  
> - for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> - if ((rate == aud_ncts[i].sample_rate) &&
> - (mode->clock == aud_ncts[i].clock)) {
> - return aud_ncts[i].n;
> + if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DP)) {
> + for (i = 0; i < ARRAY_SIZE(aud_nm); i++) {
> + if ((rate == aud_nm[i].sample_rate) &&
> + (crtc->config->port_clock == aud_nm[i].clock)) {
> + return aud_nm[i].m;
> + }
>   }
>   }
> +
>   return 0;
>  }
>  
> -static uint32_t audio_config_setup_n_reg(int n, uint32_t val)
> +static uint32_t audio_config_setup_n_reg(struct intel_crtc *crtc,
> +  int n, uint32_t val)
>  

Re: [Intel-gfx] [PATCH] drm/i915: set proper N/M in modeset

[Jani Nikula]

On Tue, 02 Aug 2016, libin.y...@linux.intel.com wrote:
> From: Libin Yang 
>
> When modeset occurs and the LS_CLK is set to some
> special values in DP mode, the N/M need to be set
> manually if audio is playing.
>
> The relationship of Maud and Naud is expressed in
> the following equation:
> Maud/Naud = 512 * fs / f_LS_Clk
>
> Please refer VESA DisplayPort Standard spec for details.
>
> Also, the patch applies
> commit 7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset")
> to APL platform.

Whenever a commit message says "also", it makes me think the patch
should probably be split to several patches. And that is certainly true
here.


-- 
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: Protect older gen against intel_gt_init_powersave()

[Ville Syrjälä]

On Tue, Aug 02, 2016 at 11:15:27AM +0100, Chris Wilson wrote:
> In the middle of intel_gt_init_powersave() we have an if-chain that ends
> with a universal else clause to read gen6+ registers. Older platforms
> like Pineview that end up here do not like those registers and may even
> OOPS whilst reading them!
> 
> Fixes: 3a45b05c4517 ("drm/i915: Preserve current RPS frequency across init")

Shouldn't that be
Fixes: 773ea9a80132 ("drm/i915: Perform static RPS frequency setup before 
userspace") ?

Either way,
Reviewed-by: Ville Syrjälä 

> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1ac32428d4db..86e136c23ac2 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6493,7 +6493,7 @@ void intel_init_gt_powersave(struct drm_i915_private 
> *dev_priv)
>   cherryview_init_gt_powersave(dev_priv);
>   else if (IS_VALLEYVIEW(dev_priv))
>   valleyview_init_gt_powersave(dev_priv);
> - else
> + else if (INTEL_GEN(dev_priv) >= 6)
>   gen6_init_rps_frequencies(dev_priv);
>  
>   /* Derive initial user preferences/limits from the hardware limits */
> -- 
> 2.8.1

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: remove redundant fbc warnings

[Matthew Auld]

> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> pass   -> FAIL   (ro-byt-n2820)
https://bugs.freedesktop.org/show_bug.cgi?id=95372
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Jani Nikula]

On Sat, 02 Jul 2016, "Vivi, Rodrigo"  wrote:
> Hi,
>
> Please consider pulling i915 updates to linux-firmware.git
>
>
> The following changes since commit
> 040c24514b94fcdbd6308d986d1bde59a704a21a:
>
>   linux-firmware: intel: Update Broxton audio firmware (2016-06-29
> 14:20:20 +0530)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~vivijim/linux-firmware-i915 master
>
> for you to fetch changes up to
> 19b71af5326bf28fe62ac2b1607b5e18d4b0eeb6:
>
>   linux-firmware/i915: Step away from symbolic links and clean up repo.
> (2016-07-01 16:07:52 -0700)
>
> 
> Rodrigo Vivi (3):
>   linux-firmware: New minor DMC release for Broxton - ver1_07
>   linux-firmware: First DMC image for Kabylake.
>   linux-firmware/i915: Step away from symbolic links and clean up
> repo.
>
>  WHENCE|  14 +-
>  i915/bxt_dmc_ver1.bin |   2 +-
>  i915/bxt_dmc_ver1_04.bin  | Bin 5872 -> 0
> bytes
>  i915/bxt_dmc_ver1_05.bin  | Bin 5872 -> 0
> bytes
>  i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} | Bin 8380 -> 8380
> bytes
>  i915/kbl_dmc_ver1.bin |   1 +
>  i915/kbl_dmc_ver1_01.bin  | Bin 0 -> 8616
> bytes
>  i915/skl_dmc_ver1_23.bin  | Bin 8824 -> 0
> bytes
>  i915/skl_guc_ver1.bin | Bin 21 -> 109636
> bytes
>  i915/skl_guc_ver1_1059.bin| Bin 109636 -> 0
> bytes
>  i915/skl_guc_ver4.bin | Bin 18 -> 128320
> bytes
>  i915/skl_guc_ver4_3.bin   | Bin 128320 -> 0
> bytes
>  12 files changed, 7 insertions(+), 10 deletions(-)
>  delete mode 100644 i915/bxt_dmc_ver1_04.bin
>  delete mode 100644 i915/bxt_dmc_ver1_05.bin
>  rename i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} (64%)
>  create mode 12 i915/kbl_dmc_ver1.bin
>  create mode 100644 i915/kbl_dmc_ver1_01.bin
>  delete mode 100644 i915/skl_dmc_ver1_23.bin
>  mode change 12 => 100644 i915/skl_guc_ver1.bin
>  delete mode 100644 i915/skl_guc_ver1_1059.bin
>  mode change 12 => 100644 i915/skl_guc_ver4.bin
>  delete mode 100644 i915/skl_guc_ver4_3.bin

Why are you deleting old versions?

BR,
Jani.

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

-- 
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] drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0

[ville . syrjala]

From: Ville Syrjälä 

Remove the CHV early bail out from intel_cleanup_gt_powersave() so that
we'll clean up the extra RPM reference held due to i915.enable_rc6=0.

Cc: Imre Deak 
Fixes: b268c699aca5 ("drm/i915: refactor RPM disabling due to RC6 being 
disabled")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1ac32428d4db..125faac2fb5d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6533,9 +6533,7 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
 
 void intel_cleanup_gt_powersave(struct drm_i915_private *dev_priv)
 {
-   if (IS_CHERRYVIEW(dev_priv))
-   return;
-   else if (IS_VALLEYVIEW(dev_priv))
+   if (IS_VALLEYVIEW(dev_priv))
valleyview_cleanup_gt_powersave(dev_priv);
 
if (!i915.enable_rc6)
-- 
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: Protect older gen against intel_gt_init_powersave()

[Chris Wilson]

On Tue, Aug 02, 2016 at 01:55:48PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 11:15:27AM +0100, Chris Wilson wrote:
> > In the middle of intel_gt_init_powersave() we have an if-chain that ends
> > with a universal else clause to read gen6+ registers. Older platforms
> > like Pineview that end up here do not like those registers and may even
> > OOPS whilst reading them!
> > 
> > Fixes: 3a45b05c4517 ("drm/i915: Preserve current RPS frequency across init")
> 
> Shouldn't that be
> Fixes: 773ea9a80132 ("drm/i915: Perform static RPS frequency setup before 
> userspace") ?

Yes, I missed in my grep for the commit marker.

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] [v4, 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Hans de Goede]

Hi,

On 26-07-16 19:34, cp...@redhat.com wrote:

Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates


This seems to not do what you want it to do, if I'm reading your changes
and the original code correct:




@@ -4589,6 +4592,11 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
 !old_primary_state->visible))
intel_post_enable_primary(&crtc->base);
}
+
+   if (old_intel_state->modeset &&
+   (old_intel_state->active_crtcs == 0 ||
+is_power_of_2(old_intel_state->active_crtcs)))
+   skl_enable_sagv(dev_priv);
 }



Here you are enabling the sagv if the *old* state allows it
(0 or 1 pipes active).

But judging from previous patches / the commit msg the
intent is to enable the sag if the *new* state allows
it, not the old one.

See e.g. the checks for calling intel_post_enable_primary()
which use both primary_state and old_primary_state

Also if you're going to respin you may want to switch
to using hweight as mentioned before, then you can simply
do something like (hamming_weight(active_crtcs) <= 1) as
condition to check for 0 or 1 active crtcs instead of
having 2 checks. Note please double check my logic here.




@@ -4649,6 +4659,15 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
}

/*
+* SKL workaround: bspec recommends we disable the SAGV when we have
+* more then one pipe enabled
+*/
+   if (old_intel_state->modeset &&
+   !is_power_of_2(old_intel_state->active_crtcs) &&
+   old_intel_state->active_crtcs != 0)
+   skl_disable_sagv(dev_priv);
+
+   /*


Same thing, you're disabling the sagv if the old state
disallows it, but I believe you should be looking at the new
state instead.

Regards,

Hans






 * If we're doing a modeset, we're done.  No need to do any pre-vblank
 * watermark programming here.
 */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e74d851..113bf48 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1709,6 +1709,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
+int skl_enable_sagv(struct drm_i915_private *dev_priv);
+int skl_disable_sagv(struct drm_i915_private *dev_priv);
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 64d628c..55a9694 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2876,6 +2876,109 @@ skl_wm_plane_id(const struct intel_plane *plane)
 }

 static void
+skl_sagv_get_hw_state(struct drm_i915_private 

Re: [Intel-gfx] [PATCH v6 06/10] drm: Read DP branch device HW revision

[Mika Kahola]

On Tue, 2016-07-12 at 15:54 +0200, Daniel Vetter wrote:
> On Wed, Jul 06, 2016 at 02:04:50PM +0300, Mika Kahola wrote:
> > HW revision is mandatory field for DisplayPort branch
> > devices. This is defined in DPCD register field 0x509.
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 21 +
> >  include/drm/drm_dp_helper.h |  7 +++
> >  2 files changed, 28 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 4003464..cfd75df 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -514,6 +514,27 @@ int drm_dp_downstream_max_bpc(const u8 
> > dpcd[DP_RECEIVER_CAP_SIZE],
> >  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> >  
> >  /**
> > + * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> > + * @aux: DisplayPort AUX channel
> > + *
> > + * Returns HW revision on succes or negative error code on failure
> > + */
> > +struct drm_dp_revision drm_dp_downstream_hw_rev(struct drm_dp_aux *aux)
> > +{
> > +   uint8_t tmp;
> > +   struct drm_dp_revision rev = { .major = -EINVAL, .minor = -EINVAL };
> > +
> > +   if (drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, &tmp, 1) != 1)
> > +   return rev;
> > +
> > +   rev.major = (tmp & 0xf0) >> 4;
> > +   rev.minor = tmp & 0xf;
> > +
> > +   return rev;
> > +}
> > +EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
> > +
> > +/**
> >   * drm_dp_downstream_id() - identify branch device
> >   * @aux: DisplayPort AUX channel
> >   *
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 8264d54..5f577e4 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -446,6 +446,7 @@
> >  #define DP_SINK_OUI0x400
> >  #define DP_BRANCH_OUI  0x500
> >  #define DP_BRANCH_ID0x503
> > +#define DP_BRANCH_HW_REV0x509
> >  
> >  #define DP_SET_POWER0x600
> >  # define DP_SET_POWER_D00x1
> > @@ -803,6 +804,11 @@ struct drm_dp_link {
> > unsigned long capabilities;
> >  };
> >  
> > +struct drm_dp_revision {
> > +   int major;
> > +   int minor;
> > +};
> 
> Atm we have two styles of helpers:
> - The ones that put decoded values into struct drm_dp_link
> - A pile of functions that return individual values.
> 
> This seems to add a third one. I guess it'd be better to just move
> everything over to putting parsed values into drm_dp_link and fill that
> out for everything ...
> -Daniel

Ok. Let's move all this information to drm_dp_link. I'll revise the
patch.

Cheers,
Mika
> 
> > +
> >  int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
> >  int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
> >  int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link 
> > *link);
> > @@ -812,6 +818,7 @@ int drm_dp_downstream_max_clock(const u8 
> > dpcd[DP_RECEIVER_CAP_SIZE],
> >  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >   const u8 port_cap[4]);
> >  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
> > +struct drm_dp_revision drm_dp_downstream_hw_rev(struct drm_dp_aux *aux);
> >  
> >  void drm_dp_aux_init(struct drm_dp_aux *aux);
> >  int drm_dp_aux_register(struct drm_dp_aux *aux);
> > -- 
> > 1.9.1
> > 
> 

-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH] drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0

[Imre Deak]

On ti, 2016-08-02 at 14:07 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Remove the CHV early bail out from intel_cleanup_gt_powersave() so that
> we'll clean up the extra RPM reference held due to i915.enable_rc6=0.
> 
> Cc: Imre Deak 
> Fixes: b268c699aca5 ("drm/i915: refactor RPM disabling due to RC6 being 
> disabled")
> Signed-off-by: Ville Syrjälä 

Thanks for catching it:
Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1ac32428d4db..125faac2fb5d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6533,9 +6533,7 @@ void intel_init_gt_powersave(struct drm_i915_private 
> *dev_priv)
>  
>  void intel_cleanup_gt_powersave(struct drm_i915_private *dev_priv)
>  {
> - if (IS_CHERRYVIEW(dev_priv))
> - return;
> - else if (IS_VALLEYVIEW(dev_priv))
> + if (IS_VALLEYVIEW(dev_priv))
>   valleyview_cleanup_gt_powersave(dev_priv);
>  
>   if (!i915.enable_rc6)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 08/10] drm/i915: Check pixel rate for DP to VGA dongle

[Mika Kahola]

On Tue, 2016-07-12 at 15:50 +0200, Daniel Vetter wrote:
> On Wed, Jul 06, 2016 at 02:04:52PM +0300, Mika Kahola wrote:
> > Filter out a mode that exceeds the max pixel rate setting
> > for DP to VGA dongle. This is defined in DPCD register 0x81
> > if detailed cap info i.e. info field is 4 bytes long and
> > it is available for DP downstream port.
> > 
> > The register defines the pixel rate divided by 8 in MP/s.
> > 
> > v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> > v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> > function (Daniel)
> > v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
> > v5: Use of intel_dp->downstream_ports to read out port capabilities.
> > Code restructuring (Ville)
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 26 ++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index ffa43ec..76a654e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -190,6 +190,20 @@ intel_dp_max_data_rate(int max_link_clock, int 
> > max_lanes)
> > return (max_link_clock * max_lanes * 8) / 10;
> >  }
> >  
> > +static int
> > +intel_dp_downstream_max_clock(struct intel_dp *intel_dp, int clock)
> > +{
> > +   int dp_ds_clk;
> > +
> > +   dp_ds_clk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> > +   intel_dp->downstream_ports);
> > +
> > +   if (dp_ds_clk == 0)
> > +   return clock;
> > +
> > +   return min(clock, dp_ds_clk);
> > +}
> > +
> >  static enum drm_mode_status
> >  intel_dp_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > @@ -201,6 +215,18 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> >  
> > +   bool is_branch_device = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > +   DP_DWN_STRM_PORT_PRESENT;
> > +   int type;
> > +
> > +   if (is_branch_device) {
> 
> Shouldn't we move this check into the drm dp helper? It can always return
> 0 for "no downstream port restrictions".
I guess we can do that. It probably looks cleaner that way.

Cheers,
Mika

> 
> > +   type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> > +
> > +   if (type == DP_DS_PORT_TYPE_VGA)
> Same here.
> -Daniel
> 
> > +   max_dotclk = intel_dp_downstream_max_clock(intel_dp,
> > +  max_dotclk);
> > +   }
> > +
> > if (is_edp(intel_dp) && fixed_mode) {
> > if (mode->hdisplay > fixed_mode->hdisplay)
> > return MODE_PANEL;
> > -- 
> > 1.9.1
> > 
> 

-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH] drm/i915: Protect older gen against intel_gt_init_powersave()

[Joonas Lahtinen]

On ti, 2016-08-02 at 13:55 +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 11:15:27AM +0100, Chris Wilson wrote:
> > 
> > In the middle of intel_gt_init_powersave() we have an if-chain that ends
> > with a universal else clause to read gen6+ registers. Older platforms
> > like Pineview that end up here do not like those registers and may even
> > OOPS whilst reading them!
> > 
> > Fixes: 3a45b05c4517 ("drm/i915: Preserve current RPS frequency across init")
> Shouldn't that be
> Fixes: 773ea9a80132 ("drm/i915: Perform static RPS frequency setup before 
> userspace") ?
> 

Me thinks so too, the patch in original Fixes: is the one that
triggered the bug in bisecting(?), but patch that Ville mentioned is
what should be followed by this patch everywhere being applied, so the
Fixes: should point to it.

So with above Fixes: updated.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

> Either way,
> Reviewed-by: Ville Syrjälä 
> 
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Mika Kuoppala 
> > Cc: Joonas Lahtinen 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 1ac32428d4db..86e136c23ac2 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6493,7 +6493,7 @@ void intel_init_gt_powersave(struct drm_i915_private 
> > *dev_priv)
> >     cherryview_init_gt_powersave(dev_priv);
> >     else if (IS_VALLEYVIEW(dev_priv))
> >     valleyview_init_gt_powersave(dev_priv);
> > -   else
> > +   else if (INTEL_GEN(dev_priv) >= 6)
> >     gen6_init_rps_frequencies(dev_priv);
> >  
> >     /* Derive initial user preferences/limits from the hardware limits */
> > -- 
> > 2.8.1
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 09/10] drm/i915: Update bits per component for display info

[Mika Kahola]

On Tue, 2016-07-12 at 15:51 +0200, Daniel Vetter wrote:
> On Wed, Jul 06, 2016 at 02:04:53PM +0300, Mika Kahola wrote:
> > DisplayPort branch device may define max supported bits per
> > component. Update display info based on this value if bpc
> > is defined.
> > 
> > v2: cleanup to match the drm_dp_helper.c patches introduced
> > earlier in this series
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 76a654e..53ec844 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3932,6 +3932,14 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > uint8_t *dpcd = intel_dp->dpcd;
> > uint8_t type;
> >  
> > +   if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT) {
> > +   int bpc = drm_dp_downstream_max_bpc(dpcd,
> > +   intel_dp->downstream_ports);
> > +
> > +   if (bpc > 0)
> > +   intel_dp->attached_connector->base.display_info.bpc = 
> > bpc;
> > +   }
> 
> I think a function in the dp helpers to correctly fill out the connector's
> display info would be neater.
> -Daniel
Ok. I can move this stuff to be part of dp helper routine.
Cheers,
Mika
> 
> > +
> > if (!intel_dp_get_dpcd(intel_dp))
> > return connector_status_disconnected;
> >  
> > @@ -3968,6 +3976,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > return connector_status_unknown;
> > }
> >  
> > +
> > /* Anything else is out of spec, warn and ignore */
> > DRM_DEBUG_KMS("Broken DP branch device, ignoring\n");
> > return connector_status_disconnected;
> > -- 
> > 1.9.1
> > 
> 

-- 
Mika Kahola - Intel OTC

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

[Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the 
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 drivers/gpu/drm/i915/i915_params.c | 64 +++---
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..7184e06 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -60,22 +60,22 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
 };
 
-module_param_named(modeset, i915.modeset, int, 0400);
+module_param_named(modeset, i915.modeset, int, S_IRUSR);
 MODULE_PARM_DESC(modeset,
"Use kernel modesetting [KMS] (0=disable, "
"1=on, -1=force vga console preference [default])");
 
-module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 0600);
+module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(panel_ignore_lid,
"Override lid status (0=autodetect, 1=autodetect disabled [default], "
"-1=force lid closed, -2=force lid open)");
 
-module_param_named_unsafe(semaphores, i915.semaphores, int, 0400);
+module_param_named_unsafe(semaphores, i915.semaphores, int, S_IRUSR);
 MODULE_PARM_DESC(semaphores,
"Use semaphores for inter-ring sync "
"(default: -1 (use per-chip defaults))");
 
-module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, 0400);
+module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, S_IRUSR);
 MODULE_PARM_DESC(enable_rc6,
"Enable power-saving render C-state 6. "
"Different stages can be selected via bitmask values "
@@ -83,82 +83,82 @@ MODULE_PARM_DESC(enable_rc6,
"For example, 3 would enable rc6 and deep rc6, and 7 would enable 
everything. "
"default: -1 (use per-chip default)");
 
-module_param_named_unsafe(enable_dc, i915.enable_dc, int, 0400);
+module_param_named_unsafe(enable_dc, i915.enable_dc, int, S_IRUSR);
 MODULE_PARM_DESC(enable_dc,
"Enable power-saving display C-states. "
"(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
 
-module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, 0600);
+module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(enable_fbc,
"Enable frame buffer compression for power savings "
"(default: -1 (use per-chip default))");
 
-module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
0400);
+module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
S_IRUSR);
 MODULE_PARM_DESC(lvds_channel_mode,
 "Specify LVDS channel mode "
 "(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
 
-module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, 0600);
+module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, S_IRUSR | 
S_IWUSR);
 MODULE_PARM_DESC(lvds_use_ssc,
"Use Spread Spectrum Clock with panels [LVDS/eDP] "
"(default: auto from VBT)");
 
-module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, int, 
0400);
+module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, int, 
S_IRUSR);
 MODULE_PARM_DESC(vbt_sdvo_panel_type,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-module_param_named_unsafe(reset, i915.reset, bool, 0600);
+module_param_named_unsafe(reset, i915.reset, bool, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
 
-module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644);
+module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(enable_hangcheck,
"Periodically check GPU activity for detecting hangs. "
"WARNING: Disabling this can cause system wide hangs. "
"(default: true)");
 
-module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
+module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, S_IRUSR);
 MODULE_PARM_DESC(enable_ppgtt,
"Override PPGTT usage. "
"(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full with 
extended address space)");
 
-module_param_named_unsafe(enable_execlists, i915.enable_execlists, int, 0400);
+module_param_named_unsafe(enable_execlists, i915.enable_execlists, int, 
S_IRUSR);
 MODULE_PARM_DESC(enable_execlists,
"Override execlists usage. "
"(-1=auto [default], 0=disabled, 1=enabled)");
 
-module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600)

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: remove redundant fbc warnings

[Joonas Lahtinen]

Merged, thanks for the patch and review.

On ti, 2016-08-02 at 12:05 +0100, Matthew Auld wrote:
> > 
> > Test gem_exec_flush:
> > Subgroup basic-batch-kernel-default-cmd:
> > pass   -> FAIL   (ro-byt-n2820)
> https://bugs.freedesktop.org/show_bug.cgi?id=95372
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0

[Patchwork]

== Series Details ==

Series: drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0
URL   : https://patchwork.freedesktop.org/series/10505/
State : failure

== Summary ==

Series 10505v1 drm/i915: Clean up the extra RPM ref on CHV with 
i915.enable_rc6=0
http://patchwork.freedesktop.org/api/1.0/series/10505/revisions/1/mbox

Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-hsw-i7-4770r)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (ro-bdw-i7-5557U)

fi-skl-i5-6260u  total:240  pass:224  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:240  pass:208  dwarn:0   dfail:0   fail:4   skip:28 
fi-snb-i7-2600   total:240  pass:198  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:4   dfail:0   fail:2   skip:16 
ro-bdw-i7-5557U  total:240  pass:223  dwarn:1   dfail:0   fail:0   skip:16 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:172  dwarn:1   dfail:0   fail:2   skip:65 
ro-ilk1-i5-650   total:235  pass:172  dwarn:0   dfail:0   fail:3   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:198  dwarn:0   dfail:0   fail:1   skip:41 
fi-hsw-i7-4770k failed to connect after reboot
fi-kbl-qkkr failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1666/

6f87e85 drm-intel-nightly: 2016y-08m-01d-14h-53m-17s UTC integration manifest
b3d5711 drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0

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

Re: [Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

[Ville Syrjälä]

On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the 
> corresponding macro,
> and that using macro can improve the robustness and readability of the code,
> thus, I suggest replacing the numeric parameter with the macro.
> 
> Signed-off-by: Chuansheng Liu 
> Signed-off-by: Baole Ni 
> ---
>  drivers/gpu/drm/i915/i915_params.c | 64 
> +++---
>  1 file changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 1779f02..7184e06 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -60,22 +60,22 @@ struct i915_params i915 __read_mostly = {
>   .inject_load_failure = 0,
>  };
>  
> -module_param_named(modeset, i915.modeset, int, 0400);
> +module_param_named(modeset, i915.modeset, int, S_IRUSR);

At least I can't read those macros. Octal is much clearer IMO.

>  MODULE_PARM_DESC(modeset,
>   "Use kernel modesetting [KMS] (0=disable, "
>   "1=on, -1=force vga console preference [default])");
>  
> -module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
> 0600);
> +module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
> S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(panel_ignore_lid,
>   "Override lid status (0=autodetect, 1=autodetect disabled [default], "
>   "-1=force lid closed, -2=force lid open)");
>  
> -module_param_named_unsafe(semaphores, i915.semaphores, int, 0400);
> +module_param_named_unsafe(semaphores, i915.semaphores, int, S_IRUSR);
>  MODULE_PARM_DESC(semaphores,
>   "Use semaphores for inter-ring sync "
>   "(default: -1 (use per-chip defaults))");
>  
> -module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, 0400);
> +module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, S_IRUSR);
>  MODULE_PARM_DESC(enable_rc6,
>   "Enable power-saving render C-state 6. "
>   "Different stages can be selected via bitmask values "
> @@ -83,82 +83,82 @@ MODULE_PARM_DESC(enable_rc6,
>   "For example, 3 would enable rc6 and deep rc6, and 7 would enable 
> everything. "
>   "default: -1 (use per-chip default)");
>  
> -module_param_named_unsafe(enable_dc, i915.enable_dc, int, 0400);
> +module_param_named_unsafe(enable_dc, i915.enable_dc, int, S_IRUSR);
>  MODULE_PARM_DESC(enable_dc,
>   "Enable power-saving display C-states. "
>   "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
>  
> -module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, 0600);
> +module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, S_IRUSR | 
> S_IWUSR);
>  MODULE_PARM_DESC(enable_fbc,
>   "Enable frame buffer compression for power savings "
>   "(default: -1 (use per-chip default))");
>  
> -module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
> 0400);
> +module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
> S_IRUSR);
>  MODULE_PARM_DESC(lvds_channel_mode,
>"Specify LVDS channel mode "
>"(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
>  
> -module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, 0600);
> +module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, S_IRUSR | 
> S_IWUSR);
>  MODULE_PARM_DESC(lvds_use_ssc,
>   "Use Spread Spectrum Clock with panels [LVDS/eDP] "
>   "(default: auto from VBT)");
>  
> -module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, 
> int, 0400);
> +module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, 
> int, S_IRUSR);
>  MODULE_PARM_DESC(vbt_sdvo_panel_type,
>   "Override/Ignore selection of SDVO panel mode in the VBT "
>   "(-2=ignore, -1=auto [default], index in VBT BIOS table)");
>  
> -module_param_named_unsafe(reset, i915.reset, bool, 0600);
> +module_param_named_unsafe(reset, i915.reset, bool, S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
>  
> -module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
> 0644);
> +module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
>  MODULE_PARM_DESC(enable_hangcheck,
>   "Periodically check GPU activity for detecting hangs. "
>   "WARNING: Disabling this can cause system wide hangs. "
>   "(default: true)");
>  
> -module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
> +module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, S_IRUSR);
>  MODULE_PARM_DESC(enable_ppgtt,
>   "Override PPGTT usage. "
>   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full with 
> extended address space)");
>  
> -module_param_named_unsafe(enable_execlists, i915.enable_execlist

Re: [Intel-gfx] [PATCH v6 09/10] drm/i915: Update bits per component for display info

[Ville Syrjälä]

On Tue, Aug 02, 2016 at 02:23:13PM +0300, Mika Kahola wrote:
> On Tue, 2016-07-12 at 15:51 +0200, Daniel Vetter wrote:
> > On Wed, Jul 06, 2016 at 02:04:53PM +0300, Mika Kahola wrote:
> > > DisplayPort branch device may define max supported bits per
> > > component. Update display info based on this value if bpc
> > > is defined.
> > > 
> > > v2: cleanup to match the drm_dp_helper.c patches introduced
> > > earlier in this series
> > > 
> > > Signed-off-by: Mika Kahola 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 9 +
> > >  1 file changed, 9 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 76a654e..53ec844 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -3932,6 +3932,14 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > >   uint8_t *dpcd = intel_dp->dpcd;
> > >   uint8_t type;
> > >  
> > > + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT) {
> > > + int bpc = drm_dp_downstream_max_bpc(dpcd,
> > > + intel_dp->downstream_ports);
> > > +
> > > + if (bpc > 0)
> > > + intel_dp->attached_connector->base.display_info.bpc = 
> > > bpc;
> > > + }
> > 
> > I think a function in the dp helpers to correctly fill out the connector's
> > display info would be neater.
> > -Daniel
> Ok. I can move this stuff to be part of dp helper routine.

I'm not sure frobbing with display_info is a good idea here since that
that one has so far been the EDID parsers domain. The ordering between
all this stuff is already very poorly defined/buggy, so some bigger
cleanup is probably needed. I have some patches to the EDID parser that
I should send out that at least make it a bit clearer where it fills out
the display_info stuff.

> Cheers,
> Mika
> > 
> > > +
> > >   if (!intel_dp_get_dpcd(intel_dp))
> > >   return connector_status_disconnected;
> > >  
> > > @@ -3968,6 +3976,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > >   return connector_status_unknown;
> > >   }
> > >  
> > > +
> > >   /* Anything else is out of spec, warn and ignore */
> > >   DRM_DEBUG_KMS("Broken DP branch device, ignoring\n");
> > >   return connector_status_disconnected;
> > > -- 
> > > 1.9.1
> > > 
> > 
> 
> -- 
> Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH 0/9] drm/i915: SKL iboost fixes

[Ville Syrjälä]

On Tue, Jul 12, 2016 at 03:59:27PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> While looking into the recent low vs. normal vswing SKL regression, I ended
> up going through the iboost handling as well. I spotted several problems
> which I've tried to fix. I also picked up a bunch of related patches from
> my earlier split DDI encoder series [1].
> 
> Entire series available here:
> git://github.com/vsyrjala/linux.git ddi_iboost_fixes_2 
> 
> [1] https://lists.freedesktop.org/archives/intel-gfx/2015-December/082384.html
> 
> Ville Syrjälä (9):

I slapped
Cc: sta...@vger.kernel.org
Fixes: f8896f5d58e6 ("drm/i915/skl: Buffer translation improvements")

to these two suckers
>   drm/i915: Fix iboost setting for DDI with 4 lanes on SKL
>   drm/i915: Program iboost settings for HDMI/DVI on SKL

and pushed the lot to dinq. Thanks for the reviews.

>   drm/i915: Name the "iboost bit"
>   drm/i915: Move bxt_ddi_vswing_sequence() call into
> intel_ddi_pre_enable() for HDMI
>   drm/i915: Explicitly use ddi buf trans entry 9 for hdmi
>   drm/i915: Split DP/eDP/FDI and HDMI/DVI DDI buffer programming apart
>   drm/i915: Get the iboost setting based on the port type
>   drm/i915: Simplify intel_ddi_get_encoder_port()
>   drm/i915: Extract bdw_get_buf_trans_edp()
> 
>  drivers/gpu/drm/i915/i915_reg.h |   2 +
>  drivers/gpu/drm/i915/intel_ddi.c| 230 
> +---
>  drivers/gpu/drm/i915/intel_dp_mst.c |   4 +-
>  drivers/gpu/drm/i915/intel_drv.h|   2 +-
>  4 files changed, 137 insertions(+), 101 deletions(-)
> 
> -- 
> 2.7.4

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

[Intel-gfx] [PATCH] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

[ville . syrjala]

From: Ville Syrjälä 

The spec was recently fixed to have the correct iboost setting for the
SKL Y/U DP DDI buffer translation table entry 2. Update our tables
to match.

Cc: David Weinehall 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fc2ef2d76091..c55a2ad50c0d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -145,7 +145,7 @@ static const struct ddi_buf_trans skl_ddi_translations_dp[] 
= {
 static const struct ddi_buf_trans skl_u_ddi_translations_dp[] = {
{ 0x201B, 0x00A2, 0x0 },
{ 0x5012, 0x0088, 0x0 },
-   { 0x80007011, 0x00CD, 0x0 },
+   { 0x80007011, 0x00CD, 0x1 },
{ 0x80009010, 0x00C0, 0x1 },
{ 0x201B, 0x009D, 0x0 },
{ 0x80005012, 0x00C0, 0x1 },
@@ -158,7 +158,7 @@ static const struct ddi_buf_trans 
skl_u_ddi_translations_dp[] = {
 static const struct ddi_buf_trans skl_y_ddi_translations_dp[] = {
{ 0x0018, 0x00A2, 0x0 },
{ 0x5012, 0x0088, 0x0 },
-   { 0x80007011, 0x00CD, 0x0 },
+   { 0x80007011, 0x00CD, 0x3 },
{ 0x80009010, 0x00C0, 0x3 },
{ 0x0018, 0x009D, 0x0 },
{ 0x80005012, 0x00C0, 0x3 },
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

[Jani Nikula]

On Tue, 02 Aug 2016, Ville Syrjälä  wrote:
> On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote:
>> I find that the developers often just specified the numeric value
>> when calling a macro which is defined with a parameter for access permission.
>> As we know, these numeric value for access permission have had the 
>> corresponding macro,
>> and that using macro can improve the robustness and readability of the code,
>> thus, I suggest replacing the numeric parameter with the macro.
>> 
>> Signed-off-by: Chuansheng Liu 
>> Signed-off-by: Baole Ni 
>> ---
>>  drivers/gpu/drm/i915/i915_params.c | 64 
>> +++---
>>  1 file changed, 32 insertions(+), 32 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_params.c 
>> b/drivers/gpu/drm/i915/i915_params.c
>> index 1779f02..7184e06 100644
>> --- a/drivers/gpu/drm/i915/i915_params.c
>> +++ b/drivers/gpu/drm/i915/i915_params.c
>> @@ -60,22 +60,22 @@ struct i915_params i915 __read_mostly = {
>>  .inject_load_failure = 0,
>>  };
>>  
>> -module_param_named(modeset, i915.modeset, int, 0400);
>> +module_param_named(modeset, i915.modeset, int, S_IRUSR);
>
> At least I can't read those macros. Octal is much clearer IMO.

Besides I think we should consider making most if not all of these
parameters group/other readable. Which would then potentially become
S_IWUSR | S_IRUSR | S_IRGRP | S_IROTH instead of just 0644.

BR,
Jani.

>
>>  MODULE_PARM_DESC(modeset,
>>  "Use kernel modesetting [KMS] (0=disable, "
>>  "1=on, -1=force vga console preference [default])");
>>  
>> -module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
>> 0600);
>> +module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
>> S_IRUSR | S_IWUSR);
>>  MODULE_PARM_DESC(panel_ignore_lid,
>>  "Override lid status (0=autodetect, 1=autodetect disabled [default], "
>>  "-1=force lid closed, -2=force lid open)");
>>  
>> -module_param_named_unsafe(semaphores, i915.semaphores, int, 0400);
>> +module_param_named_unsafe(semaphores, i915.semaphores, int, S_IRUSR);
>>  MODULE_PARM_DESC(semaphores,
>>  "Use semaphores for inter-ring sync "
>>  "(default: -1 (use per-chip defaults))");
>>  
>> -module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, 0400);
>> +module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, S_IRUSR);
>>  MODULE_PARM_DESC(enable_rc6,
>>  "Enable power-saving render C-state 6. "
>>  "Different stages can be selected via bitmask values "
>> @@ -83,82 +83,82 @@ MODULE_PARM_DESC(enable_rc6,
>>  "For example, 3 would enable rc6 and deep rc6, and 7 would enable 
>> everything. "
>>  "default: -1 (use per-chip default)");
>>  
>> -module_param_named_unsafe(enable_dc, i915.enable_dc, int, 0400);
>> +module_param_named_unsafe(enable_dc, i915.enable_dc, int, S_IRUSR);
>>  MODULE_PARM_DESC(enable_dc,
>>  "Enable power-saving display C-states. "
>>  "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
>>  
>> -module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, 0600);
>> +module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, S_IRUSR | 
>> S_IWUSR);
>>  MODULE_PARM_DESC(enable_fbc,
>>  "Enable frame buffer compression for power savings "
>>  "(default: -1 (use per-chip default))");
>>  
>> -module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
>> 0400);
>> +module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
>> S_IRUSR);
>>  MODULE_PARM_DESC(lvds_channel_mode,
>>   "Specify LVDS channel mode "
>>   "(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
>>  
>> -module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, 0600);
>> +module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, S_IRUSR | 
>> S_IWUSR);
>>  MODULE_PARM_DESC(lvds_use_ssc,
>>  "Use Spread Spectrum Clock with panels [LVDS/eDP] "
>>  "(default: auto from VBT)");
>>  
>> -module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, 
>> int, 0400);
>> +module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, 
>> int, S_IRUSR);
>>  MODULE_PARM_DESC(vbt_sdvo_panel_type,
>>  "Override/Ignore selection of SDVO panel mode in the VBT "
>>  "(-2=ignore, -1=auto [default], index in VBT BIOS table)");
>>  
>> -module_param_named_unsafe(reset, i915.reset, bool, 0600);
>> +module_param_named_unsafe(reset, i915.reset, bool, S_IRUSR | S_IWUSR);
>>  MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
>>  
>> -module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
>> 0644);
>> +module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
>> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
>>  MODULE_PARM_DESC(enable_hangcheck,
>>  "Periodically check GPU activity for detecting hangs. "
>>  "WARNING: Disabling this can cause system wide hangs. "
>>  "(default: true)");
>>  
>> -module_param_named_unsafe(enable_ppgtt, i915.enable_

Re: [Intel-gfx] [PATCH] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

[Jani Nikula]

On Tue, 02 Aug 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> The spec was recently fixed to have the correct iboost setting for the
> SKL Y/U DP DDI buffer translation table entry 2. Update our tables
> to match.
>
> Cc: David Weinehall 
> Signed-off-by: Ville Syrjälä 

Cc: sta...@vger.kernel.org

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index fc2ef2d76091..c55a2ad50c0d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -145,7 +145,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_dp[] = {
>  static const struct ddi_buf_trans skl_u_ddi_translations_dp[] = {
>   { 0x201B, 0x00A2, 0x0 },
>   { 0x5012, 0x0088, 0x0 },
> - { 0x80007011, 0x00CD, 0x0 },
> + { 0x80007011, 0x00CD, 0x1 },
>   { 0x80009010, 0x00C0, 0x1 },
>   { 0x201B, 0x009D, 0x0 },
>   { 0x80005012, 0x00C0, 0x1 },
> @@ -158,7 +158,7 @@ static const struct ddi_buf_trans 
> skl_u_ddi_translations_dp[] = {
>  static const struct ddi_buf_trans skl_y_ddi_translations_dp[] = {
>   { 0x0018, 0x00A2, 0x0 },
>   { 0x5012, 0x0088, 0x0 },
> - { 0x80007011, 0x00CD, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
>   { 0x80009010, 0x00C0, 0x3 },
>   { 0x0018, 0x009D, 0x0 },
>   { 0x80005012, 0x00C0, 0x3 },

-- 
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 v2 12/21] drm/i915: Move HAS_AUX_IRQ definition to platform definition

[Jani Nikula]

On Fri, 29 Jul 2016, Ville Syrjälä  wrote:
> On Thu, Jul 28, 2016 at 12:12:27PM -0700, Carlos Santa wrote:
>> Moving all GPU features to the platform struct definition allows for
>>  - standard place when adding new features from new platforms
>>  - possible to see supported features when dumping struct
>>definitions
>> 
>> Signed-off-by: Carlos Santa 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>>  drivers/gpu/drm/i915/i915_pci.c | 4 
>>  2 files changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 28c7264..50062b6 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -780,6 +780,7 @@ struct intel_csr {
>>  func(has_rc6) sep \
>>  func(has_rc6p) sep \
>>  func(has_dp_mst) sep \
>> +func(has_aux_irq) sep \
>>  func(has_pipe_cxsr) sep \
>>  func(has_hotplug) sep \
>>  func(cursor_needs_physical) sep \
>> @@ -2720,7 +2721,7 @@ struct drm_i915_cmd_table {
>>   * legacy irq no. is shared with another device. The kernel then disables 
>> that
>>   * interrupt source and so prevents the other device from working properly.
>>   */
>> -#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
>> +#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->has_aux_irq)
>
> These kind of flags I'm not sure will buy us anything. They're not
> likely to change ever, so we're just forcing new platforms to add more
> and more boilerplate to the feature structs/templates.
>
> While I generally disklike negative flags, I'm almost tempted to say
> that for stuff like this, it might be better. That is if we even want to
> turn them into flags.

Yeah, do we really want to turn *everything* into flags? HAS_AUX_IRQ()
has exactly one reference.

BR,
Jani.


>
>
>>  #define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
>>  
>>  /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c 
>> b/drivers/gpu/drm/i915/i915_pci.c
>> index 693943f..8780924 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -180,6 +180,7 @@ static const struct intel_device_info 
>> intel_pineview_info = {
>>  #define GEN5_FEATURES \
>>  .gen = 5, .num_pipes = 2, \
>>  .need_gfx_hws = 1, .has_hotplug = 1, \
>> +.has_aux_irq = 1, \
>>  .ring_mask = RENDER_RING | BSD_RING, \
>>  GEN_DEFAULT_PIPEOFFSETS, \
>>  CURSOR_OFFSETS
>> @@ -243,6 +244,7 @@ static const struct intel_device_info 
>> intel_ivybridge_q_info = {
>>  .has_psr = 1, \
>>  .has_runtime_pm = 1, \
>>  .has_rc6 = 1, \
>> +.has_aux_irq = 1, \
>>  .need_gfx_hws = 1, .has_hotplug = 1, \
>>  .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>>  .display_mmio_offset = VLV_DISPLAY_BASE, \
>> @@ -321,6 +323,7 @@ static const struct intel_device_info 
>> intel_cherryview_info = {
>>  .has_runtime_pm = 1,
>>  .has_resource_streamer = 1,
>>  .has_rc6 = 1,
>> +.has_aux_irq = 1,
>>  .display_mmio_offset = VLV_DISPLAY_BASE,
>>  GEN_CHV_PIPEOFFSETS,
>>  CURSOR_OFFSETS,
>> @@ -357,6 +360,7 @@ static const struct intel_device_info intel_broxton_info 
>> = {
>>  .has_resource_streamer = 1,
>>  .has_rc6 = 1,
>>  .has_dp_mst = 1,
>> +.has_aux_irq = 1,
>>  GEN_DEFAULT_PIPEOFFSETS,
>>  IVB_CURSOR_OFFSETS,
>>  BDW_COLORS,
>> -- 
>> 1.9.1
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] ✗ Ro.CI.BAT: failure for drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

[Patchwork]

== Series Details ==

Series: drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation 
entry 2
URL   : https://patchwork.freedesktop.org/series/10511/
State : failure

== Summary ==

Series 10511v1 drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer 
translation entry 2
http://patchwork.freedesktop.org/api/1.0/series/10511/revisions/1/mbox

Test drv_module_reload_basic:
pass   -> SKIP   (ro-skl3-i5-6260u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-bdw-i5-5250u)
fail   -> PASS   (fi-skl-i7-6700k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-hsw-i7-4770k)

fi-hsw-i7-4770k  total:240  pass:218  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-qkkr  total:240  pass:182  dwarn:30  dfail:0   fail:2   skip:26 
fi-skl-i5-6260u  total:240  pass:224  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:240  pass:209  dwarn:0   dfail:0   fail:3   skip:28 
fi-snb-i7-2600   total:240  pass:198  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:4   dfail:0   fail:1   skip:16 
ro-bdw-i7-5557U  total:240  pass:223  dwarn:0   dfail:0   fail:1   skip:16 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:195  dwarn:0   dfail:0   fail:3   skip:42 
ro-byt-n2820 total:240  pass:198  dwarn:0   dfail:0   fail:2   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:173  dwarn:1   dfail:0   fail:1   skip:65 
ro-ilk1-i5-650   total:235  pass:172  dwarn:0   dfail:0   fail:3   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:221  dwarn:0   dfail:0   fail:4   skip:15 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1667/

862c995 drm-intel-nightly: 2016y-08m-02d-12h-12m-24s UTC integration manifest
012a950 drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation 
entry 2

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

Re: [Intel-gfx] [PATCH v6 09/10] drm/i915: Update bits per component for display info

[Daniel Vetter]

On Tue, Aug 02, 2016 at 02:41:25PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 02:23:13PM +0300, Mika Kahola wrote:
> > On Tue, 2016-07-12 at 15:51 +0200, Daniel Vetter wrote:
> > > On Wed, Jul 06, 2016 at 02:04:53PM +0300, Mika Kahola wrote:
> > > > DisplayPort branch device may define max supported bits per
> > > > component. Update display info based on this value if bpc
> > > > is defined.
> > > > 
> > > > v2: cleanup to match the drm_dp_helper.c patches introduced
> > > > earlier in this series
> > > > 
> > > > Signed-off-by: Mika Kahola 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 9 +
> > > >  1 file changed, 9 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 76a654e..53ec844 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -3932,6 +3932,14 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > > > uint8_t *dpcd = intel_dp->dpcd;
> > > > uint8_t type;
> > > >  
> > > > +   if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT) 
> > > > {
> > > > +   int bpc = drm_dp_downstream_max_bpc(dpcd,
> > > > +   
> > > > intel_dp->downstream_ports);
> > > > +
> > > > +   if (bpc > 0)
> > > > +   
> > > > intel_dp->attached_connector->base.display_info.bpc = bpc;
> > > > +   }
> > > 
> > > I think a function in the dp helpers to correctly fill out the connector's
> > > display info would be neater.
> > > -Daniel
> > Ok. I can move this stuff to be part of dp helper routine.
> 
> I'm not sure frobbing with display_info is a good idea here since that
> that one has so far been the EDID parsers domain. The ordering between
> all this stuff is already very poorly defined/buggy, so some bigger
> cleanup is probably needed. I have some patches to the EDID parser that
> I should send out that at least make it a bit clearer where it fills out
> the display_info stuff.

+1 for bigger cleanup. A helper which does all the dp sink detection
(grabs edid, dpcd and everything else and then computes restrictions)
would be _real_ awesome I think. Even better if you can trick some other
driver into using it too.

Tomeu from collabora just volunteered himself to clean up the analogix dp
support and switch over to the helpers. He's rather active on irc, so
great guinea-pig to volutneer for this and work together with.
-Daniel

> 
> > Cheers,
> > Mika
> > > 
> > > > +
> > > > if (!intel_dp_get_dpcd(intel_dp))
> > > > return connector_status_disconnected;
> > > >  
> > > > @@ -3968,6 +3976,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > > > return connector_status_unknown;
> > > > }
> > > >  
> > > > +
> > > > /* Anything else is out of spec, warn and ignore */
> > > > DRM_DEBUG_KMS("Broken DP branch device, ignoring\n");
> > > > return connector_status_disconnected;
> > > > -- 
> > > > 1.9.1
> > > > 
> > > 
> > 
> > -- 
> > Mika Kahola - Intel OTC
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Always use cpp==4 for FW_BLC_SELF on 915GM/945GM

[Ville Syrjälä]

On Fri, Jul 29, 2016 at 03:21:00PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915: Always use cpp==4 for 
> FW_BLC_SELF on 915GM/945GM
> URL   : https://patchwork.freedesktop.org/series/10392/
> State : failure
> 
> == Summary ==
> 
> Series 10392v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/10392/revisions/1/mbox
> 
> Test drv_module_reload_basic:
> skip   -> PASS   (ro-ivb-i7-3770)
> skip   -> PASS   (ro-skl3-i5-6260u)
> Test kms_cursor_legacy:
> Subgroup basic-cursor-vs-flip-legacy:
> fail   -> PASS   (ro-ilk1-i5-650)
> Subgroup basic-cursor-vs-flip-varying-size:
> pass   -> FAIL   (ro-ilk1-i5-650)

(kms_cursor_legacy:8194) DEBUG: Using a target of 32 cursor updates per 
half-vblank
(kms_cursor_legacy:8194) WARNING: page flip 42 was delayed, missed 2 frames
(kms_cursor_legacy:8194) WARNING: page flip 44 was delayed, missed 1 frames
(kms_cursor_legacy:8194) WARNING: page flip 45 was delayed, missed 1 frames
(kms_cursor_legacy:8194) WARNING: page flip 47 was delayed, missed 2 frames
(kms_cursor_legacy:8194) WARNING: page flip 52 was delayed, missed 3 frames
(kms_cursor_legacy:8194) CRITICAL: Test assertion failure function 
basic_cursor_vs_flip, file kms_cursor_legacy.c:670:
(kms_cursor_legacy:8194) CRITICAL: Failed assertion: vbl.sequence == 
vblank_start + 60
(kms_cursor_legacy:8194) CRITICAL: error: 11522 != 11513

https://bugs.freedesktop.org/show_bug.cgi?id=96701

> Subgroup basic-flip-vs-cursor-legacy:
> pass   -> FAIL   (ro-bdw-i5-5250u)

(kms_cursor_legacy:8712) DEBUG: Test requirement passed: target > 1
(kms_cursor_legacy:8712) DEBUG: Using a target of 64 cursor updates per 
half-vblank
(kms_cursor_legacy:8712) CRITICAL: Test assertion failure function 
basic_flip_vs_cursor, file kms_cursor_legacy.c:514:
(kms_cursor_legacy:8712) CRITICAL: Failed assertion: 
get_vblank(display->drm_fd, pipe, 0) == vblank_start
(kms_cursor_legacy:8712) CRITICAL: error: 11091 != 11090

This subtests seems to be a bit different, so potentially a different problem,
and it happens on a lot of machines. Filed a new bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97188

> Subgroup basic-flip-vs-cursor-varying-size:
> fail   -> PASS   (ro-skl3-i5-6260u)
> 
> fi-kbl-qkkr  total:239  pass:181  dwarn:29  dfail:0   fail:3   skip:26 
> fi-skl-i5-6260u  total:239  pass:223  dwarn:0   dfail:0   fail:2   skip:14 
> fi-snb-i7-2600   total:239  pass:197  dwarn:0   dfail:0   fail:0   skip:42 
> ro-bdw-i5-5250u  total:239  pass:218  dwarn:4   dfail:0   fail:1   skip:16 
> ro-bdw-i7-5600u  total:239  pass:206  dwarn:0   dfail:0   fail:1   skip:32 
> ro-bsw-n3050 total:239  pass:193  dwarn:0   dfail:0   fail:4   skip:42 
> ro-hsw-i3-4010u  total:239  pass:213  dwarn:0   dfail:0   fail:0   skip:26 
> ro-hsw-i7-4770r  total:239  pass:213  dwarn:0   dfail:0   fail:0   skip:26 
> ro-ilk-i7-620lm  total:239  pass:171  dwarn:1   dfail:0   fail:2   skip:65 
> ro-ilk1-i5-650   total:234  pass:172  dwarn:0   dfail:0   fail:2   skip:60 
> ro-ivb-i7-3770   total:239  pass:204  dwarn:0   dfail:0   fail:0   skip:35 
> ro-ivb2-i7-3770  total:239  pass:208  dwarn:0   dfail:0   fail:0   skip:31 
> ro-skl3-i5-6260u total:239  pass:222  dwarn:0   dfail:0   fail:3   skip:14 
> ro-snb-i7-2620M  total:239  pass:196  dwarn:0   dfail:0   fail:2   skip:41 
> fi-hsw-i7-4770k failed to connect after reboot
> fi-skl-i7-6700k failed to connect after reboot
> ro-bdw-i7-5557U failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1644/
> 
> cb7629d drm-intel-nightly: 2016y-07m-28d-11h-02m-33s UTC integration manifest
> c06a5d8 drm/i915: Program FW_BLC_SELF on 915G as well
> 99ec8e7 drm/i915: Always use cpp==4 for FW_BLC_SELF on 915GM/945GM

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

Re: [Intel-gfx] [PATCH 0/9] drm: Store clipped coordinates in drm_plane_state

[Daniel Vetter]

On Mon, Aug 01, 2016 at 06:19:02PM +0300, Ville Syrjälä wrote:
> On Mon, Aug 01, 2016 at 11:12:05AM -0400, Sean Paul wrote:
> > On Tue, Jul 26, 2016 at 12:06 PM,   wrote:
> > > From: Ville Syrjälä 
> > >
> > > Moving the clipped plane coordinates into drm_plane_state has been
> > > discussed a few times, but as no patches seems to have materialized,
> > > I decoded to do it myself. I also added a new helper function
> > > like drm_plane_helper_check_update() that takes a plane state instead.
> > >
> > > I converted i915, rockchip, and mediatek over to the new stuff. rockchip
> > > already looked pretty solid, mediatek had some bugs in there that I
> > > hopefully fixed. The rest of the non-x86 drivers seem to entirely lack
> > > any plane clipping code, so I decided that I don't care enough to
> > > write it from scratch. I also converted drm_simple_kms_helper, but
> > > there are no drivers using it so far.
> > >
> > > I've only actually tested i915, the rest are just compile tested.
> > >
> > > Entire series available here:
> > > git://github.com/vsyrjala/linux.git plane_state_rects
> > >
> > > Ville Syrjälä (9):
> > >   drm: Warn about negative sizes when calculating scale factor
> > >   drm: Store clipped src/dst coordinatee in drm_plane_state
> > >   drm/plane-helper: Add drm_plane_helper_check_state()
> > >   drm/i915: Use drm_plane_state.{src,dst,visible}
> > >   drm/i915: Use drm_plane_helper_check_state()
> > >   drm/rockchip: Use drm_plane_state.{src,dst}
> > >   drm/rockchip: Use drm_plane_helper_check_state()
> > >   drm/mediatek: Use drm_plane_helper_check_state()
> > >   drm/simple_kms_helper: Use drm_plane_helper_check_state()
> > 
> > 
> > Looks good to me, all patches have been reviewed.
> > 
> > It seems like the only consumer of drm_plane_helper_check_update()
> > left is armada. Are you planning on converting it as well? Then we can
> > nuke the function.
> 
> IIRC that driver isn't atomic enough for the new function.

Yeah, I think no one has yet started an effort to make armada atomic :(
-Daniel

> 
> > 
> > Sean
> > 
> > >
> > >  drivers/gpu/drm/drm_plane_helper.c  | 136 
> > > +--
> > >  drivers/gpu/drm/drm_rect.c  |   2 +-
> > >  drivers/gpu/drm/drm_simple_kms_helper.c |  27 ++
> > >  drivers/gpu/drm/i915/intel_atomic_plane.c   |  18 +---
> > >  drivers/gpu/drm/i915/intel_display.c| 140 
> > > ++--
> > >  drivers/gpu/drm/i915/intel_drv.h|   3 -
> > >  drivers/gpu/drm/i915/intel_fbc.c|  12 +--
> > >  drivers/gpu/drm/i915/intel_pm.c |  60 ++--
> > >  drivers/gpu/drm/i915/intel_sprite.c |  94 ++-
> > >  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  72 --
> > >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  31 ++
> > >  include/drm/drm_crtc.h  |  13 +++
> > >  include/drm/drm_plane_helper.h  |   5 +
> > >  13 files changed, 315 insertions(+), 298 deletions(-)
> > >
> > > --
> > > 2.7.4
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Warn about aux msg buffer vs. size mismatch

[Ville Syrjälä]

On Thu, Jul 28, 2016 at 03:20:52PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Warn about aux msg buffer vs. size mismatch
> URL   : https://patchwork.freedesktop.org/series/10356/
> State : failure
> 
> == Summary ==
> 
> Series 10356v1 drm/i915: Warn about aux msg buffer vs. size mismatch
> http://patchwork.freedesktop.org/api/1.0/series/10356/revisions/1/mbox
> 
> Test drv_module_reload_basic:
> skip   -> PASS   (ro-ivb-i7-3770)
> skip   -> PASS   (ro-skl3-i5-6260u)
> Test kms_cursor_legacy:
> Subgroup basic-cursor-vs-flip-legacy:
> fail   -> PASS   (ro-ilk1-i5-650)
> Subgroup basic-cursor-vs-flip-varying-size:
> pass   -> FAIL   (ro-ilk1-i5-650)

(kms_cursor_legacy:7977) DEBUG: Test requirement passed: target > 1
(kms_cursor_legacy:7977) DEBUG: Using a target of 32 cursor updates per 
half-vblank
(kms_cursor_legacy:7977) WARNING: page flip 0 was delayed, missed 1 frames
(kms_cursor_legacy:7977) CRITICAL: Test assertion failure function 
basic_cursor_vs_flip, file kms_cursor_legacy.c:670:
(kms_cursor_legacy:7977) CRITICAL: Failed assertion: vbl.sequence == 
vblank_start + 60
(kms_cursor_legacy:7977) CRITICAL: error: 11594 != 11593

https://bugs.freedesktop.org/show_bug.cgi?id=96701

> Subgroup basic-flip-vs-cursor-legacy:
> fail   -> PASS   (fi-skl-i7-6700k)
> Subgroup basic-flip-vs-cursor-varying-size:
> fail   -> PASS   (ro-snb-i7-2620M)
> pass   -> FAIL   (ro-bdw-i5-5250u)

(kms_cursor_legacy:8640) DEBUG: Test requirement passed: target > 1
(kms_cursor_legacy:8640) DEBUG: Using a target of 64 cursor updates per 
half-vblank
(kms_cursor_legacy:8640) CRITICAL: Test assertion failure function 
basic_flip_vs_cursor, file kms_cursor_legacy.c:514:
(kms_cursor_legacy:8640) CRITICAL: Failed assertion: 
get_vblank(display->drm_fd, pipe, 0) == vblank_start
(kms_cursor_legacy:8640) CRITICAL: error: 12134 != 12133

https://bugs.freedesktop.org/show_bug.cgi?id=97188

> fi-hsw-i7-4770k  total:239  pass:217  dwarn:0   dfail:0   fail:0   skip:22 
> fi-kbl-qkkr  total:239  pass:180  dwarn:29  dfail:0   fail:3   skip:27 
> fi-skl-i7-6700k  total:239  pass:208  dwarn:0   dfail:0   fail:3   skip:28 
> fi-snb-i7-2600   total:239  pass:197  dwarn:0   dfail:0   fail:0   skip:42 
> ro-bdw-i5-5250u  total:239  pass:218  dwarn:4   dfail:0   fail:1   skip:16 
> ro-bdw-i7-5600u  total:239  pass:206  dwarn:0   dfail:0   fail:1   skip:32 
> ro-bsw-n3050 total:239  pass:193  dwarn:0   dfail:0   fail:4   skip:42 
> ro-byt-n2820 total:239  pass:195  dwarn:0   dfail:0   fail:4   skip:40 
> ro-hsw-i7-4770r  total:239  pass:213  dwarn:0   dfail:0   fail:0   skip:26 
> ro-ilk1-i5-650   total:234  pass:172  dwarn:0   dfail:0   fail:2   skip:60 
> ro-ivb-i7-3770   total:239  pass:204  dwarn:0   dfail:0   fail:0   skip:35 
> ro-ivb2-i7-3770  total:239  pass:208  dwarn:0   dfail:0   fail:0   skip:31 
> ro-skl3-i5-6260u total:239  pass:221  dwarn:0   dfail:0   fail:4   skip:14 
> ro-snb-i7-2620M  total:239  pass:197  dwarn:0   dfail:0   fail:1   skip:41 
> fi-skl-i5-6260u failed to connect after reboot
> ro-bdw-i7-5557U failed to connect after reboot
> ro-ilk-i7-620lm failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1632/
> 
> cb7629d drm-intel-nightly: 2016y-07m-28d-11h-02m-33s UTC integration manifest
> cc80144 drm/i915: Warn about aux msg buffer vs. size mismatch

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

Re: [Intel-gfx] [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

[Daniel Vetter]

On Sun, Jul 31, 2016 at 12:54:51AM -0700, Keith Packard wrote:
> There are two paths into intel_cleanup_plane_fb, the normal completion
> path and the failure path.
> 
> In the failure case, intel_cleanup_plane_fb is called before
> drm_atomic_helper_swap_state, so any wait_req reference made in
> intel_prepare_plane_fb will be in old_intel_state->wait_req.
> 
> In the normal completion path, drm_atomic_helper_swap_state has
> already been called, so the plane state holding the just-used wait_req
> will not be in old_intel_state->wait_req, rather it will be in the
> state associated with the plane itself.
> 
> Clearing this reference ensures that the wait_req will be freed as
> soon as it the related mode setting operation is complete, rather than
> waiting for some future mode setting operation to eventually
> dereference it.
> 
> The existing dereference of old_intel_state->wait_req is still
> required as that will hold the wait_req when the mode setting
> operation fails.
> 
> cc: Daniel Vetter 
> cc: David Airlie 
> cc: intel-gfx@lists.freedesktop.org
> cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Keith Packard 

Hm, I think we should just clean up wiat_req in ->atomic_destroy_state
instead of littering cleanup code all over. But this gets the job done, so
applied.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3074c56..dbabaf3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13924,6 +13924,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
>   struct drm_device *dev = plane->dev;
>   struct intel_plane *intel_plane = to_intel_plane(plane);
>   struct intel_plane_state *old_intel_state;
> + struct intel_plane_state *intel_state = 
> to_intel_plane_state(plane->state);
>   struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
>   struct drm_i915_gem_object *obj = intel_fb_obj(plane->state->fb);
>  
> @@ -13941,6 +13942,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
>   (obj && !(obj->frontbuffer_bits & intel_plane->frontbuffer_bit)))
>   i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
>  
> + i915_gem_request_assign(&intel_state->wait_req, NULL);
>   i915_gem_request_assign(&old_intel_state->wait_req, NULL);
>  }
>  
> -- 
> 2.8.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Warn about aux msg buffer vs. size mismatch

[Ville Syrjälä]

On Thu, Jul 28, 2016 at 10:15:35PM +0200, Daniel Vetter wrote:
> On Thu, Jul 28, 2016 at 05:55:04PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > If we have have a buffer, we should also have a size, and vice versa.
> > Let's check it both ways instead of just one.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Daniel Vetter 

Pushed to dinq. Thanks for the review.

> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 21b04c3eda41..001f74fc0ce5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1041,10 +1041,10 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, 
> > struct drm_dp_aux_msg *msg)
> > if (WARN_ON(txsize > 20))
> > return -E2BIG;
> >  
> > +   WARN_ON(!msg->buffer != !msg->size);
> > +
> > if (msg->buffer)
> > memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
> > -   else
> > -   WARN_ON(msg->size);
> >  
> > ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
> > if (ret > 0) {
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Always use cpp==4 for FW_BLC_SELF on 915GM/945GM

[Ville Syrjälä]

On Fri, Jul 29, 2016 at 05:32:32PM +0100, Chris Wilson wrote:
> On Fri, Jul 29, 2016 at 05:57:01PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Bspec says:
> > "FW_BLC_SELF
> >  ...
> >  Programming Note [DevALV] and [DevCST]: When calculating watermark
> >  values for 15/16bpp, assume 32bpp for purposes of calculation using
> >  the high priority bandwidth analysis spreadsheet."
> 
> It does indeed.
> 
> > Let's do that.
> > 
> > Perhaps this might even help with the problem that resulted in
> > commit 2ab1bc9df01d ("drm/i915: Disable self-refresh for untiled fbs on 
> > i915gm")
> > 
> > Cc: Daniel Vetter 
> > Cc: Chris Wilson 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 1ac32428d4db..8cfef7683088 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -1604,6 +1604,9 @@ static void i9xx_update_wm(struct drm_crtc 
> > *unused_crtc)
> > unsigned long line_time_us;
> > int entries;
> >  
> > +   if (IS_I915GM(dev) || IS_I945GM(dev))
> > +   cpp = 4;
> > +
> 
> Reviewed-by: Chris Wilson 

Series pushed to dinq. Thanks for the reviews.

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

Re: [Intel-gfx] [PATCH] drm/i915: set proper N/M in modeset

[Yang, Libin]

Hi Ville

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, August 2, 2016 6:47 PM
> To: libin.y...@linux.intel.com
> Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, 
> Daniel
> ; ti...@suse.de; Yang, Libin 
> Subject: Re: [PATCH] drm/i915: set proper N/M in modeset
> 
> On Tue, Aug 02, 2016 at 09:35:10AM +0800, libin.y...@linux.intel.com wrote:
> > From: Libin Yang 
> >
> > When modeset occurs and the LS_CLK is set to some special values in DP
> > mode, the N/M need to be set manually if audio is playing.
> >
> > The relationship of Maud and Naud is expressed in the following
> > equation:
> > Maud/Naud = 512 * fs / f_LS_Clk
> >
> > Please refer VESA DisplayPort Standard spec for details.
> >
> > Also, the patch applies
> > commit 7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset") to APL
> > platform.
> >
> > Signed-off-by: Libin Yang 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h|   6 ++
> >  drivers/gpu/drm/i915/intel_audio.c | 122
> > +++--
> >  2 files changed, 111 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 8bfde75..2f9d00e 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7351,6 +7351,12 @@ enum {
> >  #define _HSW_AUD_CONFIG_B  0x65100
> >  #define HSW_AUD_CFG(pipe)  _MMIO_PIPE(pipe,
> _HSW_AUD_CONFIG_A, _HSW_AUD_CONFIG_B)
> >
> > +#define _HSW_AUD_M_CTS_ENABLE_A0x65028
> > +#define _HSW_AUD_M_CTS_ENABLE_B0x65128
> > +#define HSW_AUD_M_CTS_ENABLE(pipe) _MMIO_PIPE(pipe,
> _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> > +#define   AUD_M_CTS_M_VALUE_INDEX  (1 << 21)
> > +#define   AUD_M_CTS_M_PROG_ENABLE  (1 << 20)
> > +
> >  #define _HSW_AUD_MISC_CTRL_A   0x65010
> >  #define _HSW_AUD_MISC_CTRL_B   0x65110
> >  #define HSW_AUD_MISC_CTRL(pipe)_MMIO_PIPE(pipe,
> _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 6700a7b..de55ecf 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -98,6 +98,22 @@ static const struct {
> > { 192000, TMDS_297M, 20480, 247500 },  };
> >
> > +#define LC_540M 54
> > +#define LC_162M 162000
> 
> Do we have some explanation why 2.7 doesn't need M/N programming, but
> 1.62 and 5.4 do?

I didn't use 2.7 because I can't find a mode using 2.7. So I can't do the test.
5.4 is for 4K and 1.62 is for 1080p.

> 
> And I see you're only doing this on HSW+. Earlier platforms don't need this?

We are not supporting earlier platforms and I'm not sure whether the
old platforms supports 4K DP or not.

> 
> > +static const struct {
> > +   int sample_rate;
> > +   int clock;
> > +   int n;
> > +   int m;
> 
> Can save a bit of space by using u16 for m and n.

OK, I will do it in next version.

> 
> > +} aud_nm[] = {
> > +   {48000, LC_540M, 5625, 256},`
> > +   {44100, LC_540M, 9375, 392},
> > +   {32000, LC_540M, 16875, 512},
> > +   {48000, LC_162M, 3375, 512},
> > +   {44100, LC_162M, 5625, 784},
> > +   {32000, LC_162M, 10125, 1024
> > +};
> 
> The numbers look good, but what about other sample rates? For HDMI we go
> up to 192kHz, why not for DP?

Our test only includes 32K, 44.1K and 48K :)
I will add the support if you think we should.

> 
> > +
> >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */  static u32
> > audio_config_hdmi_pixel_clock(const struct drm_display_mode
> > *adjusted_mode)  { @@ -121,20 +137,50 @@ static u32
> > audio_config_hdmi_pixel_clock(const struct drm_display_mode *adjusted
> > return hdmi_audio_clock[i].config;
> >  }
> >
> > -static int audio_config_get_n(const struct drm_display_mode *mode,
> > int rate)
> > +static int audio_config_get_n(struct intel_crtc *crtc,
> > + const struct drm_display_mode *adjusted_mode,
> > + int rate)
> > +{
> > +   int i;
> > +
> > +   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) {
> > +   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> > +   if ((rate == aud_ncts[i].sample_rate) &&
> > +   (adjusted_mode->clock == aud_ncts[i].clock)) {
> > +   return aud_ncts[i].n;
> > +   }
> > +   }
> > +   }
> > +
> > +   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DP)) {
> > +   for (i = 0; i < ARRAY_SIZE(aud_nm); i++) {
> > +   if ((rate == aud_nm[i].sample_rate) &&
> > +   (crtc->config->port_clock == aud_nm[i].clock))
> {
> > +   return aud_nm[i].n;
> > +   }
> > +   }
> > +   }
> > +   return 0;
> > +}
> > +
> > +static int audio_config_get_m(struct intel_crtc *crtc, int rate)
> 

Re: [Intel-gfx] [PATCH] drm/i915: set proper N/M in modeset

[Yang, Libin]

Hi Jani,

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Tuesday, August 2, 2016 6:53 PM
> To: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; Vetter, Daniel ;
> ti...@suse.de
> Cc: Yang, Libin ; Libin Yang
> 
> Subject: Re: [PATCH] drm/i915: set proper N/M in modeset
> 
> On Tue, 02 Aug 2016, libin.y...@linux.intel.com wrote:
> > From: Libin Yang 
> >
> > When modeset occurs and the LS_CLK is set to some special values in DP
> > mode, the N/M need to be set manually if audio is playing.
> >
> > The relationship of Maud and Naud is expressed in the following
> > equation:
> > Maud/Naud = 512 * fs / f_LS_Clk
> >
> > Please refer VESA DisplayPort Standard spec for details.
> >
> > Also, the patch applies
> > commit 7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset") to APL
> > platform.
> 
> Whenever a commit message says "also", it makes me think the patch should
> probably be split to several patches. And that is certainly true here.

I will split the patch in next version.

Regards,
Libin

> 
> 
> --
> 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 0197/1285] Replace numeric parameter like 0444 with macro

[Daniel Vetter]

On Tue, Aug 02, 2016 at 02:37:37PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote:
> > I find that the developers often just specified the numeric value
> > when calling a macro which is defined with a parameter for access 
> > permission.
> > As we know, these numeric value for access permission have had the 
> > corresponding macro,
> > and that using macro can improve the robustness and readability of the code,
> > thus, I suggest replacing the numeric parameter with the macro.
> > 
> > Signed-off-by: Chuansheng Liu 
> > Signed-off-by: Baole Ni 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c | 64 
> > +++---
> >  1 file changed, 32 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 1779f02..7184e06 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -60,22 +60,22 @@ struct i915_params i915 __read_mostly = {
> > .inject_load_failure = 0,
> >  };
> >  
> > -module_param_named(modeset, i915.modeset, int, 0400);
> > +module_param_named(modeset, i915.modeset, int, S_IRUSR);
> 
> At least I can't read those macros. Octal is much clearer IMO.

Yeah, not really sold on this either.
-Daniel

> 
> >  MODULE_PARM_DESC(modeset,
> > "Use kernel modesetting [KMS] (0=disable, "
> > "1=on, -1=force vga console preference [default])");
> >  
> > -module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
> > 0600);
> > +module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
> > S_IRUSR | S_IWUSR);
> >  MODULE_PARM_DESC(panel_ignore_lid,
> > "Override lid status (0=autodetect, 1=autodetect disabled [default], "
> > "-1=force lid closed, -2=force lid open)");
> >  
> > -module_param_named_unsafe(semaphores, i915.semaphores, int, 0400);
> > +module_param_named_unsafe(semaphores, i915.semaphores, int, S_IRUSR);
> >  MODULE_PARM_DESC(semaphores,
> > "Use semaphores for inter-ring sync "
> > "(default: -1 (use per-chip defaults))");
> >  
> > -module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, 0400);
> > +module_param_named_unsafe(enable_rc6, i915.enable_rc6, int, S_IRUSR);
> >  MODULE_PARM_DESC(enable_rc6,
> > "Enable power-saving render C-state 6. "
> > "Different stages can be selected via bitmask values "
> > @@ -83,82 +83,82 @@ MODULE_PARM_DESC(enable_rc6,
> > "For example, 3 would enable rc6 and deep rc6, and 7 would enable 
> > everything. "
> > "default: -1 (use per-chip default)");
> >  
> > -module_param_named_unsafe(enable_dc, i915.enable_dc, int, 0400);
> > +module_param_named_unsafe(enable_dc, i915.enable_dc, int, S_IRUSR);
> >  MODULE_PARM_DESC(enable_dc,
> > "Enable power-saving display C-states. "
> > "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
> >  
> > -module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, 0600);
> > +module_param_named_unsafe(enable_fbc, i915.enable_fbc, int, S_IRUSR | 
> > S_IWUSR);
> >  MODULE_PARM_DESC(enable_fbc,
> > "Enable frame buffer compression for power savings "
> > "(default: -1 (use per-chip default))");
> >  
> > -module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
> > 0400);
> > +module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
> > S_IRUSR);
> >  MODULE_PARM_DESC(lvds_channel_mode,
> >  "Specify LVDS channel mode "
> >  "(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
> >  
> > -module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, 0600);
> > +module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, S_IRUSR | 
> > S_IWUSR);
> >  MODULE_PARM_DESC(lvds_use_ssc,
> > "Use Spread Spectrum Clock with panels [LVDS/eDP] "
> > "(default: auto from VBT)");
> >  
> > -module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, 
> > int, 0400);
> > +module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, 
> > int, S_IRUSR);
> >  MODULE_PARM_DESC(vbt_sdvo_panel_type,
> > "Override/Ignore selection of SDVO panel mode in the VBT "
> > "(-2=ignore, -1=auto [default], index in VBT BIOS table)");
> >  
> > -module_param_named_unsafe(reset, i915.reset, bool, 0600);
> > +module_param_named_unsafe(reset, i915.reset, bool, S_IRUSR | S_IWUSR);
> >  MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
> >  
> > -module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
> > 0644);
> > +module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
> > S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> >  MODULE_PARM_DESC(enable_hangcheck,
> > "Periodically check GPU activity for detecting hangs. "
> > "WARNING: Disabling this can cause system wide hangs. "
> > "(default: true)");
> >  
> > -module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
> > +module_param_named_unsafe(enabl

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Avoid mixing up SST and MST in DDI setup

[Daniel Vetter]

On Fri, Jul 29, 2016 at 12:55:20PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 29, 2016 at 11:16:19AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 28, 2016 at 05:50:39PM +0300, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > The MST vs. SST selection should depend purely on the choice of the
> > > connector/encoder. So don't try to determine the correct DDI mode
> > > based on the intel_dp->is_mst, which simply tells us whether the sink
> > > is in MST mode or not. Instead derive the information from the encoder
> > > type. Since the link training code deals in non-fake encoders, we'll
> > > also need to keep a second copy of that information around, which we'll
> > > now designate as 'link_mst'.
> > > 
> > > Cc: Maarten Lankhorst 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Hm, I think it'd be nice if we could shovel all this stuff into the crtc
> > state I think, instead of noodling it out of somewhere else.
> 
> You mean stuffing a pre-computed (partial?) register value in the
> crtc state? That could work too.

Yeah. But reading ahead I'm not sure where exactly we need to store that,
since recovering that with your sync_state rfc might get tricky.
-Daniel

> 
> > But since we
> > always update it in pre_enable hooks it should be all fine even with
> > TEST_ONLY atomic.
> > 
> > I digress, change looks good.
> > 
> > Reviewed-by: Daniel Vetter 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c | 21 +++--
> > >  drivers/gpu/drm/i915/intel_dp.c  |  1 +
> > >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> > >  3 files changed, 5 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index dd1d6fe12297..3b3a0a808477 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -,7 +,6 @@ void intel_ddi_enable_transcoder_func(struct 
> > > drm_crtc *crtc)
> > >  {
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >   struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
> > > - struct drm_encoder *encoder = &intel_encoder->base;
> > >   struct drm_device *dev = crtc->dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   enum pipe pipe = intel_crtc->pipe;
> > > @@ -1177,29 +1176,15 @@ void intel_ddi_enable_transcoder_func(struct 
> > > drm_crtc *crtc)
> > >   temp |= TRANS_DDI_MODE_SELECT_HDMI;
> > >   else
> > >   temp |= TRANS_DDI_MODE_SELECT_DVI;
> > > -
> > >   } else if (type == INTEL_OUTPUT_ANALOG) {
> > >   temp |= TRANS_DDI_MODE_SELECT_FDI;
> > >   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> > > -
> > >   } else if (type == INTEL_OUTPUT_DP ||
> > >  type == INTEL_OUTPUT_EDP) {
> > > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > -
> > > - if (intel_dp->is_mst) {
> > > - temp |= TRANS_DDI_MODE_SELECT_DP_MST;
> > > - } else
> > > - temp |= TRANS_DDI_MODE_SELECT_DP_SST;
> > > -
> > > + temp |= TRANS_DDI_MODE_SELECT_DP_SST;
> > >   temp |= DDI_PORT_WIDTH(intel_crtc->config->lane_count);
> > >   } else if (type == INTEL_OUTPUT_DP_MST) {
> > > - struct intel_dp *intel_dp = &enc_to_mst(encoder)->primary->dp;
> > > -
> > > - if (intel_dp->is_mst) {
> > > - temp |= TRANS_DDI_MODE_SELECT_DP_MST;
> > > - } else
> > > - temp |= TRANS_DDI_MODE_SELECT_DP_SST;
> > > -
> > > + temp |= TRANS_DDI_MODE_SELECT_DP_MST;
> > >   temp |= DDI_PORT_WIDTH(intel_crtc->config->lane_count);
> > >   } else {
> > >   WARN(1, "Invalid encoder type %d for pipe %c\n",
> > > @@ -2105,7 +2090,7 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
> > > *intel_dp)
> > >  
> > >   val = DP_TP_CTL_ENABLE |
> > > DP_TP_CTL_LINK_TRAIN_PAT1 | DP_TP_CTL_SCRAMBLE_DISABLE;
> > > - if (intel_dp->is_mst)
> > > + if (intel_dp->link_mst)
> > >   val |= DP_TP_CTL_MODE_MST;
> > >   else {
> > >   val |= DP_TP_CTL_MODE_SST;
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 8c38e3483989..0096c651c21f 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1651,6 +1651,7 @@ void intel_dp_set_link_params(struct intel_dp 
> > > *intel_dp,
> > >  {
> > >   intel_dp->link_rate = pipe_config->port_clock;
> > >   intel_dp->lane_count = pipe_config->lane_count;
> > > + intel_dp->link_mst = intel_crtc_has_type(pipe_config, 
> > > INTEL_OUTPUT_DP_MST);
> > >  }
> > >  
> > >  static void intel_dp_prepare(struct intel_encoder *encoder)
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index e74d851868c5..70d7f33d6747 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

[Daniel Vetter]

On Mon, Aug 01, 2016 at 11:18:15PM +0530, Kamble, Sagar A wrote:
> Reviewed-by: Sagar Arun Kamble  >

You're mailer wreaks havoc with your reviewed-by tags. Pleas fix this.


> On 6/27/2016 8:10 PM, akash.g...@intel.com wrote:
> > From: Akash Goel 
> > 
> > Updated the i915_drpc_info debugfs with coarse power gating & forcewake
> > info for Gen9.
> > 
> > v2: Change all IS_GEN9() by gen >= 9 (Damien)
> > 
> > v3: Rebase
> > 
> > Cc: Damien Lespiau 
> > Signed-off-by: Akash Goel 

Queued for -next, thanks for the patch.
-Daniel

> > ---
> >   drivers/gpu/drm/i915/i915_debugfs.c | 21 -
> >   drivers/gpu/drm/i915/i915_reg.h |  3 +++
> >   2 files changed, 23 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index f664884..5185e02 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1588,6 +1588,7 @@ static int gen6_drpc_info(struct seq_file *m)
> > struct drm_device *dev = node->minor->dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > u32 rpmodectl1, gt_core_status, rcctl1, rc6vids = 0;
> > +   u32 gen9_powergate_enable = 0, gen9_powergate_status = 0;
> > unsigned forcewake_count;
> > int count = 0, ret;
> > @@ -1615,6 +1616,10 @@ static int gen6_drpc_info(struct seq_file *m)
> > rpmodectl1 = I915_READ(GEN6_RP_CONTROL);
> > rcctl1 = I915_READ(GEN6_RC_CONTROL);
> > +   if (INTEL_INFO(dev)->gen >= 9) {
> > +   gen9_powergate_enable = I915_READ(GEN9_PG_ENABLE);
> > +   gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
> > +   }
> > mutex_unlock(&dev->struct_mutex);
> > mutex_lock(&dev_priv->rps.hw_lock);
> > sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, &rc6vids);
> > @@ -1633,6 +1638,12 @@ static int gen6_drpc_info(struct seq_file *m)
> >yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
> > seq_printf(m, "RC6 Enabled: %s\n",
> >yesno(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
> > +   if (INTEL_INFO(dev)->gen >= 9) {
> > +   seq_printf(m, "Render Well Gating Enabled: %s\n",
> > +   yesno(gen9_powergate_enable & GEN9_RENDER_PG_ENABLE));
> > +   seq_printf(m, "Media Well Gating Enabled: %s\n",
> > +   yesno(gen9_powergate_enable & GEN9_MEDIA_PG_ENABLE));
> > +   }
> > seq_printf(m, "Deep RC6 Enabled: %s\n",
> >yesno(rcctl1 & GEN6_RC_CTL_RC6p_ENABLE));
> > seq_printf(m, "Deepest RC6 Enabled: %s\n",
> > @@ -1661,6 +1672,14 @@ static int gen6_drpc_info(struct seq_file *m)
> > seq_printf(m, "Core Power Down: %s\n",
> >yesno(gt_core_status & GEN6_CORE_CPD_STATE_MASK));
> > +   if (INTEL_INFO(dev)->gen >= 9) {
> > +   seq_printf(m, "Render Power Well: %s\n",
> > +   (gen9_powergate_status &
> > +GEN9_PWRGT_RENDER_STATUS_MASK) ? "Up" : "Down");
> > +   seq_printf(m, "Media Power Well: %s\n",
> > +   (gen9_powergate_status &
> > +GEN9_PWRGT_MEDIA_STATUS_MASK) ? "Up" : "Down");
> > +   }
> > /* Not exactly sure what this is */
> > seq_printf(m, "RC6 \"Locked to RPn\" residency since boot: %u\n",
> > @@ -1678,7 +1697,7 @@ static int gen6_drpc_info(struct seq_file *m)
> >GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
> > seq_printf(m, "RC6++ voltage: %dmV\n",
> >GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
> > -   return 0;
> > +   return i915_forcewake_domains(m, NULL);
> >   }
> >   static int i915_drpc_info(struct seq_file *m, void *unused)
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index c6bfbf8..1c8d029 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6955,6 +6955,9 @@ enum {
> >   #define  ECOBUS   _MMIO(0xa180)
> >   #defineFORCEWAKE_MT_ENABLE(1<<5)
> >   #define  VLV_SPAREG2H _MMIO(0xA194)
> > +#define  GEN9_PWRGT_DOMAIN_STATUS  _MMIO(0xA2A0)
> > +#define   GEN9_PWRGT_MEDIA_STATUS_MASK (1 << 0)
> > +#define   GEN9_PWRGT_RENDER_STATUS_MASK(1 << 1)
> >   #define  GTFIFODBG_MMIO(0x12)
> >   #defineGT_FIFO_SBDEDICATE_FREE_ENTRY_CHV  (0x1f << 20)
> 

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


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

[Daniel Vetter]

On Tue, Aug 02, 2016 at 11:10:46AM +0100, Dave Gordon wrote:
> On 21/07/16 18:10, Dave Gordon wrote:
> > On 21/07/16 11:38, Tvrtko Ursulin wrote:
> > > 
> > > On 20/07/16 22:07, Rodrigo Vivi wrote:
> > > > please kill this _ucode variation that is just a alias to guc
> > > > instead
> > > 
> > > Not sure, it was added with a particular goal. Cc Dave in case he wants
> > > to comment.
> > > 
> > > Regards,
> > > Tvrtko
> > 
> > The comment is already in the source code, just above the lines that
> > this patch changes.
> > 
> > .Dave.
> 
> Which is to say that,
> +   having a GuC that can be used for command submission
> +   having a GuC that requires firmware before use
> are logically distinct properties, and are both subsets of
> * having GuC hardware.
> 
> We can *imagine* products that might:
> 
> (1) have a GuC that requires firmware before use ...
> (2) have a GuC with predefined but reloadable firmware ...
> (3) have a GuC that contains a permanent firmware image ...
>  x
> (a) ... which supports command submission but not SLPC
> (b) ... which supports both command submission and SLPC
> (c) ... which supports SLPC but not command submission
> 
> where all combinations are logically plausible, even though we only have
> (1a) in today's devices. So we might as well make future development easier
> rather than more difficult; it is always easier to make different things
> equivalent than to separate identical things into different cases.

Let's please not add code for everything we can imagine. If there's a
product in the pipeline for which the above is true then sure, makes sense
(but needs one of the generic "needed for future platforms" notice in the
commit message). Otherwise I'll vote to nuke the difference.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Reject mixing MST and SST/HDMI on the same digital port

[Daniel Vetter]

On Fri, Jul 29, 2016 at 02:28:26PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 29, 2016 at 11:19:18AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 28, 2016 at 05:50:40PM +0300, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > We can't mix MST with SST/HDMI on the same physical port, so we'll need
> > > to reject such configurations in check_digital_port_conflicts(). Nothing
> > > else will prevent this as MST has its fake encoders and its own connectors
> > > so the cloning checks won't catch this.
> > > 
> > > The same digital port can be used multiple times, but only if all the
> > > encoders involved are MST encoders, so we only want to check MST vs.
> > > SST/HDMI, not MST vs. MST. And SST/HDMI vs. SST/HDMI we already check.
> > > 
> > > Cc: Maarten Lankhorst 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > I'd be awesome if we could have some testcases for this. We can e.g. try
> > to enable HDMI without it being connected (it'll fall back to dvi mode),
> > so could use that to try enabling both hdmi and dp or dp mst out of sheer
> > nastiness. I don't even think we need to check that it gets rejected
> > correctly, just trying to do such a modeset on a broken kernel should
> > result in plenty of fireworks in dmesg (state checker for sure will be
> > unhapy) to make it obvious it's broken. Aka would absolutely love if this
> > patch gained a Testcase: line. Either way:
> 
> What I've occasionally used for testing is kms_setmode with a patch to
> ignore all errors from setcrtc so that it doesn't abort midway. IIRC
> last time I did that on eg. HSW there were plenty of state checker
> complaints. In its default state kms_setmode has a bit of a problem
> because it doesn't know about conflicting connectors, nor does it know
> if we're supposed to have one encoder per connector or pair of
> connectors (DDI vs. !DDI). And also IIRC encoder/connector stealing
> will wreac some extra havoc here. Not sure if there's a good way to
> try and fix it so that by default kms_setmode would really test
> what's it's pretending to test on all platforms.
> 
> I guess we could at least promote my hack to a proper command line
> option, so that we can try to feed as many combinations to the kernel
> as possible.

We could promote it to a full test using atomic. Do a TEST_ONLY atomic
commit, then a real one and compare whether results agree. And if there's
any noise on dmesg then also fall over (like we do with all tests).

Of course that doens't encode the expectations we have on all platforms,
but I'm not sure there's enough value in maintaining such a detailed
testcase. The above would be generic, could run everywhere, doesn't need
updating and should at least uncover any internal inconsistencies.
-Daniel

> 
> > 
> > Reviewed-by: Daniel Vetter 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 10 ++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index c4c1c85366de..a6699c76bef3 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -12305,6 +12305,7 @@ static bool check_digital_port_conflicts(struct 
> > > drm_atomic_state *state)
> > >   struct drm_device *dev = state->dev;
> > >   struct drm_connector *connector;
> > >   unsigned int used_ports = 0;
> > > + unsigned int used_mst_ports = 0;
> > >  
> > >   /*
> > >* Walk the connector list instead of the encoder
> > > @@ -12341,11 +12342,20 @@ static bool check_digital_port_conflicts(struct 
> > > drm_atomic_state *state)
> > >   return false;
> > >  
> > >   used_ports |= port_mask;
> > > + break;
> > > + case INTEL_OUTPUT_DP_MST:
> > > + used_mst_ports |=
> > > + 1 << enc_to_mst(&encoder->base)->primary->port;
> > > + break;
> > >   default:
> > >   break;
> > >   }
> > >   }
> > >  
> > > + /* can't mix MST and SST/HDMI on the same port */
> > > + if (used_ports & used_mst_ports)
> > > + return false;
> > > +
> > >   return true;
> > >  }
> > >  
> > > -- 
> > > 2.7.4
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Track active streams also for DP SST

[Daniel Vetter]

On Fri, Jul 29, 2016 at 11:36:40AM -0700, Jim Bride wrote:
> On Fri, Jul 29, 2016 at 02:36:23PM +0300, Ville Syrjälä wrote:
> > On Fri, Jul 29, 2016 at 11:22:32AM +0200, Daniel Vetter wrote:
> > > On Thu, Jul 28, 2016 at 05:50:41PM +0300, ville.syrj...@linux.intel.com 
> > > wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > s/active_mst_links/active_streams/ and use it also for SST. We can then
> > > > use this information in the hpd handling to see if the link is active
> > > > or not, and thus whether we may need to retrain.
> > > > 
> > > > Cc: Ander Conselvan de Oliveira 
> > > > Cc: Jim Bride 
> > > > Cc: Manasi D Navare 
> > > > Cc: Durgadoss R 
> > > > Signed-off-by: Ville Syrjälä 
> > > 
> > > Hm, more state not in the state structures, and not cross-checked :( Ben
> > > Skeggs just pinged me on this, and one of the ideas he's now looking into
> > > is a separate state array for mst ports to fully keep track of this. Kinda
> > > like we keep track of the shared dplls.
> > 
> > Yeah it's a bit a mess. The other option I've outlined before might be a
> > fake crtc to drive the primary, and then use atomic enable/disable it at
> > the right time depending the state the of the actual MST streams.

Was more thinking of tracking a intel_dp_mst_port_state per mst capable
port. And then treating it similarly to how we treat the shared dpll,
including state readout, tracking, checking and all that. Fake crtc seems
like abusing the wrong concept.

But tbh I'm not entirely sure what really makes the most sense, maybe
better to keep on stitching stuff together to at least fix the bugs for
now.

> > Speaking of atomic/mst, I'm not sure our link retraining is really good
> > enough for MST. IIRC I saw a note in the spec that the payloads and
> > whatnot might get deallocated by the sink/hub if the link drops. I think
> > I have to re-read the spec a few times to make sure, but if that's the
> > case then we'd have to pimp up the link retraining to be MST aware. But,
> > I had an alternative idea recently; What if we just force a modeset on
> > all the pipes on that port? IIRC the spec even says that for link
> > retraining we should really be doing more or less the full modeset
> > sequence. It should also get rid of the FIFO underruns we now get every
> > time we retrain the link. Any thoughts?
> 
> If we ensure that we train the link at the widest and fastest configuration
> possible in the first place (which is how I interpret what the DP spec says
> to do for link training) then we shouldn't be in a situation where we need
> to retrain the main link unless the link is lost, in which case all of the
> pipes & payloads associated with the link will need to be re-configured
> anyhow (since there's no guarantee that the link bandwidth will be the same
> once the re-training was done.)  This seems like a simpler solution, IMHO.

We already link train the widest/faster link for mst. And this is about
retraining when the link is lost.

One question I have on this plan is what happens for a full unplug. Atm I
think we expect userspace to do a full modeset and we won't reconnect the
current state to the replugged hw. This is a bit different from all other
connectors (and dp sst) where an accidental cable trip doesn't result in a
black screen (assuming userspace doesn't fix things up on its own).

But reconnecting our internal dp objects with the replugged physical ones
might be tricky, so not sure this is a feasible plane. Besides this it
makes sense.
-Daniel


> 
> Jim
> 
> 
> > > 
> > > Again just ideas, code looks correct.
> > > 
> > > Reviewed-by: Daniel Vetter 
> > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_ddi.c| 10 ++
> > > >  drivers/gpu/drm/i915/intel_dp.c |  8 +++-
> > > >  drivers/gpu/drm/i915/intel_dp_mst.c | 16 
> > > >  drivers/gpu/drm/i915/intel_drv.h|  2 +-
> > > >  4 files changed, 26 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 3b3a0a808477..bc188ee6e37f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -1616,6 +1616,9 @@ static void intel_ddi_pre_enable(struct 
> > > > intel_encoder *intel_encoder)
> > > >  
> > > > intel_ddi_init_dp_buf_reg(intel_encoder);
> > > >  
> > > > +   WARN_ON(intel_dp->active_streams != 0);
> > > > +   intel_dp->active_streams++;
> > > > +
> > > > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > > intel_dp_start_link_train(intel_dp);
> > > > if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
> > > > @@ -1733,6 +1736,13 @@ static void intel_disable_ddi(struct 
> > > > intel_encoder *intel_encoder)
> > > > intel_psr_disable(intel_dp);
> > > > intel_edp_backlight_off(intel_dp);
> > > > }
> > > > +
> > > > +   if (type ==

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

[Chris Wilson]

On Tue, Jul 12, 2016 at 02:39:47PM +0300, David Weinehall wrote:
> I'm feeling sorely tempted to treat this as a proper regression,
> and simply submit a revert patch, seeing as it slows down resume by
> something like 200ms, but seeing as there was mention of a case where
> incorrect EDID-information might end up being read after resume on some
> Chromebooks, I'll just try to open a discussion instead.

Wrt https://bugs.freedesktop.org/show_bug.cgi?id=97139 this is a
regression and I'll ack the revert. Yes, we need to resolve exactly how
we get a stall between intel_hdmi_detect() and pageflip/cursor, but the
onus is on the submitter of the patch to fix existing issues first to
prevent such regressions (if possible, or else mitigate them).
-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: Add missing ring_mask to Pineview

[Daniel Vetter]

On Fri, Jul 29, 2016 at 12:10:30PM +0100, Chris Wilson wrote:
> On Fri, Jul 29, 2016 at 10:57:49AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 29, 2016 at 11:42:24AM +0300, Joonas Lahtinen wrote:
> > > On pe, 2016-07-29 at 00:45 +0100, Chris Wilson wrote:
> > > > It appears that we never told Pineview it has a RENDER_RING. This was
> > > > all fine until we started using the ring_mask for determining all the
> > > > available rings to initialise for legacy ringbuffer submission in commit
> > > > 88d2ba2e95c8 ("drm/i915: Unify engine init loop"). Though really it is a
> > > > latent bug since the ring_mask inception in commit 73ae478cdf6a
> > > > ("drm/i915: Replace has_bsd/blt/vebox with a mask").
> > > > 
> > > > To prevent similar mishaps in future, add a WARN_ON() if we find
> > > > ourselves with a device without any rings.
> > > > 
> > > > Fixes: 73ae478cdf6a ("drm/i915: Replace has_bsd/blt/vebox with a mask")
> > > > Fixes: 88d2ba2e95c8 ("drm/i915: Unify engine init loop")
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: Daniel Vetter 
> > > > Cc: Ben Widawsky 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_pci.c| 1 +
> > > >  drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
> > > >  2 files changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > > b/drivers/gpu/drm/i915/i915_pci.c
> > > > index 949c01686a66..2587b1bd41f4 100644
> > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > @@ -173,6 +173,7 @@ static const struct intel_device_info 
> > > > intel_pineview_info = {
> > > >     .gen = 3, .is_g33 = 1, .is_pineview = 1, .is_mobile = 1, 
> > > > .num_pipes = 2,
> > > >     .need_gfx_hws = 1, .has_hotplug = 1,
> > > >     .has_overlay = 1,
> > > > +   .ring_mask = RENDER_RING,
> > > >     GEN_DEFAULT_PIPEOFFSETS,
> > > >     CURSOR_OFFSETS,
> > > >  };
> > > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > > > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > index 31d43dfa7469..e6422aac2919 100644
> > > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > @@ -117,6 +117,7 @@ int intel_engines_init(struct drm_device *dev)
> > > >     unsigned int i;
> > > >     int ret;
> > > >  
> > > > +   WARN_ON(INTEL_INFO(dev_priv)->ring_mask == 0);
> > > 
> > > Reviewed-by: Joonas Lahtinen 
> > 
> > dim says this also needs a
> > 
> > Cc: drm-intel-fi...@lists.freedesktop.org
> 
> dim says nothing of the sort for me. The bug is only relevant from
> 88d2ba2e95c8

$ dim fixes 88d2ba2e95c8
Fixes: 88d2ba2e95c8 ("drm/i915: Move common engine setup into 
intel_engine_cs.c")
Cc: drm-intel-fi...@lists.freedesktop.org

Cc: -fixes is for the current -rc, which the above seems to have escaped
into.

Cc: -stable is for when it also needs to hit the stable kernels (which in
this case is indeed not needed).

So yeah I think it needs Cc: -fixes, for 4.8.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0197/1285] Replace numeric parameter like 0444 with macro

[Lukas Wunner]

On Tue, Aug 02, 2016 at 02:37:37PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote:
> > I find that the developers often just specified the numeric value
> > when calling a macro which is defined with a parameter for access 
> > permission.
> > As we know, these numeric value for access permission have had the 
> > corresponding macro,
> > and that using macro can improve the robustness and readability of the code,
> > thus, I suggest replacing the numeric parameter with the macro.
> > 
> > Signed-off-by: Chuansheng Liu 
> > Signed-off-by: Baole Ni 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c | 64 
> > +++---
> >  1 file changed, 32 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 1779f02..7184e06 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -60,22 +60,22 @@ struct i915_params i915 __read_mostly = {
> > .inject_load_failure = 0,
> >  };
> >  
> > -module_param_named(modeset, i915.modeset, int, 0400);
> > +module_param_named(modeset, i915.modeset, int, S_IRUSR);
> 
> At least I can't read those macros. Octal is much clearer IMO.

It's also easier to grep for, say, 644, rather than formulating a
regex with all possible ordering permutations of these macros.

Best regards,

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

Re: [Intel-gfx] [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount of cascading failures

[Daniel Vetter]

On Mon, Aug 01, 2016 at 10:33:17AM +0100, Peter Antoine wrote:
> On Mon, 1 Aug 2016, Chris Wilson wrote:
> 
> > On Fri, Jul 29, 2016 at 10:34:36AM +0100, Peter Antoine wrote:
> > > If one of the previous tests fails then the following tests fail.
> > > This patch means that the following tests do not fail when the previous
> > > test fails (for some cases).
> > 
> > The problem is just gem_mocs_settings hasn't split its tests up into
> > subtests.
> Chris,
> 
> Can you expand? The tests are at the minimal size for sensible results (I
> think). The problem is opening the driver for master when the test fails
> then the following tests will fail as master is not closed.
> 
> Is there a mechanism in the igt framework for doing this close on
> failure/skip?
> 
> If I move the master open code in the fixtures will this get called on all
> exit cases?

For a real test runner you need to run each individual subtest separate
(to avoid contamination). Then process exit will take care of any cleanup
needed with file descriptors. For anything else there's exit handlers, but
they're not 100% reliable

Adding hacks to make subtest runs differently isn't really how igt tests
are meant to be. Hence I concure on Chris' objection here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add missing ring_mask to Pineview

[Chris Wilson]

On Tue, Aug 02, 2016 at 04:34:25PM +0200, Daniel Vetter wrote:
> On Fri, Jul 29, 2016 at 12:10:30PM +0100, Chris Wilson wrote:
> > On Fri, Jul 29, 2016 at 10:57:49AM +0200, Daniel Vetter wrote:
> > > On Fri, Jul 29, 2016 at 11:42:24AM +0300, Joonas Lahtinen wrote:
> > > > On pe, 2016-07-29 at 00:45 +0100, Chris Wilson wrote:
> > > > > It appears that we never told Pineview it has a RENDER_RING. This was
> > > > > all fine until we started using the ring_mask for determining all the
> > > > > available rings to initialise for legacy ringbuffer submission in 
> > > > > commit
> > > > > 88d2ba2e95c8 ("drm/i915: Unify engine init loop"). Though really it 
> > > > > is a
> > > > > latent bug since the ring_mask inception in commit 73ae478cdf6a
> > > > > ("drm/i915: Replace has_bsd/blt/vebox with a mask").
> > > > > 
> > > > > To prevent similar mishaps in future, add a WARN_ON() if we find
> > > > > ourselves with a device without any rings.
> > > > > 
> > > > > Fixes: 73ae478cdf6a ("drm/i915: Replace has_bsd/blt/vebox with a 
> > > > > mask")
> > > > > Fixes: 88d2ba2e95c8 ("drm/i915: Unify engine init loop")
> > > > > Signed-off-by: Chris Wilson 
> > > > > Cc: Tvrtko Ursulin 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Ben Widawsky 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_pci.c| 1 +
> > > > >  drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
> > > > >  2 files changed, 2 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > > > b/drivers/gpu/drm/i915/i915_pci.c
> > > > > index 949c01686a66..2587b1bd41f4 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > > @@ -173,6 +173,7 @@ static const struct intel_device_info 
> > > > > intel_pineview_info = {
> > > > >   .gen = 3, .is_g33 = 1, .is_pineview = 1, .is_mobile = 1, 
> > > > > .num_pipes = 2,
> > > > >   .need_gfx_hws = 1, .has_hotplug = 1,
> > > > >   .has_overlay = 1,
> > > > > + .ring_mask = RENDER_RING,
> > > > >   GEN_DEFAULT_PIPEOFFSETS,
> > > > >   CURSOR_OFFSETS,
> > > > >  };
> > > > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > > > > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > > index 31d43dfa7469..e6422aac2919 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > > @@ -117,6 +117,7 @@ int intel_engines_init(struct drm_device *dev)
> > > > >   unsigned int i;
> > > > >   int ret;
> > > > >  
> > > > > + WARN_ON(INTEL_INFO(dev_priv)->ring_mask == 0);
> > > > 
> > > > Reviewed-by: Joonas Lahtinen 
> > > 
> > > dim says this also needs a
> > > 
> > > Cc: drm-intel-fi...@lists.freedesktop.org
> > 
> > dim says nothing of the sort for me. The bug is only relevant from
> > 88d2ba2e95c8
> 
> $ dim fixes 88d2ba2e95c8

What state does dim fixes depend upon? If did not report anything when I
ran it against the patch before pushing.
-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] [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount of cascading failures

[Antoine, Peter]

They do run separately. It's just that when one fails it does not close the fd 
and the next cannot open it as master.
Is there a mechanism for closing the fd (or any other tidy up on close.failure).

As the test runner implements a psudo exception handler it should really have a 
"final"/"skip" handler so that the tidyup can be done cleanly.

That was the question that was asked and not answered.

Peter. 

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, August 2, 2016 3:37 PM
To: Antoine, Peter 
Cc: Chris Wilson ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount 
of cascading failures

On Mon, Aug 01, 2016 at 10:33:17AM +0100, Peter Antoine wrote:
> On Mon, 1 Aug 2016, Chris Wilson wrote:
> 
> > On Fri, Jul 29, 2016 at 10:34:36AM +0100, Peter Antoine wrote:
> > > If one of the previous tests fails then the following tests fail.
> > > This patch means that the following tests do not fail when the 
> > > previous test fails (for some cases).
> > 
> > The problem is just gem_mocs_settings hasn't split its tests up into 
> > subtests.
> Chris,
> 
> Can you expand? The tests are at the minimal size for sensible results 
> (I think). The problem is opening the driver for master when the test 
> fails then the following tests will fail as master is not closed.
> 
> Is there a mechanism in the igt framework for doing this close on 
> failure/skip?
> 
> If I move the master open code in the fixtures will this get called on 
> all exit cases?

For a real test runner you need to run each individual subtest separate (to 
avoid contamination). Then process exit will take care of any cleanup needed 
with file descriptors. For anything else there's exit handlers, but they're not 
100% reliable

Adding hacks to make subtest runs differently isn't really how igt tests are 
meant to be. Hence I concure on Chris' objection here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

[Jindal, Sonika]

Yes we had the issue of incorrect edid read.
But as of now you can go ahead with the revert.
I have moved to a different group, so I am not working on this anymore.

Regards,
Sonika

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Tuesday, August 2, 2016 8:02 PM
To: Daniel Vetter ; Jindal, Sonika ; 
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading 
edid

On Tue, Jul 12, 2016 at 02:39:47PM +0300, David Weinehall wrote:
> I'm feeling sorely tempted to treat this as a proper regression, and 
> simply submit a revert patch, seeing as it slows down resume by 
> something like 200ms, but seeing as there was mention of a case where 
> incorrect EDID-information might end up being read after resume on 
> some Chromebooks, I'll just try to open a discussion instead.

Wrt https://bugs.freedesktop.org/show_bug.cgi?id=97139 this is a regression and 
I'll ack the revert. Yes, we need to resolve exactly how we get a stall between 
intel_hdmi_detect() and pageflip/cursor, but the onus is on the submitter of 
the patch to fix existing issues first to prevent such regressions (if 
possible, or else mitigate them).
-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: cleanup_plane_fb: also drop reference to current state wait_req

[Keith Packard]

Daniel Vetter  writes:

> Hm, I think we should just clean up wiat_req in ->atomic_destroy_state
> instead of littering cleanup code all over. But this gets the job done, so
> applied.

Thanks. It's required for the DRM patch I posted that makes moving the
cursor not block on rendering. I'm hoping Dave will get that merged for
4.8; it's really annoying to have the server moving the cursor in a
separate thread and then have the motion blocked in the kernel for a few
seconds worth of rendering.

-- 
-keith


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

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

[Maarten Lankhorst]

Op 01-08-16 om 13:48 schreef Ville Syrjälä:
> On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote:
>> Op 29-07-16 om 22:33 schreef Matt Roper:
>>> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
 On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
> This is completely untested (and probably horribly broken/buggy), but
> here's a quick mockup of the general approach I was thinking for
> ensuring DDB & WM's can be updated together while ensuring the
> three-step pipe flushing process is honored:
>
> https://github.com/mattrope/kernel/commits/experimental/lyude_ddb
>
> Basically the idea is to take note of what's happening to the pipe's DDB
> allocation (shrinking, growing, unchanged, etc.) during the atomic check
> phase;
 Didn't look too closely, but I think you can't actually do that unless
 you lock all the crtcs whenever the number of active pipes is goind to
 change. Meaning we'd essentially be back to the one-big-modeset-lock
 apporach, which will cause missed flips and whanot on the other pipes.

 The alternative I think would consist of:
 - make sure level 0 watermark never exceeds total_ddb_size/max_pipes,
   so that a modeset doesn't have to care about the wms for the other
   pipes not fitting in
>>> Unfortunately this part is the problem.  You might get away with doing
>>> this on SKL/KBL which only have three planes max per pipe and a large
>>> (896 block) DDB, but on BXT you have up to four planes (we don't
>>> actually enable the topmost plane in a full-featured manner just yet,
>>> but need to soon), yet the total DDB is only 512 blocks.  Sadly, the
>>> platform with more planes was given a smaller DDB...   :-(
>>> We're already in trouble because users that are running setups like 3x
>>> 4K with most/all planes in use at large sizes can't find level 0
>>> watermarks that satisfy their needs and we have to reject the whole
>>> configuration.  If we further limit each pipe's usage to total/maxpipes
>>> (i.e., 170 blocks per pipe on BXT), then we're going to hit similar
>>> issues when only driving one or two displays with with all of the planes
>>> in use, even though we should have had more DDB space to work with.
>>>
>>> I guess serious plane usage isn't too common in desktop setups today,
>>> but it's a very critical feature in the embedded world; we can't really
>>> afford to cripple plane usage further.  Unfortunately, as you point out
>>> above, this means that we have to follow the bspec's DDB allocation
>>> method, which in turn means we need to grab _all_ CRTC locks any time
>>> _any_ CRTC is being turned on or turned off which is a BKL-style way of
>>> doing things.
>> Meh, I'm running into a similar issue on vlv/chv. I don't see a way around 
>> it. :(
> Now are you hitting it w/ vlv/chv? They don't even have a shared DDB.
Not really the same, but determining what power saving levels + values to set 
with possibly parallel updates.

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

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

[Ville Syrjälä]

On Tue, Aug 02, 2016 at 05:41:50PM +0200, Maarten Lankhorst wrote:
> Op 01-08-16 om 13:48 schreef Ville Syrjälä:
> > On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote:
> >> Op 29-07-16 om 22:33 schreef Matt Roper:
> >>> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
>  On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
> > This is completely untested (and probably horribly broken/buggy), but
> > here's a quick mockup of the general approach I was thinking for
> > ensuring DDB & WM's can be updated together while ensuring the
> > three-step pipe flushing process is honored:
> >
> > 
> > https://github.com/mattrope/kernel/commits/experimental/lyude_ddb
> >
> > Basically the idea is to take note of what's happening to the pipe's DDB
> > allocation (shrinking, growing, unchanged, etc.) during the atomic check
> > phase;
>  Didn't look too closely, but I think you can't actually do that unless
>  you lock all the crtcs whenever the number of active pipes is goind to
>  change. Meaning we'd essentially be back to the one-big-modeset-lock
>  apporach, which will cause missed flips and whanot on the other pipes.
> 
>  The alternative I think would consist of:
>  - make sure level 0 watermark never exceeds total_ddb_size/max_pipes,
>    so that a modeset doesn't have to care about the wms for the other
>    pipes not fitting in
> >>> Unfortunately this part is the problem.  You might get away with doing
> >>> this on SKL/KBL which only have three planes max per pipe and a large
> >>> (896 block) DDB, but on BXT you have up to four planes (we don't
> >>> actually enable the topmost plane in a full-featured manner just yet,
> >>> but need to soon), yet the total DDB is only 512 blocks.  Sadly, the
> >>> platform with more planes was given a smaller DDB...   :-(
> >>> We're already in trouble because users that are running setups like 3x
> >>> 4K with most/all planes in use at large sizes can't find level 0
> >>> watermarks that satisfy their needs and we have to reject the whole
> >>> configuration.  If we further limit each pipe's usage to total/maxpipes
> >>> (i.e., 170 blocks per pipe on BXT), then we're going to hit similar
> >>> issues when only driving one or two displays with with all of the planes
> >>> in use, even though we should have had more DDB space to work with.
> >>>
> >>> I guess serious plane usage isn't too common in desktop setups today,
> >>> but it's a very critical feature in the embedded world; we can't really
> >>> afford to cripple plane usage further.  Unfortunately, as you point out
> >>> above, this means that we have to follow the bspec's DDB allocation
> >>> method, which in turn means we need to grab _all_ CRTC locks any time
> >>> _any_ CRTC is being turned on or turned off which is a BKL-style way of
> >>> doing things.
> >> Meh, I'm running into a similar issue on vlv/chv. I don't see a way around 
> >> it. :(
> > Now are you hitting it w/ vlv/chv? They don't even have a shared DDB.
> Not really the same, but determining what power saving levels + values to set 
> with possibly parallel updates.

Just like ILK we just need to track reasonably closely how many pipes
are active, and redo the wm level selection when that changes. Just
make sure the code never thinks there are less pipes active than in
reality, and it should all be safe.

In theory we wouldn't even need to do that since the PM5/DDR DVFS don't
actually depend on the number of active pipes. It's just that they never
validated that combination, so it's not something that's recommended to
be used. And since the whole DDR DVFS extra latency vs. DDL deadlines
is such a mess, it probably would end up in more underruns.

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

Re: [Intel-gfx] [PATCH] drm/i915: set proper N/M in modeset

[Ville Syrjälä]

On Tue, Aug 02, 2016 at 01:58:51PM +, Yang, Libin wrote:
> Hi Ville
> 
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, August 2, 2016 6:47 PM
> > To: libin.y...@linux.intel.com
> > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, 
> > Daniel
> > ; ti...@suse.de; Yang, Libin 
> > Subject: Re: [PATCH] drm/i915: set proper N/M in modeset
> > 
> > On Tue, Aug 02, 2016 at 09:35:10AM +0800, libin.y...@linux.intel.com wrote:
> > > From: Libin Yang 
> > >
> > > When modeset occurs and the LS_CLK is set to some special values in DP
> > > mode, the N/M need to be set manually if audio is playing.
> > >
> > > The relationship of Maud and Naud is expressed in the following
> > > equation:
> > > Maud/Naud = 512 * fs / f_LS_Clk
> > >
> > > Please refer VESA DisplayPort Standard spec for details.
> > >
> > > Also, the patch applies
> > > commit 7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset") to APL
> > > platform.
> > >
> > > Signed-off-by: Libin Yang 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h|   6 ++
> > >  drivers/gpu/drm/i915/intel_audio.c | 122
> > > +++--
> > >  2 files changed, 111 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 8bfde75..2f9d00e 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7351,6 +7351,12 @@ enum {
> > >  #define _HSW_AUD_CONFIG_B0x65100
> > >  #define HSW_AUD_CFG(pipe)_MMIO_PIPE(pipe,
> > _HSW_AUD_CONFIG_A, _HSW_AUD_CONFIG_B)
> > >
> > > +#define _HSW_AUD_M_CTS_ENABLE_A  0x65028
> > > +#define _HSW_AUD_M_CTS_ENABLE_B  0x65128
> > > +#define HSW_AUD_M_CTS_ENABLE(pipe)   _MMIO_PIPE(pipe,
> > _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> > > +#define   AUD_M_CTS_M_VALUE_INDEX(1 << 21)
> > > +#define   AUD_M_CTS_M_PROG_ENABLE(1 << 20)
> > > +
> > >  #define _HSW_AUD_MISC_CTRL_A 0x65010
> > >  #define _HSW_AUD_MISC_CTRL_B 0x65110
> > >  #define HSW_AUD_MISC_CTRL(pipe)  _MMIO_PIPE(pipe,
> > _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 6700a7b..de55ecf 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -98,6 +98,22 @@ static const struct {
> > >   { 192000, TMDS_297M, 20480, 247500 },  };
> > >
> > > +#define LC_540M 54
> > > +#define LC_162M 162000
> > 
> > Do we have some explanation why 2.7 doesn't need M/N programming, but
> > 1.62 and 5.4 do?
> 
> I didn't use 2.7 because I can't find a mode using 2.7.

Hmm. Maybe we should add some knobs to force a specific bpc/link rate/number
of lanes to help with this kind of testing. Currently you just get what
you get, which isn't so nice when you want to test all variations.
...
OK, so I just went ahead and did that. Here's a branch:

git://github.com/vsyrjala/linux.git modparam_clock_bpp_limit

For your DP testing just setting
i915.max_port_clock=162000 or i915.max_port_clock=27 and then
forcing a modeset should do the trick.

> So I can't do the test.
> 5.4 is for 4K and 1.62 is for 1080p.
> 
> > 
> > And I see you're only doing this on HSW+. Earlier platforms don't need this?
> 
> We are not supporting earlier platforms and I'm not sure whether the
> old platforms supports 4K DP or not.

SNB-IVB dotclock can go up to 360Mhz, ILK up to 405 Mhz. At least in
theory. The DP link is limited to 4 x 2.7 for all. From the those the
dotclock limit is the one you should hit first since DP can always fall
back to 6bpc and that should be correspond to a dotclock of 480 MHz.
Anyways, 360MHz is plenty for 4k@30.


The question really is why we need to do this in the first place.
There's nothing in the spec telling is it's really required. All I can
find in the DP spec is "Maud value is set to 2^15 (=32,768) when the
audio clock is asynchronous to the LS_Clk.", and then 

Thinking about it a bit more, on HSW+ we do drive DP ports with the
LCPLL, which is also reponsible for cdclk, and there are some vague
hints that audio may be clocked via cdclk. So if the DDI clock and the
audio clock are coming from the same reference, I suppose they are
considered synchronous, which may explain why this is needed. It's all
very poorly documented though, so I can't be sure.

As for the older platforms, the clocks are even less well documented.
The audio stuff is in the PCH, which is also where the DPLLs live, but
I have no idea where any audio clocks come from.

> 
> > 
> > > +static const struct {
> > > + int sample_rate;
> > > + int clock;
> > > + int n;
> > > + int m;
> > 
> > Can save a bit of space by using u16 for m and n.
> 
> OK, I will do it in next version.
> 
> > 
> > > +} aud_nm[] = {
> > > + {48000, LC_5

Re: [Intel-gfx] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

[Sedat Dilek]

On Mon, Aug 1, 2016 at 3:33 PM, Jani Nikula  wrote:
> On Fri, 15 Jul 2016, Sedat Dilek  wrote:
>> Hi,
>>
>> I see the below call-trace with latest d-i-n, guess latest linux-next
>
> FWIW, "d-i-n" is ambiguous (drm-intel-next vs. drm-intel-nightly) and we
> don't use that ourselves.
>

Oh, sorry with d-i-n I meant drm-intel-nightly.
Normally, I also point to the "integration manifest"
like...drm-intel-nightly: 2016y-08m-02d-14h-10m-12s UTC integration
manifest.
You do not test d-i-n yourself?
Strange.
The Ubuntu kernel-team is regularly building packages see [1] if you
did not know.

- Sedat -

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/

> BR,
> Jani.
>
>
>> will cause same issues.
>> ( Beyond this, there exist also a build failure which me and Stephen
>> have reported. )
>> The call-trace is reproducible with my setup and seen on every boot.
>>
>> Not sure if this is a problem in intel-gfx or fbdev.
>>
>> My linux-config and full dmesg-output is attached.
>>
>> If you need additional informations, please let me know.
>>
>> Regards,
>> - Sedat -
>>
>> [1] https://lists.freedesktop.org/archives/intel-gfx/2016-July/100693.html
>> [2] https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html
>>
>> P.S.: INFO: possible circular locking dependency detected
>>
>> [   16.955703] fbcon: inteldrmfb (fb0) is primary device
>> [   16.956579]
>> [   16.956580] ==
>> [   16.956581] [ INFO: possible circular locking dependency detected ]
>> [   16.956583] 4.7.0-rc7-4-iniza-small #1 Not tainted
>> [   16.956583] ---
>> [   16.956585] kworker/u16:1/79 is trying to acquire lock:
>> [   16.956618]  (&dev->mode_config.mutex){+.+.+.}, at:
>> [] drm_modeset_lock_all+0x40/0x120 [drm]
>> [   16.956619]
>> [   16.956619] but task is already holding lock:
>> [   16.956626]  ((fb_notifier_list).rwsem){.+}, at:
>> [] __blocking_notifier_call_chain+0x35/0x70
>> [   16.956627]
>> [   16.956627] which lock already depends on the new lock.
>> [   16.956627]
>> [   16.956627]
>> [   16.956627] the existing dependency chain (in reverse order) is:
>> [   16.956631]
>> [   16.956631] -> #1 ((fb_notifier_list).rwsem){.+}:
>> [   16.956635][] lock_acquire+0x119/0x220
>> [   16.956639][] down_write+0x49/0x80
>> [   16.956642][]
>> blocking_notifier_chain_register+0x21/0xb0
>> [   16.956646][] fb_register_client+0x18/0x20
>> [   16.956648][] 
>> backlight_device_register+0x12b/0x240
>> [   16.956710][]
>> intel_backlight_device_register+0xa2/0x170 [i915]
>> [   16.956764][]
>> intel_connector_register+0xe/0x10 [i915]
>> [   16.956778][]
>> drm_connector_register+0x4a/0x80 [drm]
>> [   16.956792][]
>> drm_modeset_register_all+0x163/0x1c0 [drm]
>> [   16.956805][] drm_dev_register+0xc2/0xd0 [drm]
>> [   16.956848][] i915_driver_load+0x753/0x13e0 
>> [i915]
>> [   16.956892][] i915_pci_probe+0x4f/0x70 [i915]
>> [   16.956896][] local_pci_probe+0x45/0xa0
>> [   16.956899][] pci_device_probe+0xdd/0x130
>> [   16.956901][] driver_probe_device+0x18e/0x2d0
>> [   16.956902][] __driver_attach+0x97/0xa0
>> [   16.956905][] bus_for_each_dev+0x66/0xa0
>> [   16.956908][] driver_attach+0x1e/0x20
>> [   16.956910][] bus_add_driver+0x1b8/0x230
>> [   16.956911][] driver_register+0x60/0xe0
>> [   16.956913][] __pci_register_driver+0x60/0x70
>> [   16.956949][] i915_init+0x5d/0x64 [i915]
>> [   16.956952][] do_one_initcall+0x3d/0x160
>> [   16.956954][] do_init_module+0x60/0x1dc
>> [   16.956957][] load_module+0x2012/0x2610
>> [   16.956959][] SYSC_init_module+0x126/0x140
>> [   16.956962][] SyS_init_module+0xe/0x10
>> [   16.956964][] 
>> entry_SYSCALL_64_fastpath+0x23/0xc1
>> [   16.956966]
>> [   16.956966] -> #0 (&dev->mode_config.mutex){+.+.+.}:
>> [   16.956968][] __lock_acquire+0x19ed/0x1aa0
>> [   16.956970][] lock_acquire+0x119/0x220
>> [   16.956971][] mutex_lock_nested+0x69/0x3c0
>> [   16.956988][] drm_modeset_lock_all+0x40/0x120 
>> [drm]
>> [   16.956998][]
>> drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
>> [   16.957004][]
>> drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
>> [   16.957043][] intel_fbdev_set_par+0x1a/0x60 
>> [i915]
>> [   16.957046][] fbcon_init+0x53c/0x5b0
>> [   16.957048][] visual_init+0xd6/0x130
>> [   16.957050][] do_bind_con_driver+0x167/0x3a0
>> [   16.957052][] do_take_over_console+0x12f/0x1a0
>> [   16.957054][] do_fbcon_takeover+0x57/0xb0
>> [   16.957056][] fbcon_event_notify+0x752/0x860
>> [   16.957058][] notifier_call_chain+0x5d/0x80
>> [   16.957060][]
>> __blocking_notifier_call_chain+0x4d/0x70
>> [   16

[Intel-gfx] [PATCH v5 0/6] Finally fix watermarks

[Lyude]

Next version of https://patchwork.freedesktop.org/series/10276/ .

Notable series-wide changes:
 - Added the following patches:
   - "drm/i915/skl: Ensure pipes with changed wms get added to the state"
   - "drm/i915: Move CRTC updating in atomic_commit into it's own hook"
   - "drm/i915/skl: Update DDB values atomically with wms/plane attrs"

  With this, we now actually fix all of the issues causing underruns instead of
  just working around them.

 - Since we now are fixing this issue instead of working around it, the
   following patches were no longer necessary:
   - "drm/i915/skl: Always wait for pipes to update after a flush"
   - "drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()"

Lyude (5):
  drm/i915/skl: Add support for the SAGV, fix underrun hangs
  drm/i915/skl: Update plane watermarks atomically during plane updates
  drm/i915/skl: Ensure pipes with changed wms get added to the state
  drm/i915: Move CRTC updating in atomic_commit into it's own hook
  drm/i915/skl: Update DDB values atomically with wms/plane attrs

Matt Roper (1):
  drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

 drivers/gpu/drm/i915/i915_drv.h  |   4 +
 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_display.c | 190 +++---
 drivers/gpu/drm/i915/intel_drv.h |  17 ++
 drivers/gpu/drm/i915/intel_pm.c  | 467 +++
 drivers/gpu/drm/i915/intel_sprite.c  |   6 +
 6 files changed, 496 insertions(+), 193 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v5 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

[Lyude]

Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.

Based off of Matt Rope's suggestions

Signed-off-by: Lyude 
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/intel_display.c | 74 +---
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 87018d3..4964e3f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -632,6 +632,8 @@ struct drm_i915_display_funcs {
  struct intel_crtc_state *crtc_state);
void (*crtc_enable)(struct drm_crtc *crtc);
void (*crtc_disable)(struct drm_crtc *crtc);
+   void (*update_crtcs)(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask);
void (*audio_codec_enable)(struct drm_connector *connector,
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 79d146c..d985b5b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13624,6 +13624,52 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
return false;
 }
 
+static void intel_update_crtc(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_crtc_state,
+ unsigned int *crtc_vblank_mask)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state);
+   bool modeset = needs_modeset(crtc->state);
+
+   if (modeset) {
+   update_scanline_offset(intel_crtc);
+   dev_priv->display.crtc_enable(crtc);
+   } else {
+   intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
+   }
+
+   if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
+   intel_fbc_enable(
+   intel_crtc, pipe_config,
+   to_intel_plane_state(crtc->primary->state));
+   }
+
+   drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
+
+   if (pipe_config->base.active && needs_vblank_wait(pipe_config))
+   *crtc_vblank_mask |= drm_crtc_mask(crtc);
+}
+
+static void intel_update_crtcs(struct drm_atomic_state *state,
+  unsigned int *crtc_vblank_mask)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *old_crtc_state;
+   int i;
+
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+   if (!crtc->state->active)
+   continue;
+
+   intel_update_crtc(crtc, state, old_crtc_state,
+ crtc_vblank_mask);
+   }
+}
+
 static void intel_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
@@ -13715,17 +13761,9 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
intel_modeset_verify_disabled(dev);
}
 
-   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
+   /* Complete the events for pipes that have now been disabled */
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->state);
-
-   if (modeset && crtc->state->active) {
-   update_scanline_offset(to_intel_crtc(crtc));
-   dev_priv->display.crtc_enable(crtc);
-   }
 
/* Complete events for now disable pipes here. */
if (modeset && !crtc->state->active && crtc->state->event) {
@@ -13735,21 +13773,11 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
 
crtc->state->event = NULL;
}
-
-   if (!modeset)
-   
intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
-
-   

[Intel-gfx] [PATCH v5 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

[Lyude]

If we're enabling a pipe, we'll need to modify the watermarks on all
other active pipes. Since those pipes won't be added to the state on
their own, we need to add them ourselves.

Signed-off-by: Lyude 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 53adcbf..6b2452b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4085,6 +4085,10 @@ skl_compute_ddb(struct drm_atomic_state *state)
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
+
+   ret = drm_atomic_add_affected_planes(state, &intel_crtc->base);
+   if (ret)
+   return ret;
}
 
return 0;
-- 
2.7.4

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

[Intel-gfx] [PATCH v5 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Lyude]

Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

Changes since v5:
 - Don't use is_power_of_2. Makes things confusing
 - Don't use the old state to figure out whether or not to
   enable/disable the sagv, use the new one
 - Split the loop in skl_disable_sagv into it's own function
Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
 - Use time_before() to compare timeout to jiffies
Changes since v2:
 - Really apply minor style nitpicks to patch this time
Changes since v1:
 - Added comments about this probably being one of the requirements to
   fixing Skylake's watermark issues
 - Minor style nitpicks from Matt Roper
 - Disable these functions on Broxton, since it doesn't have an SAGV

Reviewed-by: Matt Roper 
Signed-off-by: Lyude 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_reg.h  |   5 ++
 drivers/gpu/drm/i915/intel_display.c |  12 
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 112 +++
 5 files changed, 133 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65ada5d..87018d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1962,6 +1962,8 @@ struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
 
+   bool skl_sagv_enabled;
+
struct {
/*
 * Raw watermark latency values:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2f93d4a..5fb1c63 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7170,6 +7170,11 @@ enum {
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ  0x17
 #define   DISPLAY_IPS_CONTROL  0x19
 #define  HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
+#define   GEN9_PCODE_SAGV_CONTROL  0x21
+#define GEN9_SAGV_DISABLE  0x0
+#define GEN9_SAGV_LOW_FREQ 0x1
+#define GEN9_SAGV_HIGH_FREQ0x2
+#define GEN9_SAGV_DYNAMIC_FREQ  0x3
 #define GEN6_PCODE_DATA_MMIO(0x138128)
 #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT   8
 #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a8e8cc8..76ba79f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4565,6 +4565,7 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
drm_atomic_get_existing_plane_state(old_state, primary);
@@ -4589,6 +4590,9

[Intel-gfx] [PATCH v5 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

[Lyude]

From: Matt Roper 

When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw.  However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.

This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes.  Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).

Changes since v1:
 - Add a function for copying a pipe's wm values
   (skl_copy_wm_for_pipe()) so we can reuse this later

Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check' 
(v2)")
Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: Matt Roper 
Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_pm.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 68721a5..7fd299e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4064,6 +4064,24 @@ skl_compute_ddb(struct drm_atomic_state *state)
return 0;
 }
 
+static void
+skl_copy_wm_for_pipe(struct skl_wm_values *dst,
+struct skl_wm_values *src,
+enum pipe pipe)
+{
+   dst->wm_linetime[pipe] = src->wm_linetime[pipe];
+   memcpy(dst->plane[pipe], src->plane[pipe],
+  sizeof(dst->plane[pipe]));
+   memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
+  sizeof(dst->plane_trans[pipe]));
+
+   dst->ddb.pipe[pipe] = src->ddb.pipe[pipe];
+   memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
+  sizeof(dst->ddb.y_plane[pipe]));
+   memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
+  sizeof(dst->ddb.plane[pipe]));
+}
+
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
@@ -4136,8 +4154,10 @@ static void skl_update_wm(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_wm_values *results = &dev_priv->wm.skl_results;
+   struct skl_wm_values *hw_vals = &dev_priv->wm.skl_hw;
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct skl_pipe_wm *pipe_wm = &cstate->wm.skl.optimal;
+   int pipe;
 
if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
return;
@@ -4149,8 +4169,12 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_write_wm_values(dev_priv, results);
skl_flush_wm_values(dev_priv, results);
 
-   /* store the new configuration */
-   dev_priv->wm.skl_hw = *results;
+   /*
+* Store the new configuration (but only for the pipes that have
+* changed; the other values weren't recomputed).
+*/
+   for_each_pipe_masked(dev_priv, pipe, results->dirty_pipes)
+   skl_copy_wm_for_pipe(hw_vals, results, pipe);
 
mutex_unlock(&dev_priv->wm.wm_mutex);
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH v5 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

[Lyude]

Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.

The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.

The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:

We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:

|   A   |   B   |xxx|

Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.

1. Flush pipes with new allocation contained into old space. None
   apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
   previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
   giving us the following update order: A, B

This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.

As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().

This long overdue patch fixes the rest of the underruns on Skylake.

Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
Signed-off-by: Lyude 
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 100 ++--
 drivers/gpu/drm/i915/intel_drv.h |  10 ++
 drivers/gpu/drm/i915/intel_pm.c  | 287 ---
 3 files changed, 231 insertions(+), 166 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d985b5b..db271d6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12909,16 +12909,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
  hw_entry->start, hw_entry->end);
}
 
-   /* cursor */
-   hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
-   sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
-
-   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+   if (intel_crtc->cursor_addr) {
+   hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
+   sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
+
+   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+   }
}
 }
 
@@ -13670,6 +13677,72 @@ static void intel_update_crtcs(struct drm_atomic_state 
*state,
}
 }
 
+static inline void
+skl_do_ddb_step(struct drm_atomic_state *state,
+   enum skl_ddb_step step)
+{
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *old_crtc_state;
+   unsigned int crtc_vblank_mask; /* unused */
+   int i;
+
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate =
+   to_intel_crtc_state(crtc->state);
+   bool vblank_wait = false;
+
+   if (cstate->wm.skl.ddb_realloc != step || !crtc->state->active)
+   continue;
+
+   /*
+* If we're changing the ddb allocation of this pipe to make
+* room for another pipe, w

[Intel-gfx] [PATCH v5 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

[Lyude]

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

  or

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

Now we update watermarks atomically like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
  yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.

Changes since original patch series:
 - Remove mutex_lock/mutex_unlock since they don't do anything and we're
   not touching global state
 - Move skl_write_cursor_wm/skl_write_plane_wm functions into
   intel_pm.c, make externally visible
 - Add skl_write_plane_wm calls to skl_update_plane
 - Fix conditional for for loop in skl_write_plane_wm (level < max_level
   should be level <= max_level)
 - Make diagram in commit more accurate to what's actually happening
 - Add Fixes:

Changes since v1:
 - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
   then just Skylake
 - Update description to make it clear this patch doesn't fix everything
 - Check if pipes were actually changed before writing watermarks

Changes since v2:
 - Write PIPE_WM_LINETIME during vblank evasion

Changes since v3:
 - Rebase against new SAGV patch changes

Changes since v4:
 - Add a parameter to choose what skl_wm_values struct to use when
   writing new plane watermarks

Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c |  8 +
 drivers/gpu/drm/i915/intel_drv.h |  5 
 drivers/gpu/drm/i915/intel_pm.c  | 58 ++--
 drivers/gpu/drm/i915/intel_sprite.c  |  6 
 4 files changed, 61 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 76ba79f..79d146c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2980,6 +2980,7 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct skl_wm_values *wm = &dev_priv->wm.skl_results;
int pipe = intel_crtc->pipe;
u32 plane_ctl, stride_div, stride;
u32 tile_height, plane_offset, plane_size;
@@ -3031,6 +3032,9 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_x = x_offset;
intel_crtc->adjusted_y = y_offset;
 
+   if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc->base))
+   skl_write_plane_wm(intel_crtc, wm, 0);
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
@@ -10243,9 +10247,13 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
   

Re: [Intel-gfx] [v5, 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Hans de Goede]

Hi,

On 08/02/2016 08:52 PM, cp...@redhat.com wrote:

Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

Changes since v5:
 - Don't use is_power_of_2. Makes things confusing
 - Don't use the old state to figure out whether or not to
   enable/disable the sagv, use the new one
 - Split the loop in skl_disable_sagv into it's own function
Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
 - Use time_before() to compare timeout to jiffies
Changes since v2:
 - Really apply minor style nitpicks to patch this time
Changes since v1:
 - Added comments about this probably being one of the requirements to
   fixing Skylake's watermark issues
 - Minor style nitpicks from Matt Roper
 - Disable these functions on Broxton, since it doesn't have an SAGV

Reviewed-by: Matt Roper 
Signed-off-by: Lyude 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_reg.h  |   5 ++
 drivers/gpu/drm/i915/intel_display.c |  12 
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 112 +++
 5 files changed, 133 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65ada5d..87018d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1962,6 +1962,8 @@ struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;

+   bool skl_sagv_enabled;
+
struct {
/*
 * Raw watermark latency values:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2f93d4a..5fb1c63 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7170,6 +7170,11 @@ enum {
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ  0x17
 #define   DISPLAY_IPS_CONTROL  0x19
 #define  HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
+#define   GEN9_PCODE_SAGV_CONTROL  0x21
+#define GEN9_SAGV_DISABLE  0x0
+#define GEN9_SAGV_LOW_FREQ 0x1
+#define GEN9_SAGV_HIGH_FREQ0x2
+#define GEN9_SAGV_DYNAMIC_FREQ  0x3
 #define GEN6_PCODE_DATA_MMIO(0x138128)
 #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT   8
 #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a8e8cc8..76ba79f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4565,6 +4565,7 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
drm_atomic_get_existi

Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[Vivi, Rodrigo]

On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote:
> On Sat, 02 Jul 2016, "Vivi, Rodrigo"  wrote:
> > 
> > Hi,
> > 
> > Please consider pulling i915 updates to linux-firmware.git
> > 
> > 
> > The following changes since commit
> > 040c24514b94fcdbd6308d986d1bde59a704a21a:
> > 
> >   linux-firmware: intel: Update Broxton audio firmware (2016-06-29
> > 14:20:20 +0530)
> > 
> > are available in the git repository at:
> > 
> >   git://people.freedesktop.org/~vivijim/linux-firmware-i915 master
> > 
> > for you to fetch changes up to
> > 19b71af5326bf28fe62ac2b1607b5e18d4b0eeb6:
> > 
> >   linux-firmware/i915: Step away from symbolic links and clean up
> > repo.
> > (2016-07-01 16:07:52 -0700)
> > 
> > 
> > Rodrigo Vivi (3):
> >   linux-firmware: New minor DMC release for Broxton - ver1_07
> >   linux-firmware: First DMC image for Kabylake.
> >   linux-firmware/i915: Step away from symbolic links and clean
> > up
> > repo.
> > 
> >  WHENCE|  14 +-
> > 
> >  i915/bxt_dmc_ver1.bin |   2 +-
> >  i915/bxt_dmc_ver1_04.bin  | Bin 5872 -> 0
> > bytes
> >  i915/bxt_dmc_ver1_05.bin  | Bin 5872 -> 0
> > bytes
> >  i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} | Bin 8380 ->
> > 8380
> > bytes
> >  i915/kbl_dmc_ver1.bin |   1 +
> >  i915/kbl_dmc_ver1_01.bin  | Bin 0 -> 8616
> > bytes
> >  i915/skl_dmc_ver1_23.bin  | Bin 8824 -> 0
> > bytes
> >  i915/skl_guc_ver1.bin | Bin 21 ->
> > 109636
> > bytes
> >  i915/skl_guc_ver1_1059.bin| Bin 109636 ->
> > 0
> > bytes
> >  i915/skl_guc_ver4.bin | Bin 18 ->
> > 128320
> > bytes
> >  i915/skl_guc_ver4_3.bin   | Bin 128320 ->
> > 0
> > bytes
> >  12 files changed, 7 insertions(+), 10 deletions(-)
> >  delete mode 100644 i915/bxt_dmc_ver1_04.bin
> >  delete mode 100644 i915/bxt_dmc_ver1_05.bin
> >  rename i915/{bxt_dmc_ver1_06.bin => bxt_dmc_ver1_07.bin} (64%)
> >  create mode 12 i915/kbl_dmc_ver1.bin
> >  create mode 100644 i915/kbl_dmc_ver1_01.bin
> >  delete mode 100644 i915/skl_dmc_ver1_23.bin
> >  mode change 12 => 100644 i915/skl_guc_ver1.bin
> >  delete mode 100644 i915/skl_guc_ver1_1059.bin
> >  mode change 12 => 100644 i915/skl_guc_ver4.bin
> >  delete mode 100644 i915/skl_guc_ver4_3.bin
> Why are you deleting old versions?

Mainly to keep it clean. OSVs pack that entire repo, I don't want i915
taking unnecessary space from final users.

I believe this is another point in favor of bringing the sym links
back.

But also because we need to remove any firmware that we know it is bad
and that would break the user. If it was blacklisted it was removed
from repo.

Yet another reason for symbolic link. If we know the firmware is bad it
is bad for previous versions as well, but if we stay with the version
hardcoded we are forcing the user to stay with a firmware that we know
it is bad.

> 
> BR,
> Jani.
> 
> > 
> > 
> > Thanks,
> > Rodrigo.
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> -- 
> 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 v5 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Matt Roper]

On Tue, Aug 02, 2016 at 02:52:49PM -0400, Lyude wrote:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however, is the mysterious issue of
> underruns causing full system hangs. An easy way to reproduce this with
> a skylake system:
> 
> - Get a laptop with a skylake GPU, and hook up two external monitors to
>   it
> - Move the cursor from the built-in LCD to one of the external displays
>   as quickly as you can
> - You'll get a few pipe underruns, and eventually the entire system will
>   just freeze.
> 
> After doing a lot of investigation and reading through the bspec, I
> found the existence of the SAGV, which is responsible for adjusting the
> system agent voltage and clock frequencies depending on how much power
> we need. According to the bspec:
> 
> "The display engine access to system memory is blocked during the
>  adjustment time. SAGV defaults to enabled. Software must use the
>  GT-driver pcode mailbox to disable SAGV when the display engine is not
>  able to tolerate the blocking time."
> 
> The rest of the bspec goes on to explain that software can simply leave
> the SAGV enabled, and disable it when we use interlaced pipes/have more
> then one pipe active.
> 
> Sure enough, with this patchset the system hangs resulting from pipe
> underruns on Skylake have completely vanished on my T460s. Additionally,
> the bspec mentions turning off the SAGV   with more then one pipe enabled
> as a workaround for display underruns. While this patch doesn't entirely
> fix that, it looks like it does improve the situation a little bit so
> it's likely this is going to be required to make watermarks on Skylake
> fully functional.
> 
> Changes since v5:
>  - Don't use is_power_of_2. Makes things confusing
>  - Don't use the old state to figure out whether or not to
>enable/disable the sagv, use the new one
>  - Split the loop in skl_disable_sagv into it's own function
> Changes since v4:
>  - Use is_power_of_2 against active_crtcs to check whether we have > 1
>pipe enabled
>  - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
>enabled
>  - Call skl_sagv_enable/disable() from pre/post-plane updates
> Changes since v3:
>  - Use time_before() to compare timeout to jiffies
> Changes since v2:
>  - Really apply minor style nitpicks to patch this time
> Changes since v1:
>  - Added comments about this probably being one of the requirements to
>fixing Skylake's watermark issues
>  - Minor style nitpicks from Matt Roper
>  - Disable these functions on Broxton, since it doesn't have an SAGV
> 
> Reviewed-by: Matt Roper 
> Signed-off-by: Lyude 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   2 +
>  drivers/gpu/drm/i915/i915_reg.h  |   5 ++
>  drivers/gpu/drm/i915/intel_display.c |  12 
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_pm.c  | 112 
> +++
>  5 files changed, 133 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 65ada5d..87018d3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1962,6 +1962,8 @@ struct drm_i915_private {
>   struct i915_suspend_saved_registers regfile;
>   struct vlv_s0ix_state vlv_s0ix_state;
>  
> + bool skl_sagv_enabled;
> +
>   struct {
>   /*
>* Raw watermark latency values:
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2f93d4a..5fb1c63 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7170,6 +7170,11 @@ enum {
>  #define   HSW_PCODE_DE_WRITE_FREQ_REQ0x17
>  #define   DISPLAY_IPS_CONTROL0x19
>  #defineHSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
> +#define   GEN9_PCODE_SAGV_CONTROL0x21
> +#define GEN9_SAGV_DISABLE0x0
> +#define GEN9_SAGV_LOW_FREQ   0x1
> +#define GEN9_SAGV_HIGH_FREQ  0x2
> +#define GEN9_SAGV_DYNAMIC_FREQ  0x3
>  #define GEN6_PCODE_DATA  _MMIO(0x138128)
>  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
>  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT   16
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a8e8cc8..76ba79f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4565,6 +4565,7 @@ static void intel_post_plane_update(struct 
> intel_crtc_state *old_crtc_state)
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_device 

Re: [Intel-gfx] Disable power management on i915

[Sanchez, AdolfoX]

Hello Joonas,

Thanks for your answer.
It is a test related for this bug: 
https://bugzilla.kernel.org/show_bug.cgi?id=109051

Best Regards,
Adolfo Sanchez


-Original Message-
From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] 
Sent: Tuesday, August 02, 2016 1:48 AM
To: Sanchez, AdolfoX ; 
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Disable power management on i915

On ma, 2016-08-01 at 20:08 +, Sanchez, AdolfoX wrote:
> Hello.
>  
> I would like to know what is the best way to disable power management 
> on the GPU unit, the purpose is to avoid GPU power transitions to 
> avoid voltage swings.

i915.enable_rc6=0 would be a start. Do you also want to fix the GPU frequency?

May I also ask why you want to do such thing?

Regards, Joonas

>  
> Additional information:
> Platform: Bay Trail J1900
> O.S: Linux Kernel 4.4
>  
> Any help would be appreciated.
>  
> Best Regards,
> Adolfo Sanchez.
>  
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

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

Re: [Intel-gfx] [PATCH v5 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

[Matt Roper]

On Tue, Aug 02, 2016 at 02:52:51PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
> 
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
> 
> With this in mind, up until now we've been updating watermarks on skl
> like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
>   or
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
> Now we update watermarks atomically like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks() (wm values aren't written yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - write new wm values
> - end vblank evasion
>   }
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks() (actual wm values aren't written
>   yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
>   - write new wm values
> - end vblank evasion
>   }
> 
> So this patch moves all of the watermark writes into the right place;
> inside of the vblank evasion where we update all of the registers for
> each plane. While this patch doesn't fix everything, it does allow us to
> update the watermark values in the way the hardware expects us to.
> 
> Changes since original patch series:
>  - Remove mutex_lock/mutex_unlock since they don't do anything and we're
>not touching global state
>  - Move skl_write_cursor_wm/skl_write_plane_wm functions into
>intel_pm.c, make externally visible
>  - Add skl_write_plane_wm calls to skl_update_plane
>  - Fix conditional for for loop in skl_write_plane_wm (level < max_level
>should be level <= max_level)
>  - Make diagram in commit more accurate to what's actually happening
>  - Add Fixes:
> 
> Changes since v1:
>  - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
>then just Skylake
>  - Update description to make it clear this patch doesn't fix everything
>  - Check if pipes were actually changed before writing watermarks
> 
> Changes since v2:
>  - Write PIPE_WM_LINETIME during vblank evasion
> 
> Changes since v3:
>  - Rebase against new SAGV patch changes
> 
> Changes since v4:
>  - Add a parameter to choose what skl_wm_values struct to use when
>writing new plane watermarks
> 
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
> Signed-off-by: Lyude 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  8 +
>  drivers/gpu/drm/i915/intel_drv.h |  5 
>  drivers/gpu/drm/i915/intel_pm.c  | 58 
> ++--
>  drivers/gpu/drm/i915/intel_sprite.c  |  6 
>  4 files changed, 61 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 76ba79f..79d146c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2980,6 +2980,7 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
>   struct drm_framebuffer *fb = plane_state->base.fb;
>   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> + struct skl_wm_values *wm = &dev_priv->wm.skl_results;
>   int pipe = intel_crtc->pipe;
>   u32 plane_ctl, stride_div, stride;
>   u32 tile_height, plane_offset, plane_size;
> @@ -3031,6 +3032,9 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   intel_crtc->adjusted_x = x_offset;
>   intel_crtc->adjusted_y = y_offset;
>  
> + if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc->base))
> +

Re: [Intel-gfx] [PATCH v5 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

[Matt Roper]

On Tue, Aug 02, 2016 at 02:52:52PM -0400, Lyude wrote:
> If we're enabling a pipe, we'll need to modify the watermarks on all
> other active pipes. Since those pipes won't be added to the state on
> their own, we need to add them ourselves.

All pipes (crtc's) are already added to the state if we have a change in
active pipes.  I think what you meant to write was "...we'll need to
modify the watermarks on all active *planes*.  Since those *planes*
won't..."

Aside from the commit message, I believe the logic is correct, so you
can consider this
Reviewed-by: Matt Roper 
once you reword it.


Matt

> 
> Signed-off-by: Lyude 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 53adcbf..6b2452b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4085,6 +4085,10 @@ skl_compute_ddb(struct drm_atomic_state *state)
>   ret = skl_allocate_pipe_ddb(cstate, ddb);
>   if (ret)
>   return ret;
> +
> + ret = drm_atomic_add_affected_planes(state, &intel_crtc->base);
> + if (ret)
> + return ret;
>   }
>  
>   return 0;
> -- 
> 2.7.4
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 03/23] drm/i915: Rename intel_context[engine].ringbuf

[Chris Wilson]

Perform s/ringbuf/ring/ on the context struct for consistency with the
ring/engine split.

v2: Kill an outdated error_ringbuf label

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-14-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_debugfs.c|  8 +++
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/i915_gem_context.c|  4 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 37 ++
 5 files changed, 25 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7c42ec4612ab..b67fb4c26178 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -425,8 +425,8 @@ static int per_file_ctx_stats(int id, void *ptr, void *data)
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
if (ctx->engine[n].state)
per_file_stats(0, ctx->engine[n].state, data);
-   if (ctx->engine[n].ringbuf)
-   per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+   if (ctx->engine[n].ring)
+   per_file_stats(0, ctx->engine[n].ring->obj, data);
}
 
return 0;
@@ -2085,8 +2085,8 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
seq_putc(m, ce->initialised ? 'I' : 'i');
if (ce->state)
describe_obj(m, ce->state);
-   if (ce->ringbuf)
-   describe_ctx_ringbuf(m, ce->ringbuf);
+   if (ce->ring)
+   describe_ctx_ringbuf(m, ce->ring);
seq_putc(m, '\n');
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65ada5d2f88c..db43ced6f5e6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -894,7 +894,7 @@ struct i915_gem_context {
 
struct intel_context {
struct drm_i915_gem_object *state;
-   struct intel_ringbuffer *ringbuf;
+   struct intel_ringbuffer *ring;
struct i915_vma *lrc_vma;
uint32_t *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f7f4a8c40afe..f825b1e4aadf 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -173,8 +173,8 @@ void i915_gem_context_free(struct kref *ctx_ref)
continue;
 
WARN_ON(ce->pin_count);
-   if (ce->ringbuf)
-   intel_ringbuffer_free(ce->ringbuf);
+   if (ce->ring)
+   intel_ringbuffer_free(ce->ring);
 
i915_gem_object_put(ce->state);
}
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 01c1c1671811..eccd34832fe6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -363,7 +363,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
(engine->guc_id << GUC_ELC_ENGINE_OFFSET);
 
-   obj = ce->ringbuf->obj;
+   obj = ce->ring->obj;
gfx_addr = i915_gem_obj_ggtt_offset(obj);
 
lrc->ring_begin = gfx_addr;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ce7dcf85ea4b..97ce2e32a507 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -482,11 +482,8 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
 * resubmit the request. See gen8_emit_request() for where we
 * prepare the padding after the end of the request.
 */
-   struct intel_ringbuffer *ringbuf;
-
-   ringbuf = req0->ctx->engine[engine->id].ringbuf;
req0->tail += 8;
-   req0->tail &= ringbuf->size - 1;
+   req0->tail &= req0->ring->size - 1;
}
 
execlists_submit_requests(req0, req1);
@@ -714,7 +711,7 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
return ret;
}
 
-   request->ring = ce->ringbuf;
+   request->ring = ce->ring;
 
if (i915.enable_guc_submission) {
/*
@@ -976,14 +973,14 @@ static int intel_lr_context_pin(struct i915_gem_context 
*ctx,
 
lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
 
-   ret = intel_pin_and_map_ringbuffer_obj(dev_priv, ce->ringbuf);
+   ret 

[Intel-gfx] [CI 01/23] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

[Chris Wilson]

Both perform the same actions with more or less indirection, so just
unify the code.

v2: Add back a few intel_engine_cs locals

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-11-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem_context.c|  47 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  53 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c|  48 ++--
 drivers/gpu/drm/i915/intel_display.c   |  80 +++---
 drivers/gpu/drm/i915/intel_lrc.c   | 183 +++---
 drivers/gpu/drm/i915/intel_lrc.h   |  26 --
 drivers/gpu/drm/i915/intel_mocs.c  |  38 ++-
 drivers/gpu/drm/i915/intel_overlay.c   |  50 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c| 382 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h|  25 +-
 10 files changed, 450 insertions(+), 482 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index bd13d084e19c..a0e24eb5e167 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -552,6 +552,7 @@ static inline int
 mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
 {
struct drm_i915_private *dev_priv = req->i915;
+   struct intel_ringbuffer *ring = req->ringbuf;
struct intel_engine_cs *engine = req->engine;
u32 flags = hw_flags | MI_MM_SPACE_GTT;
const int num_rings =
@@ -589,64 +590,64 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 
/* WaProgramMiArbOnOffAroundMiSetContext:ivb,vlv,hsw,bdw,chv */
if (INTEL_GEN(dev_priv) >= 7) {
-   intel_ring_emit(engine, MI_ARB_ON_OFF | MI_ARB_DISABLE);
+   intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_DISABLE);
if (num_rings) {
struct intel_engine_cs *signaller;
 
-   intel_ring_emit(engine,
+   intel_ring_emit(ring,
MI_LOAD_REGISTER_IMM(num_rings));
for_each_engine(signaller, dev_priv) {
if (signaller == engine)
continue;
 
-   intel_ring_emit_reg(engine,
+   intel_ring_emit_reg(ring,

RING_PSMI_CTL(signaller->mmio_base));
-   intel_ring_emit(engine,
+   intel_ring_emit(ring,

_MASKED_BIT_ENABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
}
}
}
 
-   intel_ring_emit(engine, MI_NOOP);
-   intel_ring_emit(engine, MI_SET_CONTEXT);
-   intel_ring_emit(engine,
+   intel_ring_emit(ring, MI_NOOP);
+   intel_ring_emit(ring, MI_SET_CONTEXT);
+   intel_ring_emit(ring,
i915_gem_obj_ggtt_offset(req->ctx->engine[RCS].state) |
flags);
/*
 * w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
 * WaMiSetContext_Hang:snb,ivb,vlv
 */
-   intel_ring_emit(engine, MI_NOOP);
+   intel_ring_emit(ring, MI_NOOP);
 
if (INTEL_GEN(dev_priv) >= 7) {
if (num_rings) {
struct intel_engine_cs *signaller;
i915_reg_t last_reg = {}; /* keep gcc quiet */
 
-   intel_ring_emit(engine,
+   intel_ring_emit(ring,
MI_LOAD_REGISTER_IMM(num_rings));
for_each_engine(signaller, dev_priv) {
if (signaller == engine)
continue;
 
last_reg = RING_PSMI_CTL(signaller->mmio_base);
-   intel_ring_emit_reg(engine, last_reg);
-   intel_ring_emit(engine,
+   intel_ring_emit_reg(ring, last_reg);
+   intel_ring_emit(ring,

_MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
}
 
/* Insert a delay before the next switch! */
-   intel_ring_emit(engine,
+   intel_ring_emit(ring,
MI_STORE_REGISTER_MEM |
MI_SRM_LRM_GLOBAL_GTT);
-   intel_ring_emit_reg(engine, last_reg);
-   intel_ring_emit(engine, engine->scratch.gtt_offset);
-   intel_ring_emit(engine, MI_NOOP);
+   intel_ring_emit_reg(ring, last_reg);
+   intel_ring_emit(ring, engine->scratch.gtt_offset);
+   intel_ring_

[Intel-gfx] [CI 16/23] drm/i915: Stop passing caller's num_dwords to engine->semaphore.signal()

[Chris Wilson]

Rather than pass in the num_dwords that the caller wishes to use after
the signal command packet, split the breadcrumb emission into two phases
and have both the signal and breadcrumb individiually acquire space on
the ring. This makes the interface simpler for the reader, and will
simplify for patches.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-25-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 51 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 +--
 2 files changed, 23 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8250db767a1a..a8de46c96d32 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1309,10 +1309,8 @@ static void render_ring_cleanup(struct intel_engine_cs 
*engine)
intel_fini_pipe_control(engine);
 }
 
-static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req,
-  unsigned int num_dwords)
+static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req)
 {
-#define MBOX_UPDATE_DWORDS 8
struct intel_ring *signaller = signaller_req->ring;
struct drm_i915_private *dev_priv = signaller_req->i915;
struct intel_engine_cs *waiter;
@@ -1320,10 +1318,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
int ret, num_rings;
 
num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask);
-   num_dwords += (num_rings-1) * MBOX_UPDATE_DWORDS;
-#undef MBOX_UPDATE_DWORDS
-
-   ret = intel_ring_begin(signaller_req, num_dwords);
+   ret = intel_ring_begin(signaller_req, (num_rings-1) * 8);
if (ret)
return ret;
 
@@ -1347,14 +1342,13 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
+   intel_ring_advance(signaller);
 
return 0;
 }
 
-static int gen8_xcs_signal(struct drm_i915_gem_request *signaller_req,
-  unsigned int num_dwords)
+static int gen8_xcs_signal(struct drm_i915_gem_request *signaller_req)
 {
-#define MBOX_UPDATE_DWORDS 6
struct intel_ring *signaller = signaller_req->ring;
struct drm_i915_private *dev_priv = signaller_req->i915;
struct intel_engine_cs *waiter;
@@ -1362,10 +1356,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request 
*signaller_req,
int ret, num_rings;
 
num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask);
-   num_dwords += (num_rings-1) * MBOX_UPDATE_DWORDS;
-#undef MBOX_UPDATE_DWORDS
-
-   ret = intel_ring_begin(signaller_req, num_dwords);
+   ret = intel_ring_begin(signaller_req, (num_rings-1) * 6);
if (ret)
return ret;
 
@@ -1387,12 +1378,12 @@ static int gen8_xcs_signal(struct drm_i915_gem_request 
*signaller_req,
MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
+   intel_ring_advance(signaller);
 
return 0;
 }
 
-static int gen6_signal(struct drm_i915_gem_request *signaller_req,
-  unsigned int num_dwords)
+static int gen6_signal(struct drm_i915_gem_request *signaller_req)
 {
struct intel_ring *signaller = signaller_req->ring;
struct drm_i915_private *dev_priv = signaller_req->i915;
@@ -1400,12 +1391,8 @@ static int gen6_signal(struct drm_i915_gem_request 
*signaller_req,
enum intel_engine_id id;
int ret, num_rings;
 
-#define MBOX_UPDATE_DWORDS 3
num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask);
-   num_dwords += round_up((num_rings-1) * MBOX_UPDATE_DWORDS, 2);
-#undef MBOX_UPDATE_DWORDS
-
-   ret = intel_ring_begin(signaller_req, num_dwords);
+   ret = intel_ring_begin(signaller_req, round_up((num_rings-1) * 3, 2));
if (ret)
return ret;
 
@@ -1423,6 +1410,7 @@ static int gen6_signal(struct drm_i915_gem_request 
*signaller_req,
/* If num_dwords was rounded, make sure the tail pointer is correct */
if (num_rings % 2 == 0)
intel_ring_emit(signaller, MI_NOOP);
+   intel_ring_advance(signaller);
 
return 0;
 }
@@ -1441,11 +1429,13 @@ static int gen6_emit_request(struct 
drm_i915_gem_request *req)
struct intel_ring *ring = req->ring;
int ret;
 
-   if (engine->semaphore.signal)
-   ret = engine->semaphore.signal(req, 4);
-   else
-   ret = intel_ring_begin(req, 4);
+   if (engine->semaphore.signal) {
+   ret = engine->semaphore.signal(req);
+   if (ret)
+   return ret;
+   }
 
+   ret = intel_ring_begin(req, 4);
if (ret)
return ret

[Intel-gfx] [CI 21/23] drm/i915: Unify legacy/execlists submit_execbuf callbacks

[Chris Wilson]

Now that emitting requests is identical between legacy and execlists, we
can use the same function to build up the ring for submitting to either
engine. (With the exception of i915_switch_contexts(), but in time that
will also be handled gracefully.)

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-30-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_drv.h|  20 -
 drivers/gpu/drm/i915/i915_gem.c|   2 -
 drivers/gpu/drm/i915/i915_gem_context.c|   7 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  24 --
 drivers/gpu/drm/i915/intel_lrc.c   | 123 -
 drivers/gpu/drm/i915/intel_lrc.h   |   5 --
 6 files changed, 21 insertions(+), 160 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8f4edc9dd7a3..49ce21a82c29 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1705,18 +1705,6 @@ struct i915_virtual_gpu {
bool active;
 };
 
-struct i915_execbuffer_params {
-   struct drm_device   *dev;
-   struct drm_file *file;
-   uint32_tdispatch_flags;
-   uint32_targs_batch_start_offset;
-   uint64_tbatch_obj_vm_offset;
-   struct intel_engine_cs *engine;
-   struct drm_i915_gem_object  *batch_obj;
-   struct i915_gem_context*ctx;
-   struct drm_i915_gem_request *request;
-};
-
 /* used in computing the new watermarks state */
 struct intel_wm_config {
unsigned int num_pipes_active;
@@ -2016,9 +2004,6 @@ struct drm_i915_private {
 
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct {
-   int (*execbuf_submit)(struct i915_execbuffer_params *params,
- struct drm_i915_gem_execbuffer2 *args,
- struct list_head *vmas);
void (*cleanup_engine)(struct intel_engine_cs *engine);
void (*stop_engine)(struct intel_engine_cs *engine);
 
@@ -2993,11 +2978,6 @@ int i915_gem_set_domain_ioctl(struct drm_device *dev, 
void *data,
  struct drm_file *file_priv);
 int i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
-void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
-   struct drm_i915_gem_request *req);
-int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
-  struct drm_i915_gem_execbuffer2 *args,
-  struct list_head *vmas);
 int i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file_priv);
 int i915_gem_execbuffer2(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b6c4ff63725f..d79b949fb4c4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4534,11 +4534,9 @@ int i915_gem_init(struct drm_device *dev)
mutex_lock(&dev->struct_mutex);
 
if (!i915.enable_execlists) {
-   dev_priv->gt.execbuf_submit = i915_gem_ringbuffer_submission;
dev_priv->gt.cleanup_engine = intel_engine_cleanup;
dev_priv->gt.stop_engine = intel_engine_stop;
} else {
-   dev_priv->gt.execbuf_submit = intel_execlists_submission;
dev_priv->gt.cleanup_engine = intel_logical_ring_cleanup;
dev_priv->gt.stop_engine = intel_logical_ring_stop;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index edde8411c478..d7a7cc8b6fa4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -894,8 +894,9 @@ int i915_switch_context(struct drm_i915_gem_request *req)
 {
struct intel_engine_cs *engine = req->engine;
 
-   WARN_ON(i915.enable_execlists);
lockdep_assert_held(&req->i915->drm.struct_mutex);
+   if (i915.enable_execlists)
+   return 0;
 
if (!req->ctx->engine[engine->id].state) {
struct i915_gem_context *to = req->ctx;
@@ -943,9 +944,7 @@ int i915_gem_switch_to_kernel_context(struct 
drm_i915_private *dev_priv)
if (IS_ERR(req))
return PTR_ERR(req);
 
-   ret = 0;
-   if (!i915.enable_execlists)
-   ret = i915_switch_context(req);
+   ret = i915_switch_context(req);
i915_add_request_no_flush(req);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i91

[Intel-gfx] [CI 15/23] drm/i915/lrc: Update function names to match request flow

[Chris Wilson]

With adding engine->submit_request, we now have a bunch of functions
with similar names used at different stages of the execlist submission.
Try a different coat of paint, to hopefully reduce confusion between the
requests, intel_engine_cs and the actual execlists submision process.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-24-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  6 +++---
 drivers/gpu/drm/i915/intel_lrc.c   | 18 +-
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 5de867585275..c9105f68cc4e 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1019,11 +1019,11 @@ void i915_guc_submission_disable(struct 
drm_i915_private *dev_priv)
if (!guc->execbuf_client)
return;
 
-   guc_client_free(dev_priv, guc->execbuf_client);
-   guc->execbuf_client = NULL;
-
/* Revert back to manual ELSP submission */
intel_execlists_enable_submission(dev_priv);
+
+   guc_client_free(dev_priv, guc->execbuf_client);
+   guc->execbuf_client = NULL;
 }
 
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8a72ee86e825..961767929fed 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -384,8 +384,8 @@ static void execlists_update_context(struct 
drm_i915_gem_request *rq)
execlists_update_context_pdps(ppgtt, reg_state);
 }
 
-static void execlists_submit_requests(struct drm_i915_gem_request *rq0,
- struct drm_i915_gem_request *rq1)
+static void execlists_elsp_submit_contexts(struct drm_i915_gem_request *rq0,
+  struct drm_i915_gem_request *rq1)
 {
struct drm_i915_private *dev_priv = rq0->i915;
unsigned int fw_domains = rq0->engine->fw_domains;
@@ -418,7 +418,7 @@ static inline void execlists_context_status_change(
atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq);
 }
 
-static void execlists_context_unqueue(struct intel_engine_cs *engine)
+static void execlists_unqueue(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
struct drm_i915_gem_request *cursor, *tmp;
@@ -486,7 +486,7 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
req0->tail &= req0->ring->size - 1;
}
 
-   execlists_submit_requests(req0, req1);
+   execlists_elsp_submit_contexts(req0, req1);
 }
 
 static unsigned int
@@ -597,7 +597,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (submit_contexts) {
if (!engine->disable_lite_restore_wa ||
(csb[i][0] & GEN8_CTX_STATUS_ACTIVE_IDLE))
-   execlists_context_unqueue(engine);
+   execlists_unqueue(engine);
}
 
spin_unlock(&engine->execlist_lock);
@@ -606,7 +606,7 @@ static void intel_lrc_irq_handler(unsigned long data)
DRM_ERROR("More than two context complete events?\n");
 }
 
-static void execlists_context_queue(struct drm_i915_gem_request *request)
+static void execlists_submit_request(struct drm_i915_gem_request *request)
 {
struct intel_engine_cs *engine = request->engine;
struct drm_i915_gem_request *cursor;
@@ -637,7 +637,7 @@ static void execlists_context_queue(struct 
drm_i915_gem_request *request)
list_add_tail(&request->execlist_link, &engine->execlist_queue);
request->ctx_hw_id = request->ctx->hw_id;
if (num_elements == 0)
-   execlists_context_unqueue(engine);
+   execlists_unqueue(engine);
 
spin_unlock_bh(&engine->execlist_lock);
 }
@@ -1901,7 +1901,7 @@ void intel_execlists_enable_submission(struct 
drm_i915_private *dev_priv)
struct intel_engine_cs *engine;
 
for_each_engine(engine, dev_priv)
-   engine->submit_request = execlists_context_queue;
+   engine->submit_request = execlists_submit_request;
 }
 
 static void
@@ -1911,7 +1911,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
*engine)
engine->init_hw = gen8_init_common_ring;
engine->emit_flush = gen8_emit_flush;
engine->emit_request = gen8_emit_request;
-   engine->submit_request = execlists_context_queue;
+   engine->submit_request = execlists_submit_request;
 
engine->irq_enable = gen8_logical_ring_enable_irq;
engine->irq_disable = gen8_logical_ring_disable_irq;
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.

[Intel-gfx] [CI 10/23] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

[Chris Wilson]

Both the ->dispatch_execbuffer and ->emit_bb_start callbacks do exactly
the same thing, add MI_BATCHBUFFER_START to the request's ringbuffer -
we need only one vfunc.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-20-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  6 ++--
 drivers/gpu/drm/i915/i915_gem_render_state.c | 16 +-
 drivers/gpu/drm/i915/intel_lrc.c | 15 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 48 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 12 +++
 5 files changed, 50 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index fe06b5886ee4..ca941ff7a94b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1326,9 +1326,9 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,
if (exec_len == 0)
exec_len = params->batch_obj->base.size;
 
-   ret = params->engine->dispatch_execbuffer(params->request,
- exec_start, exec_len,
- params->dispatch_flags);
+   ret = params->engine->emit_bb_start(params->request,
+   exec_start, exec_len,
+   params->dispatch_flags);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index b2be4676a5cf..2ba759f3ab6f 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -234,18 +234,18 @@ int i915_gem_render_state_init(struct 
drm_i915_gem_request *req)
if (so.rodata == NULL)
return 0;
 
-   ret = req->engine->dispatch_execbuffer(req, so.ggtt_offset,
-so.rodata->batch_items * 4,
-I915_DISPATCH_SECURE);
+   ret = req->engine->emit_bb_start(req, so.ggtt_offset,
+so.rodata->batch_items * 4,
+I915_DISPATCH_SECURE);
if (ret)
goto out;
 
if (so.aux_batch_size > 8) {
-   ret = req->engine->dispatch_execbuffer(req,
-(so.ggtt_offset +
- so.aux_batch_offset),
-so.aux_batch_size,
-I915_DISPATCH_SECURE);
+   ret = req->engine->emit_bb_start(req,
+(so.ggtt_offset +
+ so.aux_batch_offset),
+so.aux_batch_size,
+I915_DISPATCH_SECURE);
if (ret)
goto out;
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f4d6736bf039..bf42a66d6624 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -859,7 +859,9 @@ int intel_execlists_submission(struct 
i915_execbuffer_params *params,
exec_start = params->batch_obj_vm_offset +
 args->batch_start_offset;
 
-   ret = engine->emit_bb_start(params->request, exec_start, 
params->dispatch_flags);
+   ret = engine->emit_bb_start(params->request,
+   exec_start, args->batch_len,
+   params->dispatch_flags);
if (ret)
return ret;
 
@@ -1541,7 +1543,8 @@ static int intel_logical_ring_emit_pdps(struct 
drm_i915_gem_request *req)
 }
 
 static int gen8_emit_bb_start(struct drm_i915_gem_request *req,
- u64 offset, unsigned dispatch_flags)
+ u64 offset, u32 len,
+ unsigned int dispatch_flags)
 {
struct intel_ring *ring = req->ring;
bool ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
@@ -1814,13 +1817,15 @@ static int intel_lr_context_render_state_init(struct 
drm_i915_gem_request *req)
return 0;
 
ret = req->engine->emit_bb_start(req, so.ggtt_offset,
-  I915_DISPATCH_SECURE);
+so.rodata->batch_items * 4,
+I915_DISPATCH_SECURE);
if (ret)
goto out;
 
ret = req->engine->emit_bb_start(req,
-  (so.ggtt_offset + so.aux_batch_offset),
-  I915_DISPA

[Intel-gfx] [CI 13/23] drm/i915: Move the modulus for ring emission to the register write

[Chris Wilson]

Space reservation is already safe with respect to the ring->size
modulus, but hardware only expects to see values in the range
0...ring->size-1 (inclusive) and so requires the modulus to prevent us
writing the value ring->size instead of 0. As this is only required for
the register itself, we can defer the modulus to the register update and
not perform it after every command packet. We keep the
intel_ring_advance() around in the code to provide demarcation for the
end-of-packet (which then can be compared against intel_ring_begin() as
the number of dwords emitted must match the reserved space).

v2: Assert that the ring size is a power-of-two to match assumptions in
the code. Simplify the comment before writing the tail value to explain
why the modulus is necessary.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Dave Gordon 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  8 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 20 +---
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bf42a66d6624..824f7efe4e64 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -373,7 +373,7 @@ static void execlists_update_context(struct 
drm_i915_gem_request *rq)
struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
 
-   reg_state[CTX_RING_TAIL+1] = rq->tail;
+   reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, rq->tail);
 
/* True 32b PPGTT with dynamic page allocation: update PDP
 * registers and point the unallocated PDPs to scratch page.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3142085b5cc0..a03935338019 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
drm_i915_gem_request *request)
 {
struct drm_i915_private *dev_priv = request->i915;
 
-   I915_WRITE_TAIL(request->engine, request->tail);
+   I915_WRITE_TAIL(request->engine,
+   intel_ring_offset(request->ring, request->tail));
 }
 
 static void
@@ -2081,6 +2082,8 @@ intel_engine_create_ring(struct intel_engine_cs *engine, 
int size)
struct intel_ring *ring;
int ret;
 
+   GEM_BUG_ON(!is_power_of_2(size));
+
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (ring == NULL) {
DRM_DEBUG_DRIVER("Failed to allocate ringbuffer %s\n",
@@ -2505,7 +2508,8 @@ static void gen6_bsd_submit_request(struct 
drm_i915_gem_request *request)
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
 
/* Now that the ring is fully powered up, update the tail */
-   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), request->tail);
+   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
+ intel_ring_offset(request->ring, request->tail));
POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
 
/* Let the ring send IDLE messages to the GT again,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 14d2ea36fb88..7d4a2814b331 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -460,14 +460,20 @@ static inline void intel_ring_emit_reg(struct intel_ring 
*ring, i915_reg_t reg)
 
 static inline void intel_ring_advance(struct intel_ring *ring)
 {
-   /* The modulus is required so that we avoid writing
-* request->tail == ring->size, rather than the expected 0,
-* into the RING_TAIL register as that can cause a GPU hang.
-* As this is only strictly required for the request->tail,
-* and only then as we write the value into hardware, we can
-* one day remove the modulus after every command packet.
+   /* Dummy function.
+*
+* This serves as a placeholder in the code so that the reader
+* can compare against the preceding intel_ring_begin() and
+* check that the number of dwords emitted matches the space
+* reserved for the command packet (i.e. the value passed to
+* intel_ring_begin()).
 */
-   ring->tail &= ring->size - 1;
+}
+
+static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
+{
+   /* Don't write ring->size (equivalent to 0) as that hangs some GPUs. */
+   return value & (ring->size - 1);
 }
 
 int __intel_ring_space(int head, int tail, int size);
-- 
2.8.1

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

[Intel-gfx] [CI 11/23] drm/i915: Remove intel_ring_get_tail()

[Chris Wilson]

Joonas doesn't like the tiny function, especially if I go around making
it more complicated and using it elsewhere. To remove that temptation,
remove the function!

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-21-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 8 
 drivers/gpu/drm/i915/intel_ringbuffer.h | 5 -
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index f4e6c40ac4e3..606b0b8a5f91 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -419,7 +419,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
 * should already have been reserved in the ring buffer. Let the ring
 * know that it is time to use that space up.
 */
-   request_start = intel_ring_get_tail(ring);
+   request_start = ring->tail;
reserved_tail = request->reserved_space;
request->reserved_space = 0;
 
@@ -464,19 +464,19 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
 * GPU processing the request, we never over-estimate the
 * position of the head.
 */
-   request->postfix = intel_ring_get_tail(ring);
+   request->postfix = ring->tail;
 
if (i915.enable_execlists) {
ret = engine->emit_request(request);
} else {
ret = engine->add_request(request);
 
-   request->tail = intel_ring_get_tail(ring);
+   request->tail = ring->tail;
}
/* Not allowed to fail! */
WARN(ret, "emit|add_request failed: %d!\n", ret);
/* Sanity check that the reserved size was large enough. */
-   ret = intel_ring_get_tail(ring) - request_start;
+   ret = ring->tail - request_start;
if (ret < 0)
ret += ring->size;
WARN_ONCE(ret > reserved_tail,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 45ba29c0b20e..0c3c7185d9ad 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -490,11 +490,6 @@ static inline u32 intel_engine_get_seqno(struct 
intel_engine_cs *engine)
 
 int init_workarounds_ring(struct intel_engine_cs *engine);
 
-static inline u32 intel_ring_get_tail(struct intel_ring *ring)
-{
-   return ring->tail;
-}
-
 /*
  * Arbitrary size for largest possible 'add request' sequence. The code paths
  * are complex and variable. Empirical measurement shows that the worst case
-- 
2.8.1

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

[Intel-gfx] [CI 20/23] drm/i915: Refactor golden render state emission to unconfuse gcc

[Chris Wilson]

GCC was inlining the init and setup functions, but was getting itself
confused into thinking that variables could be used uninitialised. If we
do the inline for gcc, it is happy! As a bonus we shrink the code.

v2: A couple of minor tweaks from Joonas

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-29-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_render_state.c | 95 
 1 file changed, 27 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index a9b56d18a93b..f85c5505bce2 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -32,15 +32,14 @@ struct render_state {
const struct intel_renderstate_rodata *rodata;
struct drm_i915_gem_object *obj;
u64 ggtt_offset;
-   int gen;
u32 aux_batch_size;
u32 aux_batch_offset;
 };
 
 static const struct intel_renderstate_rodata *
-render_state_get_rodata(const int gen)
+render_state_get_rodata(const struct drm_i915_gem_request *req)
 {
-   switch (gen) {
+   switch (INTEL_GEN(req->i915)) {
case 6:
return &gen6_null_state;
case 7:
@@ -54,36 +53,6 @@ render_state_get_rodata(const int gen)
return NULL;
 }
 
-static int render_state_init(struct render_state *so,
-struct drm_i915_private *dev_priv)
-{
-   int ret;
-
-   so->gen = INTEL_GEN(dev_priv);
-   so->ggtt_offset = 0; /* keep gcc quiet */
-   so->rodata = render_state_get_rodata(so->gen);
-   if (so->rodata == NULL)
-   return 0;
-
-   if (so->rodata->batch_items * 4 > 4096)
-   return -EINVAL;
-
-   so->obj = i915_gem_object_create(&dev_priv->drm, 4096);
-   if (IS_ERR(so->obj))
-   return PTR_ERR(so->obj);
-
-   ret = i915_gem_obj_ggtt_pin(so->obj, 4096, 0);
-   if (ret)
-   goto free_gem;
-
-   so->ggtt_offset = i915_gem_obj_ggtt_offset(so->obj);
-   return 0;
-
-free_gem:
-   i915_gem_object_put(so->obj);
-   return ret;
-}
-
 /*
  * Macro to add commands to auxiliary batch.
  * This macro only checks for page overflow before inserting the commands,
@@ -106,6 +75,7 @@ static int render_state_setup(struct render_state *so)
 {
struct drm_device *dev = so->obj->base.dev;
const struct intel_renderstate_rodata *rodata = so->rodata;
+   const bool has_64bit_reloc = INTEL_GEN(dev) >= 8;
unsigned int i = 0, reloc_index = 0;
struct page *page;
u32 *d;
@@ -124,7 +94,7 @@ static int render_state_setup(struct render_state *so)
if (i * 4  == rodata->reloc[reloc_index]) {
u64 r = s + so->ggtt_offset;
s = lower_32_bits(r);
-   if (so->gen >= 8) {
+   if (has_64bit_reloc) {
if (i + 1 >= rodata->batch_items ||
rodata->batch[i + 1] != 0) {
ret = -EINVAL;
@@ -202,53 +172,40 @@ err_out:
 
 #undef OUT_BATCH
 
-static void render_state_fini(struct render_state *so)
-{
-   i915_gem_object_ggtt_unpin(so->obj);
-   i915_gem_object_put(so->obj);
-}
-
-static int render_state_prepare(struct intel_engine_cs *engine,
-   struct render_state *so)
+int i915_gem_render_state_init(struct drm_i915_gem_request *req)
 {
+   struct render_state so;
int ret;
 
-   if (WARN_ON(engine->id != RCS))
+   if (WARN_ON(req->engine->id != RCS))
return -ENOENT;
 
-   ret = render_state_init(so, engine->i915);
-   if (ret)
-   return ret;
-
-   if (so->rodata == NULL)
+   so.rodata = render_state_get_rodata(req);
+   if (!so.rodata)
return 0;
 
-   ret = render_state_setup(so);
-   if (ret) {
-   render_state_fini(so);
-   return ret;
-   }
-
-   return 0;
-}
+   if (so.rodata->batch_items * 4 > 4096)
+   return -EINVAL;
 
-int i915_gem_render_state_init(struct drm_i915_gem_request *req)
-{
-   struct render_state so;
-   int ret;
+   so.obj = i915_gem_object_create(&req->i915->drm, 4096);
+   if (IS_ERR(so.obj))
+   return PTR_ERR(so.obj);
 
-   ret = render_state_prepare(req->engine, &so);
+   ret = i915_gem_obj_ggtt_pin(so.obj, 4096, 0);
if (ret)
-   return ret;
+   goto err_obj;
 
-   if (so.rodata == NULL)
-   return 0;
+   so.ggtt_offset = i915_gem_obj_ggtt_offset(so.obj);
+
+   ret = render_state_setup(&so);
+   if (ret)
+   goto err_unpin;
 
ret = req->engine->emit_bb_start(req, so.ggtt_offset,

[Intel-gfx] [CI 05/23] drm/i915: Rename residual ringbuf parameters

[Chris Wilson]

Now that we have a clear ring/engine split and a struct intel_ring, we
no longer need the stopgap ringbuf names.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-16-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 66 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  6 +--
 2 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index acbabbdececd..5dd720e7feaa 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -47,15 +47,15 @@ int __intel_ring_space(int head, int tail, int size)
return space - I915_RING_FREE_SPACE;
 }
 
-void intel_ring_update_space(struct intel_ring *ringbuf)
+void intel_ring_update_space(struct intel_ring *ring)
 {
-   if (ringbuf->last_retired_head != -1) {
-   ringbuf->head = ringbuf->last_retired_head;
-   ringbuf->last_retired_head = -1;
+   if (ring->last_retired_head != -1) {
+   ring->head = ring->last_retired_head;
+   ring->last_retired_head = -1;
}
 
-   ringbuf->space = __intel_ring_space(ringbuf->head & HEAD_ADDR,
-   ringbuf->tail, ringbuf->size);
+   ring->space = __intel_ring_space(ring->head & HEAD_ADDR,
+ring->tail, ring->size);
 }
 
 static void __intel_engine_submit(struct intel_engine_cs *engine)
@@ -1993,25 +1993,25 @@ static int init_phys_status_page(struct intel_engine_cs 
*engine)
return 0;
 }
 
-void intel_unpin_ring(struct intel_ring *ringbuf)
+void intel_unpin_ring(struct intel_ring *ring)
 {
-   GEM_BUG_ON(!ringbuf->vma);
-   GEM_BUG_ON(!ringbuf->vaddr);
+   GEM_BUG_ON(!ring->vma);
+   GEM_BUG_ON(!ring->vaddr);
 
-   if (HAS_LLC(ringbuf->obj->base.dev) && !ringbuf->obj->stolen)
-   i915_gem_object_unpin_map(ringbuf->obj);
+   if (HAS_LLC(ring->obj->base.dev) && !ring->obj->stolen)
+   i915_gem_object_unpin_map(ring->obj);
else
-   i915_vma_unpin_iomap(ringbuf->vma);
-   ringbuf->vaddr = NULL;
+   i915_vma_unpin_iomap(ring->vma);
+   ring->vaddr = NULL;
 
-   i915_gem_object_ggtt_unpin(ringbuf->obj);
-   ringbuf->vma = NULL;
+   i915_gem_object_ggtt_unpin(ring->obj);
+   ring->vma = NULL;
 }
 
 int intel_pin_and_map_ring(struct drm_i915_private *dev_priv,
-  struct intel_ring *ringbuf)
+  struct intel_ring *ring)
 {
-   struct drm_i915_gem_object *obj = ringbuf->obj;
+   struct drm_i915_gem_object *obj = ring->obj;
/* Ring wraparound at offset 0 sometimes hangs. No idea why. */
unsigned flags = PIN_OFFSET_BIAS | 4096;
void *addr;
@@ -2052,8 +2052,8 @@ int intel_pin_and_map_ring(struct drm_i915_private 
*dev_priv,
}
}
 
-   ringbuf->vaddr = addr;
-   ringbuf->vma = i915_gem_obj_to_ggtt(obj);
+   ring->vaddr = addr;
+   ring->vma = i915_gem_obj_to_ggtt(obj);
return 0;
 
 err_unpin:
@@ -2061,29 +2061,29 @@ err_unpin:
return ret;
 }
 
-static void intel_destroy_ringbuffer_obj(struct intel_ring *ringbuf)
+static void intel_destroy_ringbuffer_obj(struct intel_ring *ring)
 {
-   i915_gem_object_put(ringbuf->obj);
-   ringbuf->obj = NULL;
+   i915_gem_object_put(ring->obj);
+   ring->obj = NULL;
 }
 
 static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
- struct intel_ring *ringbuf)
+ struct intel_ring *ring)
 {
struct drm_i915_gem_object *obj;
 
obj = NULL;
if (!HAS_LLC(dev))
-   obj = i915_gem_object_create_stolen(dev, ringbuf->size);
+   obj = i915_gem_object_create_stolen(dev, ring->size);
if (obj == NULL)
-   obj = i915_gem_object_create(dev, ringbuf->size);
+   obj = i915_gem_object_create(dev, ring->size);
if (IS_ERR(obj))
return PTR_ERR(obj);
 
/* mark ring buffers as read-only from GPU side by default */
obj->gt_ro = 1;
 
-   ringbuf->obj = obj;
+   ring->obj = obj;
 
return 0;
 }
@@ -2190,7 +2190,7 @@ static void intel_ring_context_unpin(struct 
i915_gem_context *ctx,
 static int intel_init_ring_buffer(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
-   struct intel_ring *ringbuf;
+   struct intel_ring *ring;
int ret;
 
WARN_ON(engine->buffer);
@@ -2215,12 +2215,12 @@ static int intel_init_ring_buffer(struct 
intel_engine_cs *engine)
if (ret)
goto error;
 
-   ringbuf = intel_engine_create_ring(engine, 32 * PAGE_SIZE);
-   if (IS_ERR(ringbuf)) {
- 

[Intel-gfx] [CI 04/23] drm/i915: Rename struct intel_ringbuffer to struct intel_ring

[Chris Wilson]

The state stored in this struct is not only the information about the
buffer object, but the ring used to communicate with the hardware. Using
buffer here is overly specific and, for me at least, conflates with the
notion of buffer objects themselves.

s/struct intel_ringbuffer/struct intel_ring/
s/enum intel_ring_hangcheck/enum intel_engine_hangcheck/
s/describe_ctx_ringbuf()/describe_ctx_ring()/
s/intel_ring_get_active_head()/intel_engine_get_active_head()/
s/intel_ring_sync_index()/intel_engine_sync_index()/
s/intel_ring_init_seqno()/intel_engine_init_seqno()/
s/ring_stuck()/engine_stuck()/
s/intel_cleanup_engine()/intel_engine_cleanup()/
s/intel_stop_engine()/intel_engine_stop()/
s/intel_pin_and_map_ringbuffer_obj()/intel_pin_and_map_ring()/
s/intel_unpin_ringbuffer()/intel_unpin_ring()/
s/intel_engine_create_ringbuffer()/intel_engine_create_ring()/
s/intel_ring_flush_all_caches()/intel_engine_flush_all_caches()/
s/intel_ring_invalidate_all_caches()/intel_engine_invalidate_all_caches()/
s/intel_ringbuffer_free()/intel_ring_free()/

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-15-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_debugfs.c|  11 ++-
 drivers/gpu/drm/i915/i915_drv.h|   4 +-
 drivers/gpu/drm/i915/i915_gem.c|  16 ++--
 drivers/gpu/drm/i915/i915_gem_context.c|   6 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   6 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|   6 +-
 drivers/gpu/drm/i915/i915_gem_request.c|   6 +-
 drivers/gpu/drm/i915/i915_gem_request.h|   2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |   8 +-
 drivers/gpu/drm/i915/i915_irq.c|  14 ++--
 drivers/gpu/drm/i915/intel_display.c   |  10 +--
 drivers/gpu/drm/i915/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  34 
 drivers/gpu/drm/i915/intel_mocs.c  |   4 +-
 drivers/gpu/drm/i915/intel_overlay.c   |   8 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c| 128 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  51 ++--
 17 files changed, 157 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b67fb4c26178..410dc35a7a8a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1419,7 +1419,7 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
intel_runtime_pm_get(dev_priv);
 
for_each_engine_id(engine, dev_priv, id) {
-   acthd[id] = intel_ring_get_active_head(engine);
+   acthd[id] = intel_engine_get_active_head(engine);
seqno[id] = intel_engine_get_seqno(engine);
}
 
@@ -2036,12 +2036,11 @@ static int i915_gem_framebuffer_info(struct seq_file 
*m, void *data)
return 0;
 }
 
-static void describe_ctx_ringbuf(struct seq_file *m,
-struct intel_ringbuffer *ringbuf)
+static void describe_ctx_ring(struct seq_file *m, struct intel_ring *ring)
 {
seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u, last head: 
%d)",
-  ringbuf->space, ringbuf->head, ringbuf->tail,
-  ringbuf->last_retired_head);
+  ring->space, ring->head, ring->tail,
+  ring->last_retired_head);
 }
 
 static int i915_context_status(struct seq_file *m, void *unused)
@@ -2086,7 +2085,7 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
if (ce->state)
describe_obj(m, ce->state);
if (ce->ring)
-   describe_ctx_ringbuf(m, ce->ring);
+   describe_ctx_ring(m, ce->ring);
seq_putc(m, '\n');
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db43ced6f5e6..4c43bd3d74b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -518,7 +518,7 @@ struct drm_i915_error_state {
bool waiting;
int num_waiters;
int hangcheck_score;
-   enum intel_ring_hangcheck_action hangcheck_action;
+   enum intel_engine_hangcheck_action hangcheck_action;
int num_requests;
 
/* our own tracking of ring head and tail */
@@ -894,7 +894,7 @@ struct i915_gem_context {
 
struct intel_context {
struct drm_i915_gem_object *state;
-   struct intel_ringbuffer *ring;
+   struct intel_ring *ring;
struct i915_vma *lrc_vma;
uint32_t *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7bfce1d5c61b..59890f523c5f 100644
--- a/drivers/gpu/drm/i915/i915_gem.

[Intel-gfx] [CI 14/23] drm/i915: Unify request submission

[Chris Wilson]

Move request submission from emit_request into its own common vfunc
from i915_add_request().

v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing
v3: Rename a few functions to match.
v4: Reenable execlists submission after disabling guc.
v5: Be aware that everyone calls i915_guc_submission_disable()!

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-23-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c|  8 +++-
 drivers/gpu/drm/i915/i915_guc_submission.c | 15 ---
 drivers/gpu/drm/i915/intel_guc.h   |  1 -
 drivers/gpu/drm/i915/intel_lrc.c   | 26 +++---
 drivers/gpu/drm/i915/intel_lrc.h   |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c| 23 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h| 27 +--
 7 files changed, 54 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a885905df3bb..e378eb61979b 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -466,12 +466,9 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
 */
request->postfix = ring->tail;
 
-   if (i915.enable_execlists)
-   ret = engine->emit_request(request);
-   else
-   ret = engine->add_request(request);
/* Not allowed to fail! */
-   WARN(ret, "emit|add_request failed: %d!\n", ret);
+   ret = engine->emit_request(request);
+   WARN(ret, "(%s)->emit_request failed: %d!\n", engine->name, ret);
 
/* Sanity check that the reserved size was large enough. */
ret = ring->tail - request_start;
@@ -483,6 +480,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
  reserved_tail, ret);
 
i915_gem_mark_busy(engine);
+   engine->submit_request(request);
 }
 
 static unsigned long local_clock_us(unsigned int *cpu)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index eccd34832fe6..5de867585275 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -585,7 +585,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
  * The only error here arises if the doorbell hardware isn't functioning
  * as expected, which really shouln't happen.
  */
-int i915_guc_submit(struct drm_i915_gem_request *rq)
+static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
unsigned int engine_id = rq->engine->id;
struct intel_guc *guc = &rq->i915->guc;
@@ -602,8 +602,6 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
 
guc->submissions[engine_id] += 1;
guc->last_seqno[engine_id] = rq->fence.seqno;
-
-   return b_ret;
 }
 
 /*
@@ -992,6 +990,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
 {
struct intel_guc *guc = &dev_priv->guc;
struct i915_guc_client *client;
+   struct intel_engine_cs *engine;
 
/* client for execbuf submission */
client = guc_client_alloc(dev_priv,
@@ -1006,6 +1005,10 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
host2guc_sample_forcewake(guc, client);
guc_init_doorbell_hw(guc);
 
+   /* Take over from manual control of ELSP (execlists) */
+   for_each_engine(engine, dev_priv)
+   engine->submit_request = i915_guc_submit;
+
return 0;
 }
 
@@ -1013,8 +1016,14 @@ void i915_guc_submission_disable(struct drm_i915_private 
*dev_priv)
 {
struct intel_guc *guc = &dev_priv->guc;
 
+   if (!guc->execbuf_client)
+   return;
+
guc_client_free(dev_priv, guc->execbuf_client);
guc->execbuf_client = NULL;
+
+   /* Revert back to manual ELSP submission */
+   intel_execlists_enable_submission(dev_priv);
 }
 
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743740c0..623cf26cd784 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -160,7 +160,6 @@ extern int intel_guc_resume(struct drm_device *dev);
 int i915_guc_submission_init(struct drm_i915_private *dev_priv);
 int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
 int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
-int i915_guc_submit(struct drm_i915_gem_request *rq);
 void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 824f7efe4e64..8a72ee86e825 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -738,7 +738,7 @@ err_unpin:
 }
 

[Intel-gfx] [CI 07/23] drm/i915: Remove obsolete engine->gpu_caches_dirty

[Chris Wilson]

Space for flushing the GPU cache prior to completing the request is
preallocated and so cannot fail - the GPU caches will always be flushed
along with the completed request. This means we no longer have to track
whether the GPU cache is dirty between batches like we had to with the
outstanding_lazy_seqno.

With the removal of the duplication in the per-backend entry points for
emitting the obsolete lazy flush, we can then further unify the
engine->emit_flush.

v2: Expand a bit on the legacy of gpu_caches_dirty

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-18-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_context.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  9 +---
 drivers/gpu/drm/i915/i915_gem_gtt.c| 11 +++--
 drivers/gpu/drm/i915/i915_gem_request.c|  8 ++--
 drivers/gpu/drm/i915/intel_lrc.c   | 47 +++
 drivers/gpu/drm/i915/intel_lrc.h   |  2 -
 drivers/gpu/drm/i915/intel_ringbuffer.c| 72 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  7 ---
 8 files changed, 37 insertions(+), 121 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3336a5fcd029..beece8feb8fe 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -568,7 +568,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 * itlb_before_ctx_switch.
 */
if (IS_GEN6(dev_priv)) {
-   ret = engine->flush(req, I915_GEM_GPU_DOMAINS, 0);
+   ret = engine->emit_flush(req, I915_GEM_GPU_DOMAINS, 0);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index d0ef675fb169..35c4c595e5ba 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -998,10 +998,8 @@ i915_gem_execbuffer_move_to_gpu(struct 
drm_i915_gem_request *req,
if (flush_domains & I915_GEM_DOMAIN_GTT)
wmb();
 
-   /* Unconditionally invalidate gpu caches and ensure that we do flush
-* any residual writes from the previous batch.
-*/
-   return intel_engine_invalidate_all_caches(req);
+   /* Unconditionally invalidate GPU caches and TLBs. */
+   return req->engine->emit_flush(req, I915_GEM_GPU_DOMAINS, 0);
 }
 
 static bool
@@ -1163,9 +1161,6 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas,
 static void
 i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params *params)
 {
-   /* Unconditionally force add_request to emit a full flush. */
-   params->engine->gpu_caches_dirty = true;
-
/* Add a breadcrumb for the completion of the batch buffer */
__i915_add_request(params->request, params->batch_obj, true);
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ebfa0406a6a1..39fa9eb10514 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1666,7 +1666,8 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
int ret;
 
/* NB: TLBs must be flushed and invalidated before a switch */
-   ret = engine->flush(req, I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
+   ret = engine->emit_flush(req,
+I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
 
@@ -1693,7 +1694,8 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
int ret;
 
/* NB: TLBs must be flushed and invalidated before a switch */
-   ret = engine->flush(req, I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
+   ret = engine->emit_flush(req,
+I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
 
@@ -1711,8 +1713,9 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
 
/* XXX: RCS is the only one to auto invalidate the TLBs? */
if (engine->id != RCS) {
-   ret = engine->flush(req,
-   I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
+   ret = engine->emit_flush(req,
+I915_GEM_GPU_DOMAINS,
+I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 942b5b1f1602..7e3206051ced 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -451,12 +451,10 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
 * what.
 */
if (flush_caches) {
-   if (i915.enable_execlists)
-  

[Intel-gfx] [CI 06/23] drm/i915: Rename intel_pin_and_map_ring()

[Chris Wilson]

For more consistent oop-naming, we would use intel_ring_verb, so pick
intel_ring_pin() and intel_ring_unpin().

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-17-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_lrc.c|  4 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 38 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 ++---
 3 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9668331f973a..e4f809f879c6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -973,7 +973,7 @@ static int intel_lr_context_pin(struct i915_gem_context 
*ctx,
 
lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
 
-   ret = intel_pin_and_map_ring(dev_priv, ce->ring);
+   ret = intel_ring_pin(ce->ring);
if (ret)
goto unpin_map;
 
@@ -1011,7 +1011,7 @@ void intel_lr_context_unpin(struct i915_gem_context *ctx,
if (--ce->pin_count)
return;
 
-   intel_unpin_ring(ce->ring);
+   intel_ring_unpin(ce->ring);
 
i915_gem_object_unpin_map(ce->state);
i915_gem_object_ggtt_unpin(ce->state);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5dd720e7feaa..e7a7f67ab06d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1993,24 +1993,9 @@ static int init_phys_status_page(struct intel_engine_cs 
*engine)
return 0;
 }
 
-void intel_unpin_ring(struct intel_ring *ring)
-{
-   GEM_BUG_ON(!ring->vma);
-   GEM_BUG_ON(!ring->vaddr);
-
-   if (HAS_LLC(ring->obj->base.dev) && !ring->obj->stolen)
-   i915_gem_object_unpin_map(ring->obj);
-   else
-   i915_vma_unpin_iomap(ring->vma);
-   ring->vaddr = NULL;
-
-   i915_gem_object_ggtt_unpin(ring->obj);
-   ring->vma = NULL;
-}
-
-int intel_pin_and_map_ring(struct drm_i915_private *dev_priv,
-  struct intel_ring *ring)
+int intel_ring_pin(struct intel_ring *ring)
 {
+   struct drm_i915_private *dev_priv = ring->engine->i915;
struct drm_i915_gem_object *obj = ring->obj;
/* Ring wraparound at offset 0 sometimes hangs. No idea why. */
unsigned flags = PIN_OFFSET_BIAS | 4096;
@@ -2061,6 +2046,21 @@ err_unpin:
return ret;
 }
 
+void intel_ring_unpin(struct intel_ring *ring)
+{
+   GEM_BUG_ON(!ring->vma);
+   GEM_BUG_ON(!ring->vaddr);
+
+   if (HAS_LLC(ring->engine->i915) && !ring->obj->stolen)
+   i915_gem_object_unpin_map(ring->obj);
+   else
+   i915_vma_unpin_iomap(ring->vma);
+   ring->vaddr = NULL;
+
+   i915_gem_object_ggtt_unpin(ring->obj);
+   ring->vma = NULL;
+}
+
 static void intel_destroy_ringbuffer_obj(struct intel_ring *ring)
 {
i915_gem_object_put(ring->obj);
@@ -2233,7 +2233,7 @@ static int intel_init_ring_buffer(struct intel_engine_cs 
*engine)
goto error;
}
 
-   ret = intel_pin_and_map_ring(dev_priv, ring);
+   ret = intel_ring_pin(ring);
if (ret) {
DRM_ERROR("Failed to pin and map ringbuffer %s: %d\n",
engine->name, ret);
@@ -2261,7 +2261,7 @@ void intel_engine_cleanup(struct intel_engine_cs *engine)
intel_engine_stop(engine);
WARN_ON(!IS_GEN2(dev_priv) && (I915_READ_MODE(engine) & 
MODE_IDLE) == 0);
 
-   intel_unpin_ring(engine->buffer);
+   intel_ring_unpin(engine->buffer);
intel_ring_free(engine->buffer);
engine->buffer = NULL;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2dfc418c5102..ba54ffcdd55a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -441,9 +441,8 @@ intel_write_status_page(struct intel_engine_cs *engine,
 
 struct intel_ring *
 intel_engine_create_ring(struct intel_engine_cs *engine, int size);
-int intel_pin_and_map_ring(struct drm_i915_private *dev_priv,
-  struct intel_ring *ring);
-void intel_unpin_ring(struct intel_ring *ring);
+int intel_ring_pin(struct intel_ring *ring);
+void intel_ring_unpin(struct intel_ring *ring);
 void intel_ring_free(struct intel_ring *ring);
 
 void intel_engine_stop(struct intel_engine_cs *engine);
-- 
2.8.1

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

[Intel-gfx] [CI 19/23] drm/i915: Remove duplicate golden render state init from execlists

[Chris Wilson]

Now that we use the same vfuncs for emitting the batch buffer in both
execlists and legacy, the golden render state initialisation is
identical between both.

v2: gcc wants so.ggtt_offset initialised (even though it is not used)

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-28-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem_render_state.c | 23 +--
 drivers/gpu/drm/i915/i915_gem_render_state.h | 18 ---
 drivers/gpu/drm/i915/intel_lrc.c | 34 +---
 drivers/gpu/drm/i915/intel_renderstate.h | 16 +
 4 files changed, 28 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 2ba759f3ab6f..a9b56d18a93b 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -28,6 +28,15 @@
 #include "i915_drv.h"
 #include "intel_renderstate.h"
 
+struct render_state {
+   const struct intel_renderstate_rodata *rodata;
+   struct drm_i915_gem_object *obj;
+   u64 ggtt_offset;
+   int gen;
+   u32 aux_batch_size;
+   u32 aux_batch_offset;
+};
+
 static const struct intel_renderstate_rodata *
 render_state_get_rodata(const int gen)
 {
@@ -51,6 +60,7 @@ static int render_state_init(struct render_state *so,
int ret;
 
so->gen = INTEL_GEN(dev_priv);
+   so->ggtt_offset = 0; /* keep gcc quiet */
so->rodata = render_state_get_rodata(so->gen);
if (so->rodata == NULL)
return 0;
@@ -192,14 +202,14 @@ err_out:
 
 #undef OUT_BATCH
 
-void i915_gem_render_state_fini(struct render_state *so)
+static void render_state_fini(struct render_state *so)
 {
i915_gem_object_ggtt_unpin(so->obj);
i915_gem_object_put(so->obj);
 }
 
-int i915_gem_render_state_prepare(struct intel_engine_cs *engine,
- struct render_state *so)
+static int render_state_prepare(struct intel_engine_cs *engine,
+   struct render_state *so)
 {
int ret;
 
@@ -215,7 +225,7 @@ int i915_gem_render_state_prepare(struct intel_engine_cs 
*engine,
 
ret = render_state_setup(so);
if (ret) {
-   i915_gem_render_state_fini(so);
+   render_state_fini(so);
return ret;
}
 
@@ -227,7 +237,7 @@ int i915_gem_render_state_init(struct drm_i915_gem_request 
*req)
struct render_state so;
int ret;
 
-   ret = i915_gem_render_state_prepare(req->engine, &so);
+   ret = render_state_prepare(req->engine, &so);
if (ret)
return ret;
 
@@ -251,8 +261,7 @@ int i915_gem_render_state_init(struct drm_i915_gem_request 
*req)
}
 
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), req);
-
 out:
-   i915_gem_render_state_fini(&so);
+   render_state_fini(&so);
return ret;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.h 
b/drivers/gpu/drm/i915/i915_gem_render_state.h
index 6aaa3a10a630..c44fca8599bb 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.h
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.h
@@ -26,24 +26,6 @@
 
 #include 
 
-struct intel_renderstate_rodata {
-   const u32 *reloc;
-   const u32 *batch;
-   const u32 batch_items;
-};
-
-struct render_state {
-   const struct intel_renderstate_rodata *rodata;
-   struct drm_i915_gem_object *obj;
-   u64 ggtt_offset;
-   int gen;
-   u32 aux_batch_size;
-   u32 aux_batch_offset;
-};
-
 int i915_gem_render_state_init(struct drm_i915_gem_request *req);
-void i915_gem_render_state_fini(struct render_state *so);
-int i915_gem_render_state_prepare(struct intel_engine_cs *engine,
- struct render_state *so);
 
 #endif /* _I915_GEM_RENDER_STATE_H_ */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 961767929fed..8160416f0018 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1798,38 +1798,6 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
return intel_logical_ring_advance(request);
 }
 
-static int intel_lr_context_render_state_init(struct drm_i915_gem_request *req)
-{
-   struct render_state so;
-   int ret;
-
-   ret = i915_gem_render_state_prepare(req->engine, &so);
-   if (ret)
-   return ret;
-
-   if (so.rodata == NULL)
-   return 0;
-
-   ret = req->engine->emit_bb_start(req, so.ggtt_offset,
-so.rodata->batch_items * 4,
-I915_DISPATCH_SECURE);
-   if (ret)
-   goto out;
-
-   ret = req->engine->emit_bb_start(req,
-(so.ggtt_offset + so.aux_batch_offset),
- 

[Intel-gfx] [CI 08/23] drm/i915: Reduce engine->emit_flush() to a single mode parameter

[Chris Wilson]

Rather than passing a complete set of GPU cache domains for either
invalidation or for flushing, or even both, just pass a single parameter
to the engine->emit_flush to determine the required operations.

engine->emit_flush(GPU, 0) -> engine->emit_flush(EMIT_INVALIDATE)
engine->emit_flush(0, GPU) -> engine->emit_flush(EMIT_FLUSH)
engine->emit_flush(GPU, GPU) -> engine->emit_flush(EMIT_FLUSH | EMIT_INVALIDATE)

This allows us to extend the behaviour easily in future, for example if
we want just a command barrier without the overhead of flushing.

Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_context.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 10 ++
 drivers/gpu/drm/i915/i915_gem_request.c|  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 23 +---
 drivers/gpu/drm/i915/intel_ringbuffer.c| 57 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  6 ++--
 7 files changed, 38 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index beece8feb8fe..edde8411c478 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -568,7 +568,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 * itlb_before_ctx_switch.
 */
if (IS_GEN6(dev_priv)) {
-   ret = engine->emit_flush(req, I915_GEM_GPU_DOMAINS, 0);
+   ret = engine->emit_flush(req, EMIT_INVALIDATE);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 35c4c595e5ba..e49776e34eed 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -999,7 +999,7 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request 
*req,
wmb();
 
/* Unconditionally invalidate GPU caches and TLBs. */
-   return req->engine->emit_flush(req, I915_GEM_GPU_DOMAINS, 0);
+   return req->engine->emit_flush(req, EMIT_INVALIDATE);
 }
 
 static bool
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 39fa9eb10514..671b1cab5e54 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1666,8 +1666,7 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
int ret;
 
/* NB: TLBs must be flushed and invalidated before a switch */
-   ret = engine->emit_flush(req,
-I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
+   ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
if (ret)
return ret;
 
@@ -1694,8 +1693,7 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
int ret;
 
/* NB: TLBs must be flushed and invalidated before a switch */
-   ret = engine->emit_flush(req,
-I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
+   ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
if (ret)
return ret;
 
@@ -1713,9 +1711,7 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
 
/* XXX: RCS is the only one to auto invalidate the TLBs? */
if (engine->id != RCS) {
-   ret = engine->emit_flush(req,
-I915_GEM_GPU_DOMAINS,
-I915_GEM_GPU_DOMAINS);
+   ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 7e3206051ced..67f16feb0552 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -451,7 +451,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
 * what.
 */
if (flush_caches) {
-   ret = engine->emit_flush(request, 0, I915_GEM_GPU_DOMAINS);
+   ret = engine->emit_flush(request, EMIT_FLUSH);
 
/* Not allowed to fail! */
WARN(ret, "engine->emit_flush() failed: %d!\n", ret);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 33ff9f6d588f..3f1c5cdd38a0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -672,7 +672,7 @@ static int execlists_move_to_gpu(struct 
drm_i915_gem_request *req,
/* Unconditionally invalidate gpu caches and ensure that we do flush
 * any residual writes from the previous batch.
 */
-   return req->engine->emit_flush(req, I915_GEM_GPU_DOMAINS, 0);
+   return req->engine->emit_flush(req, EMIT_INVALIDATE);
 }
 
 int intel_logical_ri

[Intel-gfx] [CI 12/23] drm/i915: Convert engine->write_tail to operate on a request

[Chris Wilson]

If we rewrite the I915_WRITE_TAIL specialisation for the legacy
ringbuffer as submitting the request onto the ringbuffer, we can unify
the vfunc with both execlists and GuC in the next patch.

v2: Drop the modulus from the I915_WRITE_TAIL as it is currently being
applied in intel_ring_advance() after every command packet, and add a
comment explaining why we need the modulus at all.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-22-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem_request.c |  8 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 51 -
 drivers/gpu/drm/i915/intel_ringbuffer.h | 10 +--
 3 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 606b0b8a5f91..a885905df3bb 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -466,15 +466,13 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
 */
request->postfix = ring->tail;
 
-   if (i915.enable_execlists) {
+   if (i915.enable_execlists)
ret = engine->emit_request(request);
-   } else {
+   else
ret = engine->add_request(request);
-
-   request->tail = ring->tail;
-   }
/* Not allowed to fail! */
WARN(ret, "emit|add_request failed: %d!\n", ret);
+
/* Sanity check that the reserved size was large enough. */
ret = ring->tail - request_start;
if (ret < 0)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 799a7dc02675..3142085b5cc0 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -58,14 +58,6 @@ void intel_ring_update_space(struct intel_ring *ring)
 ring->tail, ring->size);
 }
 
-static void __intel_engine_submit(struct intel_engine_cs *engine)
-{
-   struct intel_ring *ring = engine->buffer;
-
-   ring->tail &= ring->size - 1;
-   engine->write_tail(engine, ring->tail);
-}
-
 static int
 gen2_render_ring_flush(struct drm_i915_gem_request *req, u32 mode)
 {
@@ -412,13 +404,6 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req, 
u32 mode)
return gen8_emit_pipe_control(req, flags, scratch_addr);
 }
 
-static void ring_write_tail(struct intel_engine_cs *engine,
-   u32 value)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   I915_WRITE_TAIL(engine, value);
-}
-
 u64 intel_engine_get_active_head(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
@@ -532,7 +517,7 @@ static bool stop_ring(struct intel_engine_cs *engine)
 
I915_WRITE_CTL(engine, 0);
I915_WRITE_HEAD(engine, 0);
-   engine->write_tail(engine, 0);
+   I915_WRITE_TAIL(engine, 0);
 
if (!IS_GEN2(dev_priv)) {
(void)I915_READ_CTL(engine);
@@ -1469,7 +1454,10 @@ gen6_add_request(struct drm_i915_gem_request *req)
intel_ring_emit(ring, I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT);
intel_ring_emit(ring, req->fence.seqno);
intel_ring_emit(ring, MI_USER_INTERRUPT);
-   __intel_engine_submit(engine);
+   intel_ring_advance(ring);
+
+   req->tail = ring->tail;
+   engine->submit_request(req);
 
return 0;
 }
@@ -1499,7 +1487,9 @@ gen8_render_add_request(struct drm_i915_gem_request *req)
intel_ring_emit(ring, 0);
intel_ring_emit(ring, MI_USER_INTERRUPT);
intel_ring_emit(ring, MI_NOOP);
-   __intel_engine_submit(engine);
+
+   req->tail = ring->tail;
+   engine->submit_request(req);
 
return 0;
 }
@@ -1716,11 +1706,21 @@ i9xx_add_request(struct drm_i915_gem_request *req)
intel_ring_emit(ring, I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT);
intel_ring_emit(ring, req->fence.seqno);
intel_ring_emit(ring, MI_USER_INTERRUPT);
-   __intel_engine_submit(req->engine);
+   intel_ring_advance(ring);
+
+   req->tail = ring->tail;
+   req->engine->submit_request(req);
 
return 0;
 }
 
+static void i9xx_submit_request(struct drm_i915_gem_request *request)
+{
+   struct drm_i915_private *dev_priv = request->i915;
+
+   I915_WRITE_TAIL(request->engine, request->tail);
+}
+
 static void
 gen6_irq_enable(struct intel_engine_cs *engine)
 {
@@ -2479,10 +2479,9 @@ void intel_engine_init_seqno(struct intel_engine_cs 
*engine, u32 seqno)
rcu_read_unlock();
 }
 
-static void gen6_bsd_ring_write_tail(struct intel_engine_cs *engine,
-u32 value)
+static void gen6_bsd_submit_request(struct drm_i915_gem_request *request)
 {
-   struct drm_i915_private *dev_priv = engine->i915;
+   struct drm_i915_private *dev_priv = 

[Intel-gfx] [CI 02/23] drm/i915: Rename request->ringbuf to request->ring

[Chris Wilson]

Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.

@@
struct drm_i915_gem_request *r;
@@
- r->ringbuf
+ r->ring

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-12-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_gem_context.c|  4 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  6 +-
 drivers/gpu/drm/i915/i915_gem_request.c| 16 +++---
 drivers/gpu/drm/i915/i915_gem_request.h|  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  | 19 +++---
 drivers/gpu/drm/i915/intel_display.c   | 10 ++--
 drivers/gpu/drm/i915/intel_lrc.c   | 57 +-
 drivers/gpu/drm/i915/intel_mocs.c  | 36 ++--
 drivers/gpu/drm/i915/intel_overlay.c   |  8 +--
 drivers/gpu/drm/i915/intel_ringbuffer.c| 92 +++---
 11 files changed, 125 insertions(+), 129 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a0e24eb5e167..f7f4a8c40afe 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -552,7 +552,7 @@ static inline int
 mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
 {
struct drm_i915_private *dev_priv = req->i915;
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
struct intel_engine_cs *engine = req->engine;
u32 flags = hw_flags | MI_MM_SPACE_GTT;
const int num_rings =
@@ -655,7 +655,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
 static int remap_l3(struct drm_i915_gem_request *req, int slice)
 {
u32 *remap_info = req->i915->l3_parity.remap_info[slice];
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
int i, ret;
 
if (!remap_info)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2f9f0daa1bc2..42389de4752a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1173,7 +1173,7 @@ i915_gem_execbuffer_retire_commands(struct 
i915_execbuffer_params *params)
 static int
 i915_reset_gen7_sol_offsets(struct drm_i915_gem_request *req)
 {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
int ret, i;
 
if (!IS_GEN7(req->i915) || req->engine->id != RCS) {
@@ -1303,7 +1303,7 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,
 
if (params->engine->id == RCS &&
instp_mode != dev_priv->relative_constants_mode) {
-   struct intel_ringbuffer *ring = params->request->ringbuf;
+   struct intel_ringbuffer *ring = params->request->ring;
 
ret = intel_ring_begin(params->request, 4);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b38a5311f996..46cae2a92bda 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -669,7 +669,7 @@ static int gen8_write_pdp(struct drm_i915_gem_request *req,
  unsigned entry,
  dma_addr_t addr)
 {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
struct intel_engine_cs *engine = req->engine;
int ret;
 
@@ -1661,7 +1661,7 @@ static uint32_t get_pd_offset(struct i915_hw_ppgtt *ppgtt)
 static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
 struct drm_i915_gem_request *req)
 {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
struct intel_engine_cs *engine = req->engine;
int ret;
 
@@ -1688,7 +1688,7 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
 static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
  struct drm_i915_gem_request *req)
 {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
struct intel_engine_cs *engine = req->engine;
int ret;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 49396b895a36..d2133c41be13 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -170,7 +170,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   request->ringbuf->last_retired_head = request->postfix;
+   request->ring->last_retired_head = request->postfix;
 
i915_gem_request_re

[Intel-gfx] [CI 09/23] drm/i915: Simplify request_alloc by returning the allocated request

[Chris Wilson]

If is simpler and leads to more readable code through the callstack if
the allocation returns the allocated struct through the return value.

The importance of this is that it no longer looks like we accidentally
allocate requests as side-effect of calling certain functions.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-19-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h|  3 +-
 drivers/gpu/drm/i915/i915_gem.c| 75 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 ++---
 drivers/gpu/drm/i915/i915_gem_request.c| 58 ---
 drivers/gpu/drm/i915/i915_trace.h  | 13 +++---
 drivers/gpu/drm/i915/intel_display.c   | 36 ++
 drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
 drivers/gpu/drm/i915/intel_overlay.c   | 20 
 8 files changed, 79 insertions(+), 140 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4c43bd3d74b1..8f4edc9dd7a3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3171,8 +3171,7 @@ static inline void i915_gem_object_unpin_map(struct 
drm_i915_gem_object *obj)
 
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
-struct intel_engine_cs *to,
-struct drm_i915_gem_request **to_req);
+struct drm_i915_gem_request *to);
 void i915_vma_move_to_active(struct i915_vma *vma,
 struct drm_i915_gem_request *req);
 int i915_gem_dumb_create(struct drm_file *file_priv,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 59890f523c5f..b6c4ff63725f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2845,51 +2845,35 @@ out:
 
 static int
 __i915_gem_object_sync(struct drm_i915_gem_object *obj,
-  struct intel_engine_cs *to,
-  struct drm_i915_gem_request *from_req,
-  struct drm_i915_gem_request **to_req)
+  struct drm_i915_gem_request *to,
+  struct drm_i915_gem_request *from)
 {
-   struct intel_engine_cs *from;
int ret;
 
-   from = i915_gem_request_get_engine(from_req);
-   if (to == from)
+   if (to->engine == from->engine)
return 0;
 
-   if (i915_gem_request_completed(from_req))
+   if (i915_gem_request_completed(from))
return 0;
 
if (!i915.semaphores) {
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   ret = __i915_wait_request(from_req,
- i915->mm.interruptible,
+   ret = __i915_wait_request(from,
+ from->i915->mm.interruptible,
  NULL,
  NO_WAITBOOST);
if (ret)
return ret;
 
-   i915_gem_object_retire_request(obj, from_req);
+   i915_gem_object_retire_request(obj, from);
} else {
-   int idx = intel_engine_sync_index(from, to);
-   u32 seqno = i915_gem_request_get_seqno(from_req);
+   int idx = intel_engine_sync_index(from->engine, to->engine);
+   u32 seqno = i915_gem_request_get_seqno(from);
 
-   WARN_ON(!to_req);
-
-   if (seqno <= from->semaphore.sync_seqno[idx])
+   if (seqno <= from->engine->semaphore.sync_seqno[idx])
return 0;
 
-   if (*to_req == NULL) {
-   struct drm_i915_gem_request *req;
-
-   req = i915_gem_request_alloc(to, NULL);
-   if (IS_ERR(req))
-   return PTR_ERR(req);
-
-   *to_req = req;
-   }
-
-   trace_i915_gem_ring_sync_to(*to_req, from, from_req);
-   ret = to->semaphore.sync_to(*to_req, from, seqno);
+   trace_i915_gem_ring_sync_to(to, from);
+   ret = to->engine->semaphore.sync_to(to, from->engine, seqno);
if (ret)
return ret;
 
@@ -2897,8 +2881,8 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
 * might have just caused seqno wrap under
 * the radar.
 */
-   from->semaphore.sync_seqno[idx] =
-   
i915_gem_request_get_seqno(obj->last_read_req[from->id]);
+   from->engine->semaphore.sync_seqno[idx] =
+   
i915_gem_request_get_seqno(obj->last_read_req[from->engine->id]);
}
 
return 0;
@@ -2908,17 +2892,12 @@ __i915_gem_object_s

[Intel-gfx] [CI 22/23] drm/i915: Simplify calling engine->sync_to

[Chris Wilson]

Since requests can no longer be generated as a side-effect of
intel_ring_begin(), we know that the seqno will be unchanged during
ring-emission. This predicatablity then means we do not have to check
for the seqno wrapping around whilst emitting the semaphore for
engine->sync_to().

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-31-git-send-email-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 13 ++-
 drivers/gpu/drm/i915/i915_gem_request.c |  9 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 64 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 ++-
 5 files changed, 30 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 49ce21a82c29..9b18b9c875ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1757,7 +1757,7 @@ struct drm_i915_private {
struct i915_gem_context *kernel_context;
struct intel_engine_cs engine[I915_NUM_ENGINES];
struct drm_i915_gem_object *semaphore_obj;
-   uint32_t last_seqno, next_seqno;
+   u32 next_seqno;
 
struct drm_dma_handle *status_page_dmah;
struct resource mch_res;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d79b949fb4c4..3df6b485d2d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2867,22 +2867,15 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
i915_gem_object_retire_request(obj, from);
} else {
int idx = intel_engine_sync_index(from->engine, to->engine);
-   u32 seqno = i915_gem_request_get_seqno(from);
-
-   if (seqno <= from->engine->semaphore.sync_seqno[idx])
+   if (from->fence.seqno <= 
from->engine->semaphore.sync_seqno[idx])
return 0;
 
trace_i915_gem_ring_sync_to(to, from);
-   ret = to->engine->semaphore.sync_to(to, from->engine, seqno);
+   ret = to->engine->semaphore.sync_to(to, from);
if (ret)
return ret;
 
-   /* We use last_read_req because sync_to()
-* might have just caused seqno wrap under
-* the radar.
-*/
-   from->engine->semaphore.sync_seqno[idx] =
-   
i915_gem_request_get_seqno(obj->last_read_req[from->engine->id]);
+   from->engine->semaphore.sync_seqno[idx] = from->fence.seqno;
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index e378eb61979b..11c19e7f82fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -264,14 +264,7 @@ int i915_gem_set_seqno(struct drm_device *dev, u32 seqno)
if (ret)
return ret;
 
-   /* Carefully set the last_seqno value so that wrap
-* detection still works
-*/
dev_priv->next_seqno = seqno;
-   dev_priv->last_seqno = seqno - 1;
-   if (dev_priv->last_seqno == 0)
-   dev_priv->last_seqno--;
-
return 0;
 }
 
@@ -288,7 +281,7 @@ static int i915_gem_get_seqno(struct drm_i915_private 
*dev_priv, u32 *seqno)
dev_priv->next_seqno = 1;
}
 
-   *seqno = dev_priv->last_seqno = dev_priv->next_seqno++;
+   *seqno = dev_priv->next_seqno++;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 0b6f12c36e58..51f3123b500c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1496,12 +1496,6 @@ static int gen8_render_emit_request(struct 
drm_i915_gem_request *req)
return 0;
 }
 
-static inline bool i915_gem_has_seqno_wrapped(struct drm_i915_private 
*dev_priv,
- u32 seqno)
-{
-   return dev_priv->last_seqno < seqno;
-}
-
 /**
  * intel_ring_sync - sync the waiter to the signaller on seqno
  *
@@ -1511,24 +1505,23 @@ static inline bool i915_gem_has_seqno_wrapped(struct 
drm_i915_private *dev_priv,
  */
 
 static int
-gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
-  struct intel_engine_cs *signaller,
-  u32 seqno)
+gen8_ring_sync(struct drm_i915_gem_request *wait,
+  struct drm_i915_gem_request *signal)
 {
-   struct intel_ring *waiter = waiter_req->ring;
-   struct drm_i915_private *dev_priv = waiter_req->i915;
-   u64 offset = GEN8_WAIT_OFFSET(waiter_req->engine, signaller->id);
+   struct intel_ring *waiter = wait->ring;
+   struct drm_i915_private *dev_priv = wait->i915;
+   u64 offset = GEN8_WAIT_OFFSET(wait->engine, signal->engine->id);
struct i915_hw_ppg