Re: [Intel-gfx] [PATCH v3] drm/i915: Use exponential backoff for wait_for()

[Sagar Arun Kamble]

On 11/30/2017 12:45 PM, John Harrison wrote:

On 11/29/2017 10:19 PM, Sagar Arun Kamble wrote:

On 11/30/2017 8:34 AM, John Harrison wrote:

On 11/24/2017 6:12 AM, Chris Wilson wrote:

Quoting Michał Winiarski (2017-11-24 12:37:56)

Since we see the effects for GuC preeption, let's gather some evidence.

(SKL)
intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption'

drm-tip:
  usecs   : count distribution
  0 -> 1  : 0||
  2 -> 3  : 0||
  4 -> 7  : 0||
  8 -> 15 : 44   ||
 16 -> 31 : 1088 ||
 32 -> 63 : 832  ||
 64 -> 127: 0||
128 -> 255: 0||
256 -> 511: 12   ||
512 -> 1023   : 0||
   1024 -> 2047   : 29899|*   |
   2048 -> 4095   : 131033   ||

Such pretty graphs. Reminds me of the bpf hist output, I wonder if we
could create a tracepoint/kprobe that would output a histogram for each
waiter (filterable ofc). Benefit? Just thinking of tuning the
spin/sleep, in which case overall metrics are best
(intel_eait_for_register needs to be optimised for the typical case). I
am wondering if we could tune the spin period down to 5us, 2us? And then
have the 10us sleep.

We would also need a typical workload to run, it's profile-guided
optimisation after all. Hmm.
-Chris


It took me a while to get back to this but I've now had chance to 
run with this exponential backoff scheme on the original system that 
showed the problem. It was a slightly messy back port due to the 
customer tree being much older than current nightly. I'm pretty sure 
I got it correct though. However, I'm not sure what the 
recommendation is for the two timeout values. Using the default of 
'10, 10' in the patch, I still get lots of very long delays. 
Recommended setting currently is Wmin=10, Wmax=10 for wait_for_us and 
Wmin=10, Wmax=1000 for wait_for.


Exponential backoff is more helpful inside wait_for if wait_for_us 
prior to wait_for is smaller.
Setting Wmax less than Wmin is effectively changing the backoff 
strategy to just linear waits of Wmin.
I have to up the Wmin value to at least 140 to get a stall free 
result. Which is plausible given that the big spike in the results 
of any fast version is at 110-150us. Also of note is that a Wmin 
between 10 and 110 actually makes things worse. Changing Wmax has no 
effect.


In the following table, 'original' is the original driver before any 
changes and 'retry loop' is the version using the first workaround 
of just running the busy poll wait in a 10x loop. The other columns 
are using the backoff patch with the given Wmin/Wmax values. Note 
that the times are bucketed to 10us up to 500us and then in 500us 
lumps thereafter. The value listed is the lower limit, i.e. there 
were no times of <10us measured. Each case was run for 1000 samples.


Below setting like in current nightly will suit this workload and as 
you have found this will also likely complete most waits in <150us.
If many samples had been beyond 160us and less than 300us we might 
have been needed to change Wmin to may be 15 or 20 to ensure the

exponential rise caps around 300us.

wait_for_us(10, 10)
wait_for()

#define wait_for _wait_for(10, 1000)

But as shown in the table, a setting of 10/10 does not work well for 
this workload. The best results possible are a large spike of waits in 
the 120-130us bucket with a small tail out to 150us. Whereas, the 
10/10 setting produces a spike from 150-170us with the tail extending 
to 240us and an appreciable number of samples stretching all the way 
out to the 1-10ms range. A regular delay of multiple milliseconds is 
not acceptable when this path is supposed to be a low latency 
pre-emption to switch to some super high priority time critical task. 
And as noted, I did try a bunch of different settings for Wmax but 
nothing seemed to make much of a difference. E.g. 10/10 vs 10/1000 
produced pretty much identical results. Hence it didn't seem worth 
including those in the table.


Wmin = 10us leads us to total delay of 150us in 3 loops (this might be 
tight to catch most conditions)

Wmin = 25us can lead us to total delay of 175us in 3 loops

Since most conditions are likely to complete around 140us-160us, Looks 
like Wmin of 25 to 30 (25,1000 or 30, 1000) will suit this workload but
since this profile driver optimization I am 

Re: [Intel-gfx] [RFC PATCH 0/6] drm/i915: Implement HDCP

[Daniel Vetter]

On Wed, Nov 29, 2017 at 10:08:55PM -0500, Sean Paul wrote:
> Here's the RFC for my i915 HDCP patchset. The UABI is based on what we've been
> using in Chrome for the past 3 years. I posted the property to the list back
> then, but never had a mainline driver to implement it. I do now :-)
> 
> Things are mostly in place, danvet gave me some feedback that I will
> incorporate in v1. However, in the interest of gaining more early feedback, 
> I'm
> posting this now.
> 
> TODO:
> - Add kerneldoc for property

The big thing I'd like to see here is clear description of the flows
between kernel and userspace (since there's no helpers on the kernel side
to standardize this).

One thing we discussed in that context is the addition of an uevent (like
we do for anything else that changes with connectors, link_status is one
example). But since the hdcp spec explicitly demands that the video player
must poll the status an event is moot and won't be used. And I'm no fan of
speculative uapi :-)

> - Fix '//' comments
> - Change to MIT license
> - Rebase on Ville's gmbus fixes (thanks Ville)
> - Improve documentation on drm_intel_hdcp_shim
> - Fix async commit locking (ie: don't use connection_mutex)
> - Don't change connector->state in enable, defer to worker

Same holds for the disable callback, you can't touch state in there.

With the link_status prop (which is somewhat similar) we only reset it in
atomic_check (where we hold the state locks) and in the async worker (same
applies).
-Daniel

> - Add igt coverage for the feature.
> 
> Thanks!
> 
> Sean
> 
> 
> Sean Paul (6):
>   drm: Add Content Protection property
>   drm: Add some HDCP related #defines
>   drm/i915: Add HDCP framework + base implementation
>   drm/i915: Add function to output Aksv over GMBUS
>   drm/i915: Implement HDCP for HDMI
>   drm/i915: Implement HDCP for DisplayPort
> 
>  drivers/gpu/drm/drm_atomic.c|   8 +
>  drivers/gpu/drm/drm_connector.c |  43 +++
>  drivers/gpu/drm/drm_sysfs.c |  29 ++
>  drivers/gpu/drm/i915/Makefile   |   1 +
>  drivers/gpu/drm/i915/i915_drv.h |   1 +
>  drivers/gpu/drm/i915/i915_reg.h |  85 +
>  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>  drivers/gpu/drm/i915/intel_ddi.c|  64 
>  drivers/gpu/drm/i915/intel_dp.c | 243 +-
>  drivers/gpu/drm/i915/intel_drv.h|  53 +++
>  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
> 
>  drivers/gpu/drm/i915/intel_hdmi.c   | 253 ++
>  drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
>  include/drm/drm_connector.h |  16 +
>  include/drm/drm_dp_helper.h |  17 +
>  include/drm/drm_hdcp.h  |  44 +++
>  include/uapi/drm/drm_mode.h |   4 +
>  17 files changed, 1560 insertions(+), 17 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>  create mode 100644 include/drm/drm_hdcp.h
> 
> -- 
> 2.15.0.531.g2ccb3012c9-goog
> 
> ___
> 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 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Peter Zijlstra]

On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote:
> cross-release ftl
> 
> From Chris:
> 
> "Fwiw, this isn't cross-release but us reloading the module many times,
> creating a whole host of new lockclasses. Even more fun is when the
> module gets a slightly different address and the new lock address hashes
> into an old lock...

Yeah, this is a known issue, just reboot.

> "I did think about a module-hook to revoke the stale lockclasses, but
> that still leaves all the hashed chains.

Its an absolute royal pain to remove all the resources consumed by a
module, and if you manage you then have to deal with fragmented storage
-- that is, we need to go keep track of which entries are used.

Its a giant heap of complexity that's just not worth it.


Given all that, I don't see why we should up this. Just don't reload
modules (or better, don't use modules at all).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2017-11-30:
drm-misc-fixes for -rc2

- big pile of bridge driver (mostly tc358767), all handled by Archit
  and Andrez
- rockchip dsi fix
- atomic helper regression fix for spurious -EBUSY (Maarten)
- fix deferred fbdev fallout (Maarten)

Also backmerged -rc1 because I couldn't just roll forward and to cope
better with the dc branch hydra situation :-)

Cheers, Daniel

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-11-30

for you to fetch changes up to 4dbd6c03fbf88299c573d676838896c6e06aade2:

  drm/bridge: tc358767: fix 1-lane behavior (2017-11-30 07:56:18 +0100)


drm-misc-fixes for -rc2

- big pile of bridge driver (mostly tc358767), all handled by Archit
  and Andrez
- rockchip dsi fix
- atomic helper regression fix for spurious -EBUSY (Maarten)
- fix deferred fbdev fallout (Maarten)


Andrey Gusakov (6):
  drm/bridge: tc358767: do no fail on hi-res displays
  drm/bridge: tc358767: filter out too high modes
  drm/bridge: tc358767: fix DP0_MISC register set
  drm/bridge: tc358767: fix timing calculations
  drm/bridge: tc358767: fix AUXDATAn registers access
  drm/bridge: tc358767: fix 1-lane behavior

Daniel Vetter (1):
  Merge tag 'v4.15-rc1' into drm-misc-fixes

Eric Anholt (1):
  drm/bridge: Fix lvds-encoder since the panel_bridge rework.

Hans Verkuil (1):
  drm/bridge: adv7511/33: Fix adv7511_cec_init() failure handling

Lucas Stach (1):
  drm/atomic: make drm_atomic_helper_wait_for_vblanks more agressive

Maarten Lankhorst (1):
  drm/fb_helper: Disable all crtc's when initial setup fails.

Mirza Krak (1):
  drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable

Pierre-Hugues Husson (1):
  drm/bridge: synopsys/dw-hdmi: Enable cec clock

 drivers/gpu/drm/bridge/adv7511/adv7511.h | 13 -
 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 32 
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 ++-
 drivers/gpu/drm/bridge/lvds-encoder.c| 48 +++---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 25 ++
 drivers/gpu/drm/bridge/tc358767.c| 73 +++-
 drivers/gpu/drm/drm_atomic_helper.c  |  2 +-
 drivers/gpu/drm/drm_edid.c   | 12 -
 drivers/gpu/drm/drm_fb_helper.c  |  4 ++
 drivers/gpu/drm/i915/intel_hdmi.c|  3 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c   |  3 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c   |  3 +-
 drivers/gpu/drm/vc4/vc4_irq.c|  6 +++
 include/drm/drm_edid.h   |  3 +-
 14 files changed, 171 insertions(+), 73 deletions(-)

-- 
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 v3] drm/i915: Use exponential backoff for wait_for()

[John Harrison]

On 11/29/2017 10:19 PM, Sagar Arun Kamble wrote:

On 11/30/2017 8:34 AM, John Harrison wrote:

On 11/24/2017 6:12 AM, Chris Wilson wrote:

Quoting Michał Winiarski (2017-11-24 12:37:56)

Since we see the effects for GuC preeption, let's gather some evidence.

(SKL)
intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption'

drm-tip:
  usecs   : count distribution
  0 -> 1  : 0||
  2 -> 3  : 0||
  4 -> 7  : 0||
  8 -> 15 : 44   ||
 16 -> 31 : 1088 ||
 32 -> 63 : 832  ||
 64 -> 127: 0||
128 -> 255: 0||
256 -> 511: 12   ||
512 -> 1023   : 0||
   1024 -> 2047   : 29899|*   |
   2048 -> 4095   : 131033   ||

Such pretty graphs. Reminds me of the bpf hist output, I wonder if we
could create a tracepoint/kprobe that would output a histogram for each
waiter (filterable ofc). Benefit? Just thinking of tuning the
spin/sleep, in which case overall metrics are best
(intel_eait_for_register needs to be optimised for the typical case). I
am wondering if we could tune the spin period down to 5us, 2us? And then
have the 10us sleep.

We would also need a typical workload to run, it's profile-guided
optimisation after all. Hmm.
-Chris


It took me a while to get back to this but I've now had chance to run 
with this exponential backoff scheme on the original system that 
showed the problem. It was a slightly messy back port due to the 
customer tree being much older than current nightly. I'm pretty sure 
I got it correct though. However, I'm not sure what the 
recommendation is for the two timeout values. Using the default of 
'10, 10' in the patch, I still get lots of very long delays. 
Recommended setting currently is Wmin=10, Wmax=10 for wait_for_us and 
Wmin=10, Wmax=1000 for wait_for.


Exponential backoff is more helpful inside wait_for if wait_for_us 
prior to wait_for is smaller.
Setting Wmax less than Wmin is effectively changing the backoff 
strategy to just linear waits of Wmin.
I have to up the Wmin value to at least 140 to get a stall free 
result. Which is plausible given that the big spike in the results of 
any fast version is at 110-150us. Also of note is that a Wmin between 
10 and 110 actually makes things worse. Changing Wmax has no effect.


In the following table, 'original' is the original driver before any 
changes and 'retry loop' is the version using the first workaround of 
just running the busy poll wait in a 10x loop. The other columns are 
using the backoff patch with the given Wmin/Wmax values. Note that 
the times are bucketed to 10us up to 500us and then in 500us lumps 
thereafter. The value listed is the lower limit, i.e. there were no 
times of <10us measured. Each case was run for 1000 samples.


Below setting like in current nightly will suit this workload and as 
you have found this will also likely complete most waits in <150us.
If many samples had been beyond 160us and less than 300us we might 
have been needed to change Wmin to may be 15 or 20 to ensure the

exponential rise caps around 300us.

wait_for_us(10, 10)
wait_for()

#define wait_for _wait_for(10, 1000)

But as shown in the table, a setting of 10/10 does not work well for 
this workload. The best results possible are a large spike of waits in 
the 120-130us bucket with a small tail out to 150us. Whereas, the 10/10 
setting produces a spike from 150-170us with the tail extending to 240us 
and an appreciable number of samples stretching all the way out to the 
1-10ms range. A regular delay of multiple milliseconds is not acceptable 
when this path is supposed to be a low latency pre-emption to switch to 
some super high priority time critical task. And as noted, I did try a 
bunch of different settings for Wmax but nothing seemed to make much of 
a difference. E.g. 10/10 vs 10/1000 produced pretty much identical 
results. Hence it didn't seem worth including those in the table.



    Time    Original    10/10 50/10    100/10    110/10    
130/10    140/10  RetryLoop
    10us:  2 2 2 2 2 
2 2 2

    30us:  1 1 1 1 1
    50us:  1
    70us: 14    63 56    
64    63    61
    80us:  

Re: [Intel-gfx] [PATCH v3] drm/i915: Use exponential backoff for wait_for()

[Sagar Arun Kamble]

On 11/30/2017 8:34 AM, John Harrison wrote:

On 11/24/2017 6:12 AM, Chris Wilson wrote:

Quoting Michał Winiarski (2017-11-24 12:37:56)

Since we see the effects for GuC preeption, let's gather some evidence.

(SKL)
intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption'

drm-tip:
  usecs   : count distribution
  0 -> 1  : 0||
  2 -> 3  : 0||
  4 -> 7  : 0||
  8 -> 15 : 44   ||
 16 -> 31 : 1088 ||
 32 -> 63 : 832  ||
 64 -> 127: 0||
128 -> 255: 0||
256 -> 511: 12   ||
512 -> 1023   : 0||
   1024 -> 2047   : 29899|*   |
   2048 -> 4095   : 131033   ||

Such pretty graphs. Reminds me of the bpf hist output, I wonder if we
could create a tracepoint/kprobe that would output a histogram for each
waiter (filterable ofc). Benefit? Just thinking of tuning the
spin/sleep, in which case overall metrics are best
(intel_eait_for_register needs to be optimised for the typical case). I
am wondering if we could tune the spin period down to 5us, 2us? And then
have the 10us sleep.

We would also need a typical workload to run, it's profile-guided
optimisation after all. Hmm.
-Chris


It took me a while to get back to this but I've now had chance to run 
with this exponential backoff scheme on the original system that 
showed the problem. It was a slightly messy back port due to the 
customer tree being much older than current nightly. I'm pretty sure I 
got it correct though. However, I'm not sure what the recommendation 
is for the two timeout values. Using the default of '10, 10' in the 
patch, I still get lots of very long delays. 
Recommended setting currently is Wmin=10, Wmax=10 for wait_for_us and 
Wmin=10, Wmax=1000 for wait_for.


Exponential backoff is more helpful inside wait_for if wait_for_us prior 
to wait_for is smaller.
Setting Wmax less than Wmin is effectively changing the backoff strategy 
to just linear waits of Wmin.
I have to up the Wmin value to at least 140 to get a stall free 
result. Which is plausible given that the big spike in the results of 
any fast version is at 110-150us. Also of note is that a Wmin between 
10 and 110 actually makes things worse. Changing Wmax has no effect.


In the following table, 'original' is the original driver before any 
changes and 'retry loop' is the version using the first workaround of 
just running the busy poll wait in a 10x loop. The other columns are 
using the backoff patch with the given Wmin/Wmax values. Note that the 
times are bucketed to 10us up to 500us and then in 500us lumps 
thereafter. The value listed is the lower limit, i.e. there were no 
times of <10us measured. Each case was run for 1000 samples.


Below setting like in current nightly will suit this workload and as you 
have found this will also likely complete most waits in <150us.
If many samples had been beyond 160us and less than 300us we might have 
been needed to change Wmin to may be 15 or 20 to ensure the

exponential rise caps around 300us.

wait_for_us(10, 10)
wait_for()

#define wait_for _wait_for(10, 1000)

    Time    Original    10/10 50/10 100/10    110/10    
130/10    140/10  RetryLoop
    10us:  2 2 2 2 2 2 
2 2

    30us:  1 1 1 1 1
    50us:  1
    70us: 14    63 56    64    
63    61
    80us:  8    41 52    44    
46    41
    90us:  6    24 10    28    
12    17
   100us:    2 4    20 16    17    
17    22
   110us:   13 21    14    
13    11
   120us:  6   366 633   636   
660   650
   130us:    2 2    46 125    
95    86    95
   140us:    3 2    16 18    32    
46    48
   150us:  210 3    12 13    37    
32    31
   160us:  322 1    18 10    14    
12    17
   170us:  157 4 5 5 3 
5 2
   180us:

[Intel-gfx] [RFC PATCH 6/6] drm/i915: Implement HDCP for DisplayPort

[Sean Paul]

This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.

Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the rest
of it.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_dp.c | 243 ++--
 1 file changed, 236 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d11281004109..091c8bcc4645 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -36,7 +36,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -1039,10 +1041,29 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
*intel_dp,
   DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
 }
 
+static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
+ bool has_aux_irq,
+ int send_bytes,
+ uint32_t aux_clock_divider,
+ bool aksv_write)
+{
+   uint32_t val = 0;
+
+   if (aksv_write) {
+   send_bytes += 5;
+   val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+   }
+
+   return val | intel_dp->get_aux_send_ctl(intel_dp,
+   has_aux_irq,
+   send_bytes,
+   aux_clock_divider);
+}
+
 static int
 intel_dp_aux_ch(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
-   uint8_t *recv, int recv_size)
+   uint8_t *recv, int recv_size, bool aksv_write)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv =
@@ -1102,10 +1123,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
}
 
while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
clock++))) {
-   u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
- has_aux_irq,
- send_bytes,
- aux_clock_divider);
+   u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
+has_aux_irq,
+send_bytes,
+aux_clock_divider,
+aksv_write);
 
/* Must try at least 3 times according to DP spec */
for (try = 0; try < 5; try++) {
@@ -1242,7 +1264,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (msg->buffer)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
 
@@ -1264,7 +1287,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (WARN_ON(rxsize > 20))
return -E2BIG;
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -4310,6 +4334,8 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
intel_dp_retrain_link(intel_dp);
}
+
+   intel_hdcp_check_link(intel_dp->attached_connector);
 }
 
 /*
@@ -4977,6 +5003,203 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
 }
 
+static
+int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
+   u8 *an)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
+   uint8_t txbuf[4], rxbuf[2], reply = 0;
+   ssize_t dpcd_ret;
+   int ret;
+
+   /* Output An first, that's easy */
+   dpcd_ret = drm_dp_dpcd_write(_dig_port->dp.aux, DP_AUX_HDCP_AN,
+an, DRM_HDCP_AN_LEN);
+   if (dpcd_ret != DRM_HDCP_AN_LEN) {
+   DRM_ERROR("Failed to write An over DP/AUX (%ld)\n", dpcd_ret);
+   return dpcd_ret >= 0 ? -EIO : dpcd_ret;
+   }
+
+   /*
+* Since Aksv is 

[Intel-gfx] [RFC PATCH 4/6] drm/i915: Add function to output Aksv over GMBUS

[Sean Paul]

Once the Aksv is available in the PCH, we need to get it on the wire to
the receiver via DDC. The hardware doesn't allow us to read the value
directly, so we need to tell GMBUS to source the Aksv internally and
send it to the right offset on the receiver.

The way we do this is to initiate an indexed write where the index is
the Aksv register offset. We write dummy values to GMBUS3 as if we were
sending the key, and the hardware slips in the "real" values when it
goes out.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_i2c.c | 54 ++--
 3 files changed, 48 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54b5d4c582b6..30fcd856ec23 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4024,6 +4024,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
*dev_priv);
 extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
 extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
 unsigned int pin);
+extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
 
 extern struct i2c_adapter *
 intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 43128030171d..78370877fea3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3009,6 +3009,7 @@ enum i915_power_well_id {
 # define GPIO_DATA_PULLUP_DISABLE  (1 << 13)
 
 #define GMBUS0 _MMIO(dev_priv->gpio_mmio_base + 0x5100) /* 
clock/port select */
+#define   GMBUS_AKSV_SELECT(1<<11)
 #define   GMBUS_RATE_100KHZ(0<<8)
 #define   GMBUS_RATE_50KHZ (1<<8)
 #define   GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index eb5827110d8f..c01156bf0f27 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -373,7 +374,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg,
 
 static int
 gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
-  unsigned short addr, u8 *buf, unsigned int len)
+  unsigned short addr, u8 *buf, unsigned int len,
+  u32 gmbus1_index)
 {
unsigned int chunk_size = len;
u32 val, loop;
@@ -386,7 +388,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 
I915_WRITE_FW(GMBUS3, val);
I915_WRITE_FW(GMBUS1,
- GMBUS_CYCLE_WAIT |
+ gmbus1_index | GMBUS_CYCLE_WAIT |
  (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
  (addr << GMBUS_SLAVE_ADDR_SHIFT) |
  GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
@@ -409,7 +411,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 }
 
 static int
-gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
+gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
+u32 gmbus1_index)
 {
u8 *buf = msg->buf;
unsigned int tx_size = msg->len;
@@ -419,7 +422,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg)
do {
len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
 
-   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
+   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
+gmbus1_index);
if (ret)
return ret;
 
@@ -470,7 +474,8 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
struct i2c_msg *msgs)
 }
 
 static int
-do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
+do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
+ u32 gmbus0_source, u32 gmbus1_index)
 {
struct intel_gmbus *bus = container_of(adapter,
   struct intel_gmbus,
@@ -480,7 +485,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
int ret = 0;
 
 retry:
-   I915_WRITE_FW(GMBUS0, bus->reg0);
+   I915_WRITE_FW(GMBUS0, gmbus0_source | bus->reg0);
 
for (; i < num; i += inc) {
inc = 1;
@@ -490,7 +495,8 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
} else if (msgs[i].flags & I2C_M_RD) {
ret = gmbus_xfer_read(dev_priv, [i], 0);
} else {
-   ret = gmbus_xfer_write(dev_priv, [i]);
+   ret = 

[Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_reg.h |  83 +
 drivers/gpu/drm/i915/intel_atomic.c |  26 +-
 drivers/gpu/drm/i915/intel_ddi.c|  14 +
 drivers/gpu/drm/i915/intel_drv.h|  53 +++
 drivers/gpu/drm/i915/intel_hdcp.c   | 636 
 6 files changed, 811 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6c3b0481ef82..1e745508e437 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,6 +87,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..43128030171d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7991,6 +7991,7 @@ enum {
 #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT   8
 #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT   16
 #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT   24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
 #define   SKL_PCODE_CDCLK_CONTROL  0x7
 #define SKL_CDCLK_PREPARE_FOR_CHANGE   0x3
 #define SKL_CDCLK_READY_FOR_CHANGE 0x1
@@ -8285,6 +8286,88 @@ enum skl_power_gate {
 #define  SKL_PW_TO_PG(pw)  ((pw) - SKL_DISP_PW_1 + SKL_PG1)
 #define  SKL_FUSE_PG_DIST_STATUS(pg)   (1 << (27 - (pg)))
 
+
+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
+#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define SKL_HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
+#define SKL_HDCP_SHA_TEXT  _MMIO(0x66d18)
+
+/* HDCP Auth Registers */
+#define _SKL_PORTA_HDCP_AUTHENC0x66800
+#define _SKL_PORTB_HDCP_AUTHENC0x66500
+#define _SKL_PORTC_HDCP_AUTHENC0x66600
+#define _SKL_PORTD_HDCP_AUTHENC0x66700
+#define _SKL_PORTE_HDCP_AUTHENC0x66A00
+#define _SKL_PORTF_HDCP_AUTHENC0x66900
+#define _SKL_PORT_HDCP_AUTHENC(port, x)_MMIO(_PICK(port, \
+ _SKL_PORTA_HDCP_AUTHENC, \
+ _SKL_PORTB_HDCP_AUTHENC, \
+ _SKL_PORTC_HDCP_AUTHENC, \
+ _SKL_PORTD_HDCP_AUTHENC, \
+ _SKL_PORTE_HDCP_AUTHENC, \
+

[Intel-gfx] [RFC PATCH 5/6] drm/i915: Implement HDCP for HDMI

[Sean Paul]

This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.

Nothing too special, just a bunch of DDC reads/writes.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 drivers/gpu/drm/i915/intel_ddi.c  |  50 
 drivers/gpu/drm/i915/intel_hdmi.c | 253 ++
 3 files changed, 304 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 78370877fea3..061c52a5d7d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8400,6 +8400,7 @@ enum skl_power_gate {
 #define  TRANS_DDI_EDP_INPUT_A_ONOFF   (4<<12)
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
+#define  TRANS_DDI_HDCP_SIGNALLING (1<<9)
 #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
 #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
 #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0e69337f410d..0324b09ecf76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1650,6 +1650,56 @@ void intel_ddi_disable_transcoder_func(struct 
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
 }
 
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
 {
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 59247a49a077..563168897dd9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "intel_drv.h"
 #include 
@@ -875,6 +876,252 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
 adapter, enable);
 }
 
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,
+   unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   intel_dig_port->base.base.dev->dev_private;
+   struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+   int ret;
+   u8 start = offset & 0xff;
+   struct i2c_msg msgs[] = {
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = 1,
+   .buf = ,
+   },
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = I2C_M_RD,
+   .len = size,
+   .buf = buffer
+   }
+   };
+   ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
+   if (ret == ARRAY_SIZE(msgs))
+   return 0;
+   return ret >= 0 ? -EIO : ret;
+}
+
+static int intel_hdmi_hdcp_write(struct intel_digital_port *intel_dig_port,
+unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   

[Intel-gfx] [RFC PATCH 2/6] drm: Add some HDCP related #defines

[Sean Paul]

In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.

Signed-off-by: Sean Paul 
---
 include/drm/drm_dp_helper.h | 17 +
 include/drm/drm_hdcp.h  | 44 
 2 files changed, 61 insertions(+)
 create mode 100644 include/drm/drm_hdcp.h

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9049ef133d69..4671d41a2fe1 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -816,6 +816,23 @@
 #define DP_CEC_TX_MESSAGE_BUFFER   0x3020
 #define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
 
+#define DP_AUX_HDCP_BKSV   0x68000
+#define DP_AUX_HDCP_RI_PRIME   0x68005
+#define DP_AUX_HDCP_AKSV   0x68007
+#define DP_AUX_HDCP_AN 0x6800C
+#define DP_AUX_HDCP_V_PRIME(h) (0x68014 + h * 4)
+#define DP_AUX_HDCP_BCAPS  0x68028
+# define DP_BCAPS_REPEATER_PRESENT BIT(1)
+# define DP_BCAPS_HDCP_CAPABLE BIT(0)
+#define DP_AUX_HDCP_BSTATUS0x68029
+# define DP_BSTATUS_REAUTH_REQ BIT(3)
+# define DP_BSTATUS_LINK_FAILURE   BIT(2)
+# define DP_BSTATUS_R0_PRIME_READY BIT(1)
+# define DP_BSTATUS_READY  BIT(0)
+#define DP_AUX_HDCP_BINFO  0x6802A
+#define DP_AUX_HDCP_KSV_FIFO   0x6802C
+#define DP_AUX_HDCP_AINFO  0x6803B
+
 /* DP 1.2 Sideband message defines */
 /* peer device type - DP 1.2a Table 2-92 */
 #define DP_PEER_DEVICE_NONE0x0
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
new file mode 100644
index ..d9b0947b6f09
--- /dev/null
+++ b/include/drm/drm_hdcp.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DRM_HDCP_H_INCLUDED_
+#define _DRM_HDCP_H_INCLUDED_
+
+/* Period of hdcp checks (to ensure we're still authenticated) */
+#define DRM_HDCP_CHECK_PERIOD_MS   (128 * 16)
+
+/* Shared lengths/masks between HDMI/DVI/DisplayPort */
+#define DRM_HDCP_AN_LEN8
+#define DRM_HDCP_BSTATUS_LEN   2
+#define DRM_HDCP_KSV_LEN   5
+#define DRM_HDCP_RI_LEN2
+#define DRM_HDCP_V_PRIME_PART_LEN  4
+#define DRM_HDCP_V_PRIME_NUM_PARTS 5
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+
+/* Slave address for the HDCP registers in the receiver */
+#define DRM_HDCP_DDC_ADDR  0x3A
+
+/* HDCP register offsets for HDMI/DVI devices */
+#define DRM_HDCP_DDC_BKSV  0x00
+#define DRM_HDCP_DDC_RI_PRIME  0x08
+#define DRM_HDCP_DDC_AKSV  0x10
+#define DRM_HDCP_DDC_AN0x18
+#define DRM_HDCP_DDC_V_PRIME(h)(0x20 + h * 4)
+#define DRM_HDCP_DDC_BCAPS 0x40
+#define  DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT   BIT(6)
+#define  DRM_HDCP_DDC_BCAPS_KSV_FIFO_READY BIT(5)
+#define DRM_HDCP_DDC_BSTATUS   0x41
+#define DRM_HDCP_DDC_KSV_FIFO  0x43
+
+#endif
-- 
2.15.0.531.g2ccb3012c9-goog

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

[Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

[Sean Paul]

This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.

The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value

The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.

If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.

Signed-off-by: Sean Paul 

[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
---
 drivers/gpu/drm/drm_atomic.c|  8 
 drivers/gpu/drm/drm_connector.c | 43 +
 drivers/gpu/drm/drm_sysfs.c | 29 +++
 include/drm/drm_connector.h | 16 +++
 include/uapi/drm/drm_mode.h |  4 
 5 files changed, 100 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 37445d50816a..2212793eefa6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1185,6 +1185,12 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == connector->content_protection_property) {
+   if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
+   return -EINVAL;
+   }
+   state->content_protection = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1264,6 +1270,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+   } else if (property == connector->content_protection_property) {
+   *val = state->content_protection;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..de2345a4a125 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
+{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
 /**
  * DOC: standard connector properties
  *
@@ -1046,6 +1053,42 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
 
+/**
+ * drm_connector_attach_content_protection_property - attach content protection
+ * property
+ *
+ * @connector: connector to attach CP property on.
+ *
+ * This is used to add support for content protection on select connectors.
+ * Content Protection is intentionally vague to allow for different underlying
+ * technologies, however it is most implemented by HDCP.
+ *
+ * The content protection will be set to 
_connector_state.content_protection
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_content_protection_property(
+   struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   prop = drm_property_create_enum(dev, 0, "Content Protection",
+   drm_cp_enum_list,
+   ARRAY_SIZE(drm_cp_enum_list));
+   if (!prop)
+   return -ENOMEM;
+
+   drm_object_attach_property(>base, prop,
+  DRM_MODE_CONTENT_PROTECTION_OFF);
+
+   connector->content_protection_property = prop;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
+
 /**
  * drm_mode_create_aspect_ratio_property - create aspect ratio property
  * @dev: DRM device
diff --git 

[Intel-gfx] [RFC PATCH 0/6] drm/i915: Implement HDCP

[Sean Paul]

Here's the RFC for my i915 HDCP patchset. The UABI is based on what we've been
using in Chrome for the past 3 years. I posted the property to the list back
then, but never had a mainline driver to implement it. I do now :-)

Things are mostly in place, danvet gave me some feedback that I will
incorporate in v1. However, in the interest of gaining more early feedback, I'm
posting this now.

TODO:
- Add kerneldoc for property
- Fix '//' comments
- Change to MIT license
- Rebase on Ville's gmbus fixes (thanks Ville)
- Improve documentation on drm_intel_hdcp_shim
- Fix async commit locking (ie: don't use connection_mutex)
- Don't change connector->state in enable, defer to worker
- Add igt coverage for the feature.

Thanks!

Sean


Sean Paul (6):
  drm: Add Content Protection property
  drm: Add some HDCP related #defines
  drm/i915: Add HDCP framework + base implementation
  drm/i915: Add function to output Aksv over GMBUS
  drm/i915: Implement HDCP for HDMI
  drm/i915: Implement HDCP for DisplayPort

 drivers/gpu/drm/drm_atomic.c|   8 +
 drivers/gpu/drm/drm_connector.c |  43 +++
 drivers/gpu/drm/drm_sysfs.c |  29 ++
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.h |   1 +
 drivers/gpu/drm/i915/i915_reg.h |  85 +
 drivers/gpu/drm/i915/intel_atomic.c |  26 +-
 drivers/gpu/drm/i915/intel_ddi.c|  64 
 drivers/gpu/drm/i915/intel_dp.c | 243 +-
 drivers/gpu/drm/i915/intel_drv.h|  53 +++
 drivers/gpu/drm/i915/intel_hdcp.c   | 636 
 drivers/gpu/drm/i915/intel_hdmi.c   | 253 ++
 drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
 include/drm/drm_connector.h |  16 +
 include/drm/drm_dp_helper.h |  17 +
 include/drm/drm_hdcp.h  |  44 +++
 include/uapi/drm/drm_mode.h |   4 +
 17 files changed, 1560 insertions(+), 17 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
 create mode 100644 include/drm/drm_hdcp.h

-- 
2.15.0.531.g2ccb3012c9-goog

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

Re: [Intel-gfx] [PATCH v3] drm/i915: Use exponential backoff for wait_for()

[John Harrison]

On 11/24/2017 6:12 AM, Chris Wilson wrote:

Quoting Michał Winiarski (2017-11-24 12:37:56)

Since we see the effects for GuC preeption, let's gather some evidence.

(SKL)
intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption'

drm-tip:
  usecs   : count distribution
  0 -> 1  : 0||
  2 -> 3  : 0||
  4 -> 7  : 0||
  8 -> 15 : 44   ||
 16 -> 31 : 1088 ||
 32 -> 63 : 832  ||
 64 -> 127: 0||
128 -> 255: 0||
256 -> 511: 12   ||
512 -> 1023   : 0||
   1024 -> 2047   : 29899|*   |
   2048 -> 4095   : 131033   ||

Such pretty graphs. Reminds me of the bpf hist output, I wonder if we
could create a tracepoint/kprobe that would output a histogram for each
waiter (filterable ofc). Benefit? Just thinking of tuning the
spin/sleep, in which case overall metrics are best
(intel_eait_for_register needs to be optimised for the typical case). I
am wondering if we could tune the spin period down to 5us, 2us? And then
have the 10us sleep.

We would also need a typical workload to run, it's profile-guided
optimisation after all. Hmm.
-Chris


It took me a while to get back to this but I've now had chance to run 
with this exponential backoff scheme on the original system that showed 
the problem. It was a slightly messy back port due to the customer tree 
being much older than current nightly. I'm pretty sure I got it correct 
though. However, I'm not sure what the recommendation is for the two 
timeout values. Using the default of '10, 10' in the patch, I still get 
lots of very long delays. I have to up the Wmin value to at least 140 to 
get a stall free result. Which is plausible given that the big spike in 
the results of any fast version is at 110-150us. Also of note is that a 
Wmin between 10 and 110 actually makes things worse. Changing Wmax has 
no effect.


In the following table, 'original' is the original driver before any 
changes and 'retry loop' is the version using the first workaround of 
just running the busy poll wait in a 10x loop. The other columns are 
using the backoff patch with the given Wmin/Wmax values. Note that the 
times are bucketed to 10us up to 500us and then in 500us lumps 
thereafter. The value listed is the lower limit, i.e. there were no 
times of <10us measured. Each case was run for 1000 samples.


    Time    Original    10/10 50/10    100/10    110/10    
130/10    140/10  RetryLoop
    10us:  2 2 2 2 2 2 
2 2

    30us:  1 1 1 1 1
    50us:  1
    70us: 14    63 56    64    
63    61
    80us:  8    41 52    44    
46    41
    90us:  6    24 10    28    
12    17
   100us:    2 4    20 16    17    
17    22
   110us:   13 21    14    
13    11
   120us:  6   366 633   636   
660   650
   130us:    2 2    46 125    95    
86    95
   140us:    3 2    16 18    32    
46    48
   150us:  210 3    12 13    37    
32    31
   160us:  322 1    18 10    14    
12    17
   170us:  157 4 5 5 3 
5 2
   180us:   62    11 3 1 2 
1 1

   190us:   32   212 1   1 2
   200us:   27   266 1   1
   210us:   16 
181 1

   220us:   16 51   1
   230us:   10    43 4
   240us:   12    22    62 1
   250us:    4    12   112 3
   260us:    3    13    73 8
   270us:    5    12    12 8 2
   280us:    4 7    12 5 1
   290us: 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: follow single notation for workaround number

[Rodrigo Vivi]

On Wed, Nov 29, 2017 at 11:53:16PM +, De Marchi, Lucas wrote:
> On Wed, 2017-11-29 at 15:44 -0800, Rodrigo Vivi wrote:
> > On Tue, Nov 28, 2017 at 09:08:19PM +, Lucas De Marchi wrote:
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Lucas De Marchi 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > >  drivers/gpu/drm/i915/intel_hdmi.c| 2 +-
> > >  drivers/gpu/drm/i915/intel_pm.c  | 2 +-
> > >  3 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 76c75d34e799..9a0ebf205435 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -15126,7 +15126,7 @@ get_encoder_power_domains(struct drm_i915_private
> > > *dev_priv)
> > >  
> > >  static void intel_early_display_was(struct drm_i915_private *dev_priv)
> > >  {
> > > - /* Display WA #1185 WaDisableDARBFClkGating:cnl,glk */
> > > + /* Display WA #1185 WaDisableDARBFClkGating: cnl,glk */
> > 
> > If you introduce the space here I believe this patch will need to get
> > bigger.
> > probably to just leave without it.
> 
> Not from my grep.  The ones that don't have space are the ones that don't have
> numbers either. Of course we could just ignore this and allow to either have
> spaces or not.
> 
> git grep -e "Wa[A-Z]" -- drivers/gpu/drm/i915/
> 

Well, using this I see

$ git grep -e "Wa[A-Z]" -- drivers/gpu/drm/i915/ | wc -l
235

where only
$ git grep -e "Wa[A-Z]" -- drivers/gpu/drm/i915/ | grep ": " | wc -l
9

have space.

So maybe it would be good to convert those 9 to match the most used style,
i.e., no space.

Not that I have a strong preference actually. As far as we have the information
about the platform, WaStrangeNameWhenTheyExist, and Display WA #, I'm 
ok with it,
no matter order or spaces ;)

> vs
> 
> git grep -i -e "WA \#" -- drivers/gpu/drm/i915/
> 
> 
> ... and this last one shows I forgot one case in
> drivers/gpu/drm/i915/intel_pm.c

so, if you insist on this format with space for the displays one I ack the v2 ;)

> 
> 
> Lucas De Marchi
> 
> > 
> > >   if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> > >   I915_WRITE(GEN9_CLKGATE_DIS_0,
> > > I915_READ(GEN9_CLKGATE_DIS_0) |
> > >  DARBF_GATING_DIS);
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 9d5e72728475..691600ce48c4 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct
> > > intel_crtc_state *crtc_state)
> > >   }
> > >   }
> > >  
> > > - /* Display Wa #1139 */
> > > + /* Display WA #1139 */
> > 
> > maybe good to add the affected platforms here as well?
> > 
> > >   if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
> > >   crtc_state->base.adjusted_mode.htotal > 5460)
> > >   return false;
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index a80c322c5b43..7905b8313e40 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -61,7 +61,7 @@ static void gen9_init_clock_gating(struct
> > > drm_i915_private *dev_priv)
> > >   if (HAS_LLC(dev_priv)) {
> > >   /*
> > >* WaCompressedResourceDisplayNewHashMode:skl,kbl
> > > -  * Display WA#0390: skl,kbl
> > > +  * Display WA #0390: skl,kbl
> > >*
> > >* Must match Sampler, Pixel Back End, and Media. See
> > >* WaCompressedResourceSamplerPbeMediaNewHashMode.
> > > -- 
> > > 2.14.3
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: follow single notation for workaround number

[De Marchi, Lucas]

On Wed, 2017-11-29 at 15:44 -0800, Rodrigo Vivi wrote:
> On Tue, Nov 28, 2017 at 09:08:19PM +, Lucas De Marchi wrote:
> > Cc: Ville Syrjälä 
> > Signed-off-by: Lucas De Marchi 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> >  drivers/gpu/drm/i915/intel_hdmi.c| 2 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 76c75d34e799..9a0ebf205435 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15126,7 +15126,7 @@ get_encoder_power_domains(struct drm_i915_private
> > *dev_priv)
> >  
> >  static void intel_early_display_was(struct drm_i915_private *dev_priv)
> >  {
> > -   /* Display WA #1185 WaDisableDARBFClkGating:cnl,glk */
> > +   /* Display WA #1185 WaDisableDARBFClkGating: cnl,glk */
> 
> If you introduce the space here I believe this patch will need to get
> bigger.
> probably to just leave without it.

Not from my grep.  The ones that don't have space are the ones that don't have
numbers either. Of course we could just ignore this and allow to either have
spaces or not.

git grep -e "Wa[A-Z]" -- drivers/gpu/drm/i915/

vs

git grep -i -e "WA \#" -- drivers/gpu/drm/i915/


... and this last one shows I forgot one case in
drivers/gpu/drm/i915/intel_pm.c


Lucas De Marchi

> 
> > if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> > I915_WRITE(GEN9_CLKGATE_DIS_0,
> > I915_READ(GEN9_CLKGATE_DIS_0) |
> >DARBF_GATING_DIS);
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 9d5e72728475..691600ce48c4 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct
> > intel_crtc_state *crtc_state)
> > }
> > }
> >  
> > -   /* Display Wa #1139 */
> > +   /* Display WA #1139 */
> 
> maybe good to add the affected platforms here as well?
> 
> > if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
> > crtc_state->base.adjusted_mode.htotal > 5460)
> > return false;
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index a80c322c5b43..7905b8313e40 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -61,7 +61,7 @@ static void gen9_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> > if (HAS_LLC(dev_priv)) {
> > /*
> >  * WaCompressedResourceDisplayNewHashMode:skl,kbl
> > -* Display WA#0390: skl,kbl
> > +* Display WA #0390: skl,kbl
> >  *
> >  * Must match Sampler, Pixel Back End, and Media. See
> >  * WaCompressedResourceSamplerPbeMediaNewHashMode.
> > -- 
> > 2.14.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too

[Rodrigo Vivi]

On Tue, Nov 28, 2017 at 02:45:05PM +, Valtteri Rantala wrote:
> Testing the texture read performance shows that the same tuning for
> the SQ credits is needed on GLK as on BXT/APL. This has been also
> confirmed by Altug from the HW team.
> 
> V4: Rebase + fix
> Signed-off-by: Valtteri Rantala 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index fede62d..0b04ca7 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1067,6 +1067,15 @@ static int gen9_init_workarounds(struct 
> intel_engine_cs *engine)
>   /* WaDisableSTUnitPowerOptimization:skl,bxt,kbl,glk,cfl */
>   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN2, GEN8_ST_PO_DISABLE);
>  
> + /* WaProgramL3SqcReg1DefaultForPerf:bxt,glk */
> + if (IS_GEN9_LP(dev_priv)) {
> + u32 val = I915_READ(GEN8_L3SQCREG1);
> +
> + val &= ~L3_PRIO_CREDITS_MASK;
> + val |= L3_GENERAL_PRIO_CREDITS(62) | L3_HIGH_PRIO_CREDITS(2);
> + I915_WRITE(GEN8_L3SQCREG1, val);
> + }
> +
>   /* WaOCLCoherentLineFlush:skl,bxt,kbl,cfl */
>   I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
>   GEN8_LQSC_FLUSH_COHERENT_LINES));
> @@ -1184,7 +1193,6 @@ static int skl_init_workarounds(struct intel_engine_cs 
> *engine)
>  static int bxt_init_workarounds(struct intel_engine_cs *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
> - u32 val;
>   int ret;
>  
>   ret = gen9_init_workarounds(engine);
> @@ -1199,12 +1207,6 @@ static int bxt_init_workarounds(struct intel_engine_cs 
> *engine)
>   I915_WRITE(FF_SLICE_CS_CHICKEN2,
>  
> _MASKED_BIT_ENABLE(GEN9_POOLED_EU_LOAD_BALANCING_FIX_DISABLE));
>  
> - /* WaProgramL3SqcReg1DefaultForPerf:bxt */
> - val = I915_READ(GEN8_L3SQCREG1);
> - val &= ~L3_PRIO_CREDITS_MASK;
> - val |= L3_GENERAL_PRIO_CREDITS(62) | L3_HIGH_PRIO_CREDITS(2);
> - I915_WRITE(GEN8_L3SQCREG1, val);
> -
>   /* WaToEnableHwFixForPushConstHWBug:bxt */
>   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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: add platform tag to WA

[Rodrigo Vivi]

On Tue, Nov 28, 2017 at 09:08:20PM +, Lucas De Marchi wrote:
> Cc: Ville Syrjälä 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 691600ce48c4..c42a6c672b73 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct 
> intel_crtc_state *crtc_state)
>   }
>   }
>  
> - /* Display WA #1139 */
> + /* Display WA #1139: glk */

Ah! ops... it is here! ;)

Reviewed-by: Rodrigo Vivi 

>   if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
>   crtc_state->base.adjusted_mode.htotal > 5460)
>   return false;
> -- 
> 2.14.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: follow single notation for workaround number

[Rodrigo Vivi]

On Tue, Nov 28, 2017 at 09:08:19PM +, Lucas De Marchi wrote:
> Cc: Ville Syrjälä 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c| 2 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 76c75d34e799..9a0ebf205435 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15126,7 +15126,7 @@ get_encoder_power_domains(struct drm_i915_private 
> *dev_priv)
>  
>  static void intel_early_display_was(struct drm_i915_private *dev_priv)
>  {
> - /* Display WA #1185 WaDisableDARBFClkGating:cnl,glk */
> + /* Display WA #1185 WaDisableDARBFClkGating: cnl,glk */

If you introduce the space here I believe this patch will need to get bigger.
probably to just leave without it.

>   if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
>   I915_WRITE(GEN9_CLKGATE_DIS_0, I915_READ(GEN9_CLKGATE_DIS_0) |
>  DARBF_GATING_DIS);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 9d5e72728475..691600ce48c4 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct 
> intel_crtc_state *crtc_state)
>   }
>   }
>  
> - /* Display Wa #1139 */
> + /* Display WA #1139 */

maybe good to add the affected platforms here as well?

>   if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
>   crtc_state->base.adjusted_mode.htotal > 5460)
>   return false;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a80c322c5b43..7905b8313e40 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -61,7 +61,7 @@ static void gen9_init_clock_gating(struct drm_i915_private 
> *dev_priv)
>   if (HAS_LLC(dev_priv)) {
>   /*
>* WaCompressedResourceDisplayNewHashMode:skl,kbl
> -  * Display WA#0390: skl,kbl
> +  * Display WA #0390: skl,kbl
>*
>* Must match Sampler, Pixel Back End, and Media. See
>* WaCompressedResourceSamplerPbeMediaNewHashMode.
> -- 
> 2.14.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Don't add the "force audio" property to DP connectors that don't support audio

[Rodrigo Vivi]

On Wed, Nov 29, 2017 at 04:43:02PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> No point in adding the "force audio" property to DP connectors
> that don't support audio (g4x or port A).

It makes sense... but the lack of the property there couldn't
break any existent user space?

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0e1a20e625e4..f8ead29e3c81 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5180,8 +5180,11 @@ static void
>  intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector 
> *connector)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + enum port port = dp_to_dig_port(intel_dp)->base.port;
> +
> + if (!IS_G4X(dev_priv) && port != PORT_A)
> + intel_attach_force_audio_property(connector);
>  
> - intel_attach_force_audio_property(connector);
>   intel_attach_broadcast_rgb_property(connector);
>  
>   if (intel_dp_is_edp(intel_dp)) {
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix has_audio readout for DDI A

[Rodrigo Vivi]

On Wed, Nov 29, 2017 at 04:43:03PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Transcoder EDP does not support audio. Let's not try to
> read the state of the audio enable bit HSW_AUD_PIN_ELD_CP_VLD
> based on the pipe when using transcoder EDP.
> 
> While at it make the function static and flatten it.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 20 ++--
>  drivers/gpu/drm/i915/intel_drv.h |  2 --
>  2 files changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index eff3b51872eb..48ba9b7fdc78 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2513,17 +2513,17 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
> *intel_dp)
>   udelay(600);
>  }
>  
> -bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
> -  struct intel_crtc *intel_crtc)
> +static bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
> +enum transcoder cpu_transcoder)
>  {
> - u32 temp;
> + if (cpu_transcoder == TRANSCODER_EDP)
> + return false;
>  
> - if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
> - temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> - if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
> - return true;
> - }
> - return false;
> + if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO))
> + return false;
> +
> + return I915_READ(HSW_AUD_PIN_ELD_CP_VLD) &
> + AUDIO_OUTPUT_ENABLE(cpu_transcoder);
>  }
>  
>  void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
> @@ -2616,7 +2616,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
>   }
>  
>   pipe_config->has_audio =
> - intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
> + intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
>  
>   if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp &&
>   pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index c679df99d530..c55fa245cd8c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1288,8 +1288,6 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
> *crtc_state);
>  void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state);
>  void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp);
>  bool intel_ddi_connector_get_hw_state(struct intel_connector 
> *intel_connector);
> -bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
> -  struct intel_crtc *intel_crtc);
>  void intel_ddi_get_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config);
>  
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disable DP audio for g4x

[Rodrigo Vivi]

On Wed, Nov 29, 2017 at 04:43:01PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Apparently g4x doesn't support audio over DP. Bspec lists the
> bit as "Reserved for Audio Output Enable", and empirical evidence
> tells us that the bit won't stick. So stop trying to enable DP
> audio on g4x.

Based on the display controller specified at
https://01.org/sites/default/files/documentation/g45_vol_3_register_0_0_0.pdf

you are right...
If I'm following the right spec feel free to use:

Reviewed-by: Rodrigo Vivi 

otherwise, please point me to the right place ;)

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 957735c0b4c6..0e1a20e625e4 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1643,7 +1643,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   pipe_config->has_pch_encoder = true;
>  
>   pipe_config->has_drrs = false;
> - if (port == PORT_A)
> + if (IS_G4X(dev_priv) || port == PORT_A)
>   pipe_config->has_audio = false;
>   else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
>   pipe_config->has_audio = intel_dp->has_audio;
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Interlaced DP output doesn't work on VLV/CHV

[Rodrigo Vivi]

On Wed, Nov 29, 2017 at 06:08:47PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Reject interlaced modes on VLV/CHV DP outputs. This simply does
> not work correctly in the hardware. We do get some output, but
> it's quite corrupted.
> 
> The available documentation fails to mention this fact. I
> contacted some hardware people who eventually managed to locate
> the relevant HSD for VLV, which was resolved by declaring
> interlaced DP output as not supported. The HSD was never cloned
> for CHV even though it inherited most of the hardware and
> thus has the same problems with interlaced DP output.
> 
> Cc: Dennis Vshivkov 
> Reported-by: Dennis Vshivkov 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103922
> Signed-off-by: Ville Syrjälä 

I'm afraid we won't be able to track that down...
I took a quick look on wa_database for vlv/chv to see if
something seemed related, but nothing ring a bell...

So, let's live without these modes.

Acked-by: Rodrigo Vivi 


> ---
>  drivers/gpu/drm/i915/intel_dp.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 957735c0b4c6..61cde5cd04d3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1677,6 +1677,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   conn_state->scaling_mode);
>   }
>  
> + if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
> + adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return false;
> +
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return false;
>  
> @@ -6083,7 +6087,8 @@ intel_dp_init_connector(struct intel_digital_port 
> *intel_dig_port,
>   drm_connector_init(dev, connector, _dp_connector_funcs, type);
>   drm_connector_helper_add(connector, _dp_connector_helper_funcs);
>  
> - connector->interlace_allowed = true;
> + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> + connector->interlace_allowed = true;
>   connector->doublescan_allowed = 0;
>  
>   intel_dp_init_connector_port_info(intel_dig_port);
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Change default GuC FW for KBL to v9.39

[Rodrigo Vivi]

On Wed, Nov 29, 2017 at 10:22:11PM +, Srivatsa, Anusha wrote:
> 
> 
> >-Original Message-
> >From: Kamble, Sagar A
> >Sent: Wednesday, November 29, 2017 8:19 AM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Kamble, Sagar A ; Mcgee, Jeff
> >; Spotswood, John A ;
> >Srivatsa, Anusha ; Wajdeczko, Michal
> >; Vivi, Rodrigo ; Joonas
> >Lahtinen 
> >Subject: [PATCH v2 3/3] drm/i915/guc: Change default GuC FW for KBL to v9.39
> >
> >This patch makes v9.39 firmware as default firmware for KBL.
> >
> >Note: GuC logging control is changed with this firmware. GuC is expecting 
> >i915 to
> >set control bit to enable "default logging"
> >while using GuC action UK_LOG_ENABLE_LOGGING.
> >However i915 is currently not doing this because it is version specific 
> >change and
> >can be handled entirely in GuC. It will need to be fixed in future firmwares.
> >
> >This update includes (since v9.14):
> >
> >- DCC spec changes for BXT + DCT enabling
> >- Bug Fix for power conservation feature SLPC_DCC
> >- Scheduler 1-element submission during DCC cycles.
> >- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
> >- Moving GuC non_critical r/w data to lower SRAM 64KB
> >- Media engine Reset fix.  Correctly marking context for resubmission in
> >  Media Reset case.
> >- ABT Disable bug fix. Disabled Evaluation mode on context change.
> >- Async FW in Engine Schedule feature (not enabled from KMD)
> >- GuC clean up to align developer build in line to production build.
> >- Disable ARAT interrupt before programming ARAT delta.
> >- Memory range check in Parse to avoid failure due to overflow.
> >- GuC Msg Channel Hang WA - Stall GUC for mmio access when IDI is low
> >  during CPD flow.
> >- Fix for submit queue over flow issue
> >- Enabling IBC on KBL GT3 15W, GT4 45W
> >- Disabling wrong device ID WA in production signed kernel
> >- Enabling WA for MSGCH hang issue upto required KBL stepping
> >- Clear forcewake in CSB when SQ is empty.
> >- 3Tries of GuC2CSME wake request
> >- During reset one parameter was not getting accounted
> >- Disable DCC 1-elem mode submission
> >- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
> >- This is file location change.No functional change done as part of this
> >  check in.
> >- Enabling Guc Log changes for ultra low logging for OCA
> >- Enabling Dynamic Render Power Well Hysteresis Programming for Compute
> >  Worklaods
> >- Enabling build failure check to catch critical section overflow.
> >- Disable build.bat redundant prints.
> >- Move few least used functions to non-critical section.
> >- Rearrange GuC documentation folder structure.
> >- Synchronize SLPC internal debug interface with other branches.
> >- Fixing Issue with Default Guc Log changes for OCA using special Control
> >  Bit
> >- Aggressive DCC implementation for supported platforms.
> >
> >v2: Rebase. Updated commit message.
> >
> >Signed-off-by: Jeff McGee 
> >Signed-off-by: Sagar Arun Kamble 
> >Cc: Spotswood John A 
> >Cc: Anusha Srivatsa 
> >Cc: Michal Wajdeczko 
> >Cc: Rodrigo Vivi 
> >Cc: Joonas Lahtinen 
> Reviewed-by: Anusha Srivatsa

Thanks for the patches, thanks for splitting that initial series as requested 
and thanks for review.
All 3 patches merged to dinq.

> 
> > drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
> >b/drivers/gpu/drm/i915/intel_guc_fw.c
> >index df2ff96..89862fa 100644
> >--- a/drivers/gpu/drm/i915/intel_guc_fw.c
> >+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
> >@@ -37,7 +37,7 @@
> > #define BXT_FW_MINOR 29
> >
> > #define KBL_FW_MAJOR 9
> >-#define KBL_FW_MINOR 14
> >+#define KBL_FW_MINOR 39
> >
> > #define GLK_FW_MAJOR 10
> > #define GLK_FW_MINOR 56
> >--
> >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 22/29] [media] atomisp: deprecate pci_get_bus_and_slot()

[Sakari Ailus]

Hi Sinan,

On Mon, Nov 27, 2017 at 11:57:59AM -0500, Sinan Kaya wrote:
> diff --git 
> a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c 
> b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
> index 4631b1d..51dcef57 100644
> --- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
> +++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
> @@ -39,7 +39,7 @@ static inline int platform_is(u8 model)
>  
>  static int intel_mid_msgbus_init(void)
>  {
> - pci_root = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> + pci_root = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
>   if (!pci_root) {
>   pr_err("%s: Error: msgbus PCI handle NULL\n", __func__);
>   return -ENODEV;

This file has been removed, I'm applying the rest of the patch.

Please use the media tree as the base in the future. Thanks.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

[Maarten Lankhorst]

Hey,

Op 13-11-17 om 13:05 schreef Thomas Gleixner:
> Linus,
>
> please pull the latest x86-apic-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> x86-apic-for-linus
>
> This update provides a major overhaul of the APIC initialization and vector
> allocation code:
>
>   - Unification of the APIC and interrupt mode setup which was scattered
> all over the place and was hard to follow. This also distangles the
> timer setup from the APIC initialization which brings a clear
> separation of functionality.
>
> Great detective work from Dou Lyiang!
>
>   - Refactoring of the x86 vector allocation mechanism. The existing code
> was based on nested loops and rather convoluted APIC callbacks which
> had a horrible worst case behaviour and tried to serve all different
> use cases in one go. This led to quite odd hacks when supporting the
> new managed interupt facility for multiqueue devices and made it more
> or less impossible to deal with the vector space exhaustion which was a
> major roadblock for server hibernation.
>
> Aside of that the code dealing with cpu hotplug and the system vectors
> was disconnected from the actual vector management and allocation code,
> which made it hard to follow and maintain.
>
> Utilizing the new bitmap matrix allocator core mechanism, the new
> allocator and management code consolidates the handling of system
> vectors, legacy vectors, cpu hotplug mechanisms and the actual
> allocation which needs to be aware of system and legacy vectors and
> hotplug constraints into a single consistent entity.
>
> This has one visible change: The support for multi CPU targets of
> interrupts, which is only available on a certain subset of CPUs/APIC
> variants has been removed in favour of single interrupt targets. A
> proper analysis of the multi CPU target feature revealed that there is
> no real advantage as the vast majority of interrupts end up on the CPU
> with the lowest APIC id in the set of target CPUs anyway. That change
> was agreed on by the relevant folks and allowed to simplify the
> implementation significantly and to replace rather fragile constructs
> like the vector cleanup IPI with straight forward and solid code.
> 
> Furthermore this allowed to cleanly separate the allocation details for
> legacy, normal and managed interrupts.
>
>  - Legacy interrupts are not longer wasting 16 vectors unconditionally
>
>  - Managed interrupts have now a guaranteed vector reservation, but the
>actual vector assignment happens when the interrupt is
>requested. It's guaranteed not to fail.
>
>  - Normal interrupts no longer allocate vectors unconditionally when
>the interrupt is set up (IO/APIC init or MSI(X) enable). The
>mechanism has been switched to a best effort reservation mode. The
>actual allocation happens when the interrupt is requested. Contrary
>to managed interrupts the request can fail due to vector space
>exhaustion, but drivers must handle a fail of request_irq()
>anyway. When the interrupt is freed, the vector is handed back as
>well.
>
>This solves a long standing problem with large unconditional
>vector allocations for a certain class of enterprise devices which
>prevented server hibernation due to vector space exhaustion when the
>unused allocated vectors had to be migrated to CPU0 while unplugging
>all non boot CPUs.
>
> The code has been equipped with trace points and detailed debugfs
> information to aid analysis of the vector space.
>
The changes to interrupts bring down our CI during hibernate, see:

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

I created a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=198033

Short reproducer:

Create a swapfile on a snb 2600, attempt to hibernate to it with echo disk > 
/sys/power/state, this will fail in the end, but will go through most of the 
steps.

After the almost complete hibernate, i915 will not receive irqs any more, which 
kills our entire integration testing.

Kernel config is available at 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3402/kernel.config.bz2
Results with pull request reverted at 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7333/shards.html

First bad commit:

commit fdba46ffb4c203b6e6794163493fd310f98bb4be (HEAD, refs/bisect/bad)
Author: Thomas Gleixner 
Date:   Wed Sep 13 23:29:27 2017 +0200

x86/apic: Get rid of multi CPU affinity

dmesg:
[   25.419245] PM: hibernation entry
[   25.420957] PM: Syncing filesystems ... 
[   25.464097] PM: done.
[   25.464150] Freezing user space processes ... (elapsed 0.006 seconds) done.
[   25.470453] OOM killer disabled.
[   25.470822] PM: Marking nosave pages: [mem 0x-0x0fff]
[   25.470844] PM: Marking nosave 

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Change default GuC FW for SKL to v9.33

[Srivatsa, Anusha]

>-Original Message-
>From: Kamble, Sagar A
>Sent: Wednesday, November 29, 2017 8:19 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Kamble, Sagar A ; Mcgee, Jeff
>; Spotswood, John A ;
>Srivatsa, Anusha ; Wajdeczko, Michal
>; Vivi, Rodrigo ; Joonas
>Lahtinen 
>Subject: [PATCH v2 1/3] drm/i915/guc: Change default GuC FW for SKL to v9.33
>
>This patch makes v9.33 firmware as default firmware for SKL.
>
>Note: GuC logging control is changed with this firmware. GuC is expecting i915 
>to
>set control bit to enable "default logging"
>while using GuC action UK_LOG_ENABLE_LOGGING.
>However i915 is currently not doing this because it is version specific change 
>and
>can be handled entirely in GuC. It will need to be fixed in future firmwares.
>
>This update includes (since v6.1):
>
>- HuC RSA Keys updated.
>- Adding per engine preemption support in GuC scheduler
>- Minor bug fixes.
>- Added support to log media reset count for host to read it
>- Sub-feature level control for power management features.
>- Minor clean-up for power management interface.
>- Unified power management interface and scheduler interface into
>  1 file using same version.
>- Bug Fix for multi context scheduler flag.
>- DCC spec changes for BXT + DCT enabling
>- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
>- Moving GuC non_critical r/w data to lower SRAM 64KB
>- Media engine Reset fix.  Correctly marking context for resubmission in
>  Media Reset case.
>- ABT Disable bug fix. Disabled Evaluation mode on context change.
>- Async FW in Engine Schedule feature (not enabled from KMD)
>- GuC clean up to align developer build in line to production build.
>- DCC consistency fix for SKL
>- Disable ARAT interrupt before programming ARAT delta.
>- Memory range check in Parse to avoid failure due to overflow.
>- Enabled WA for MSGCH hang issue
>- Clear forcewake in CSB when SQ is empty.
>- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
>- This is file location change.No functional change done as part of this
>  check in.
>- Enable decoupled freq for SKL GT4
>- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
>  has come from ME spec
>- During reset one parameter was not getting accounted
>- Enabling Guc Log changes for ultra low logging for OCA
>- Enabling build failure check to catch critical section overflow.
>- Disable build.bat redundant prints.
>- Move few least used functions to non-critical section.
>- Rearrange GuC documentation folder structure.
>- Synchronize SLPC internal debug interface with other branches.
>- Fixing Issue with Default Guc Log changes for OCA using special Control
>  Bit
>
>v2: Rebase. Updated commit message.
>
>Signed-off-by: Jeff McGee 
>Signed-off-by: Sagar Arun Kamble 
>Cc: Spotswood John A 
>Cc: Anusha Srivatsa 
>Cc: Michal Wajdeczko 
>Cc: Rodrigo Vivi 
>Cc: Joonas Lahtinen 
Reviewed-by: Anusha Srivatsa 

> drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
>b/drivers/gpu/drm/i915/intel_guc_fw.c
>index bbab4e1..631e932 100644
>--- a/drivers/gpu/drm/i915/intel_guc_fw.c
>+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
>@@ -30,8 +30,8 @@
> #include "intel_guc_fw.h"
> #include "i915_drv.h"
>
>-#define SKL_FW_MAJOR 6
>-#define SKL_FW_MINOR 1
>+#define SKL_FW_MAJOR 9
>+#define SKL_FW_MINOR 33
>
> #define BXT_FW_MAJOR 8
> #define BXT_FW_MINOR 7
>--
>1.9.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/gem_eio: Test we can suspend when the driver is already wedged

[Patchwork]

== Series Details ==

Series: igt/gem_eio: Test we can suspend when the driver is already wedged
URL   : https://patchwork.freedesktop.org/series/34663/
State : success

== Summary ==

Blacklisted hosts:
shard-apltotal:2663 pass:1683 dwarn:3   dfail:2   fail:26  skip:948 
time:13579s
shard-hswtotal:2620 pass:1504 dwarn:2   dfail:2   fail:10  skip:1101 
time:9371s
shard-kbltotal:2654 pass:1747 dwarn:51  dfail:3   fail:25  skip:827 
time:10751s
shard-snbtotal:2663 pass:1305 dwarn:2   dfail:2   fail:12  skip:1342 
time:8192s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Change default GuC FW for BXT to v9.29

[Srivatsa, Anusha]

>-Original Message-
>From: Kamble, Sagar A
>Sent: Wednesday, November 29, 2017 8:19 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Kamble, Sagar A ; Mcgee, Jeff
>; Spotswood, John A ;
>Srivatsa, Anusha ; Wajdeczko, Michal
>; Vivi, Rodrigo ; Joonas
>Lahtinen 
>Subject: [PATCH v2 2/3] drm/i915/guc: Change default GuC FW for BXT to v9.29
>
>This patch makes v9.29 firmware as default firmware for BXT.
>
>Note: GuC logging control is changed with this firmware. GuC is expecting i915 
>to
>set control bit to enable "default logging"
>while using GuC action UK_LOG_ENABLE_LOGGING.
>However i915 is currently not doing this because it is version specific change 
>and
>can be handled entirely in GuC. It will need to be fixed in future firmwares.
>
>This update includes (since v8.7):
>
>- Added support to log media reset count for host to read it
>- BXT WA for fixing MTP hangs. WaDisableDOPRenderClkGatingAtSubmit
>- Sub-feature level control for power management features.
>- Minor clean-up for power management interface.
>- Unified power management interface and scheduler interface into
>  1 file using same version.
>- Bug Fix for multi context scheduler flag.
>- DCC spec changes for BXT + DCT enabling
>- Springboard based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
>- Moving GuC non_critical r/w data to lower SRAM 64KB
>- Enabled IBC for BXT
>- Media engine Reset fix.  Correctly marking context for resubmission in
>  Media Reset case.
>- SLPC Dynamic RPe fix to resolve issues where incorrect frequency was set.
>- ABT Disable bug fix. Disabled Evaluation mode on context change.
>- GuC clean up to align developer build in line to production build.
>- Disable ARAT interrupt before programming ARAT delta.
>- Memory range check in Parse to avoid failure due to overflow.
>- Clear forcewake in CSB when SQ is empty.
>- SLPC IBC 1.6 for APL to ensure multiplier does not cap IA below Pe.
>- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
>- This is file location change. No functional change done as part of this
>  check in.
>- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
>  has come from ME spec
>- During reset one parameter was not getting accounted
>- Enabling Guc Log changes for ultra low logging for OCA
>- Disable build.bat redundant prints.
>- Move few least used functions to non-critical section.
>- Rearrange GuC documentation folder structure.
>- Fixing Issue with Default Guc Log changes for OCA using special Control
>  Bit
>
>v2: Rebase. Updated commit message.
>
>Signed-off-by: Jeff McGee 
>Signed-off-by: Sagar Arun Kamble 
>Cc: Spotswood John A 
>Cc: Anusha Srivatsa 
>Cc: Michal Wajdeczko 
>Cc: Rodrigo Vivi 
>Cc: Joonas Lahtinen 
Reviewed-by: Anusha Srivatsa 

> drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
>b/drivers/gpu/drm/i915/intel_guc_fw.c
>index 631e932..df2ff96 100644
>--- a/drivers/gpu/drm/i915/intel_guc_fw.c
>+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
>@@ -33,8 +33,8 @@
> #define SKL_FW_MAJOR 9
> #define SKL_FW_MINOR 33
>
>-#define BXT_FW_MAJOR 8
>-#define BXT_FW_MINOR 7
>+#define BXT_FW_MAJOR 9
>+#define BXT_FW_MINOR 29
>
> #define KBL_FW_MAJOR 9
> #define KBL_FW_MINOR 14
>--
>1.9.1

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

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Change default GuC FW for KBL to v9.39

[Srivatsa, Anusha]

>-Original Message-
>From: Kamble, Sagar A
>Sent: Wednesday, November 29, 2017 8:19 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Kamble, Sagar A ; Mcgee, Jeff
>; Spotswood, John A ;
>Srivatsa, Anusha ; Wajdeczko, Michal
>; Vivi, Rodrigo ; Joonas
>Lahtinen 
>Subject: [PATCH v2 3/3] drm/i915/guc: Change default GuC FW for KBL to v9.39
>
>This patch makes v9.39 firmware as default firmware for KBL.
>
>Note: GuC logging control is changed with this firmware. GuC is expecting i915 
>to
>set control bit to enable "default logging"
>while using GuC action UK_LOG_ENABLE_LOGGING.
>However i915 is currently not doing this because it is version specific change 
>and
>can be handled entirely in GuC. It will need to be fixed in future firmwares.
>
>This update includes (since v9.14):
>
>- DCC spec changes for BXT + DCT enabling
>- Bug Fix for power conservation feature SLPC_DCC
>- Scheduler 1-element submission during DCC cycles.
>- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
>- Moving GuC non_critical r/w data to lower SRAM 64KB
>- Media engine Reset fix.  Correctly marking context for resubmission in
>  Media Reset case.
>- ABT Disable bug fix. Disabled Evaluation mode on context change.
>- Async FW in Engine Schedule feature (not enabled from KMD)
>- GuC clean up to align developer build in line to production build.
>- Disable ARAT interrupt before programming ARAT delta.
>- Memory range check in Parse to avoid failure due to overflow.
>- GuC Msg Channel Hang WA - Stall GUC for mmio access when IDI is low
>  during CPD flow.
>- Fix for submit queue over flow issue
>- Enabling IBC on KBL GT3 15W, GT4 45W
>- Disabling wrong device ID WA in production signed kernel
>- Enabling WA for MSGCH hang issue upto required KBL stepping
>- Clear forcewake in CSB when SQ is empty.
>- 3Tries of GuC2CSME wake request
>- During reset one parameter was not getting accounted
>- Disable DCC 1-elem mode submission
>- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
>- This is file location change.No functional change done as part of this
>  check in.
>- Enabling Guc Log changes for ultra low logging for OCA
>- Enabling Dynamic Render Power Well Hysteresis Programming for Compute
>  Worklaods
>- Enabling build failure check to catch critical section overflow.
>- Disable build.bat redundant prints.
>- Move few least used functions to non-critical section.
>- Rearrange GuC documentation folder structure.
>- Synchronize SLPC internal debug interface with other branches.
>- Fixing Issue with Default Guc Log changes for OCA using special Control
>  Bit
>- Aggressive DCC implementation for supported platforms.
>
>v2: Rebase. Updated commit message.
>
>Signed-off-by: Jeff McGee 
>Signed-off-by: Sagar Arun Kamble 
>Cc: Spotswood John A 
>Cc: Anusha Srivatsa 
>Cc: Michal Wajdeczko 
>Cc: Rodrigo Vivi 
>Cc: Joonas Lahtinen 
Reviewed-by: Anusha Srivatsa

> drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
>b/drivers/gpu/drm/i915/intel_guc_fw.c
>index df2ff96..89862fa 100644
>--- a/drivers/gpu/drm/i915/intel_guc_fw.c
>+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
>@@ -37,7 +37,7 @@
> #define BXT_FW_MINOR 29
>
> #define KBL_FW_MAJOR 9
>-#define KBL_FW_MINOR 14
>+#define KBL_FW_MINOR 39
>
> #define GLK_FW_MAJOR 10
> #define GLK_FW_MINOR 56
>--
>1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_eio: Test we can suspend when the driver is already wedged

[Patchwork]

== Series Details ==

Series: igt/gem_eio: Test we can suspend when the driver is already wedged
URL   : https://patchwork.freedesktop.org/series/34663/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
62b7723e6bed126be4950223593a6fd3395c58a6 tools/intel_watermark: Right justify 
register names

with latest DRM-Tip kernel build CI_DRM_3411
8f873adc152c drm-tip: 2017y-11m-29d-16h-28m-40s UTC integration manifest

Testlist changes:
+igt@gem_eio@hibernate
+igt@gem_eio@suspend

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
fail   -> PASS   (fi-hsw-4770)
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:388s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:533s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:479s
fi-elk-e7500 total:224  pass:162  dwarn:16  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:272s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:372s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:268s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:439s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:488s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:528s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:593s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:452s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:552s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:421s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:609s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s

== Logs ==

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

[Intel-gfx] [PATCH igt] igt/gem_eio: Test we can suspend when the driver is already wedged

[Chris Wilson]

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 tests/gem_eio.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index ca0020f1..7a6be393 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -82,6 +82,15 @@ static void wedge_gpu(int fd)
igt_assert(i915_reset_control(true));
 }
 
+static void wedgeme(int drm_fd)
+{
+   int dir = igt_debugfs_dir(drm_fd);
+
+   igt_sysfs_set(dir, "i915_wedged", "-1");
+
+   close(dir);
+}
+
 static int __gem_throttle(int fd)
 {
int err = 0;
@@ -159,6 +168,18 @@ static void test_wait(int fd)
trigger_reset(fd);
 }
 
+static void test_suspend(int fd, int state)
+{
+   /* Check we can suspend when the driver is already wedged */
+   igt_require(i915_reset_control(false));
+   wedgeme(fd);
+
+   igt_system_suspend_autoresume(state, SUSPEND_TEST_DEVICES);
+
+   igt_require(i915_reset_control(true));
+   trigger_reset(fd);
+}
+
 static void test_inflight(int fd)
 {
struct drm_i915_gem_execbuffer2 execbuf;
@@ -445,6 +466,12 @@ igt_main
igt_subtest("wait")
test_wait(fd);
 
+   igt_subtest("suspend")
+   test_suspend(fd, SUSPEND_STATE_MEM);
+
+   igt_subtest("hibernate")
+   test_suspend(fd, SUSPEND_STATE_DISK);
+
igt_subtest("in-flight")
test_inflight(fd);
 
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Skip switch-to-kernel-context on suspend when wedged

[Chris Wilson]

Quoting Chris Wilson (2017-11-29 19:53:54)
> If the HW is already wedged, attempting to submit a request will
> generate an -EIO. If we tried this during suspend, we would abort
> whereas all we want to do is to go sleep and throw away the corrupt
> state.
> 
> Fixes: 5ab57c702069 ("drm/i915: Flush logical context image out to memory 
> upon suspend")
Testcase: igt/gem_eio/suspend
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Skip switch-to-kernel-context on suspend when wedged

[Chris Wilson]

If the HW is already wedged, attempting to submit a request will
generate an -EIO. If we tried this during suspend, we would abort
whereas all we want to do is to go sleep and throw away the corrupt
state.

Fixes: 5ab57c702069 ("drm/i915: Flush logical context image out to memory upon 
suspend")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354b0546a191..e083f242b8dc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4774,17 +4774,19 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
 * state. Fortunately, the kernel_context is disposable and we do
 * not rely on its state.
 */
-   ret = i915_gem_switch_to_kernel_context(dev_priv);
-   if (ret)
-   goto err_unlock;
+   if (!i915_terminally_wedged(_priv->gpu_error)) {
+   ret = i915_gem_switch_to_kernel_context(dev_priv);
+   if (ret)
+   goto err_unlock;
 
-   ret = i915_gem_wait_for_idle(dev_priv,
-I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
-   if (ret && ret != -EIO)
-   goto err_unlock;
+   ret = i915_gem_wait_for_idle(dev_priv,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED);
+   if (ret && ret != -EIO)
+   goto err_unlock;
 
-   assert_kernel_context_is_current(dev_priv);
+   assert_kernel_context_is_current(dev_priv);
+   }
i915_gem_contexts_lost(dev_priv);
mutex_unlock(>struct_mutex);
 
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal flip subtest.

[Srivatsa, Anusha]

>-Original Message-
>From: Latvala, Petri
>Sent: Wednesday, November 29, 2017 1:55 AM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org; Joseph Garvey ;
>Ville Syrjälä ; Hiler, Arkadiusz
>
>Subject: Re: [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal flip subtest.
>
>On Wed, Nov 22, 2017 at 03:05:55PM -0800, Anusha Srivatsa wrote:
>> From: Joseph Garvey 
>>
>> Test that horizontal flip works with supported rotations. Includes a
>> fix for the unrotated fb which was not being positioned correctly with
>> portrait and landscape rectangles.
>>
>> v2:(from Anusha)
>> - Change 180 degree rotation to follow the rest, use igt_swap(), make
>> flip variable a bool. Format the patch correctly (Ville, Petri
>> Latvala)
>>
>> v3: (From Anusha)
>> - Correct the name of subtests in order to avoid duplication of names
>> (Arek)
>>
>> Signed-off-by: Anusha Srivatsa 
>> Signed-off-by: Joseph Garvey 
>> Cc: Ville Syrjälä 
>> Cc: Petri Latvala 
>> Cc: Arkadiusz Hiler 
>> ---
>>  lib/igt_kms.c|   2 +-
>>  lib/igt_kms.h|   5 ++
>>  tests/kms_rotation_crc.c | 198
>> +--
>>  3 files changed, 164 insertions(+), 41 deletions(-)
>>
>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c index a572fc6..3034e44
>> 100644
>> --- a/lib/igt_kms.c
>> +++ b/lib/igt_kms.c
>> @@ -3050,7 +3050,7 @@ void igt_fb_set_size(struct igt_fb *fb,
>> igt_plane_t *plane,
>>
>>  static const char *rotation_name(igt_rotation_t rotation)  {
>> -switch (rotation) {
>> +switch (rotation & IGT_ROTATION_MASK) {
>>  case IGT_ROTATION_0:
>>  return "0°";
>>  case IGT_ROTATION_90:
>> diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 8dc118c..b83a828
>> 100644
>> --- a/lib/igt_kms.h
>> +++ b/lib/igt_kms.h
>> @@ -281,8 +281,13 @@ typedef enum {
>>  IGT_ROTATION_90  = 1 << 1,
>>  IGT_ROTATION_180 = 1 << 2,
>>  IGT_ROTATION_270 = 1 << 3,
>> +IGT_REFLECT_X= 1 << 4,
>> +IGT_REFLECT_Y= 1 << 5,
>>  } igt_rotation_t;
>>
>> +#define IGT_ROTATION_MASK \
>> +(IGT_ROTATION_0 | IGT_ROTATION_90 | IGT_ROTATION_180 |
>> +IGT_ROTATION_270)
>> +
>>  typedef struct {
>>  /*< private >*/
>>  igt_pipe_t *pipe;
>> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index
>> 5aec8fa..9e13667 100644
>> --- a/tests/kms_rotation_crc.c
>> +++ b/tests/kms_rotation_crc.c
>> @@ -32,6 +32,7 @@ typedef struct {
>>  igt_display_t display;
>>  struct igt_fb fb;
>>  struct igt_fb fb_reference;
>> +struct igt_fb fb_unrotated;
>>  struct igt_fb fb_modeset;
>>  struct igt_fb fb_flip;
>>  igt_crc_t ref_crc;
>> @@ -43,8 +44,59 @@ typedef struct {
>>  uint32_t override_fmt;
>>  uint64_t override_tiling;
>>  bool flips;
>> +int devid;
>>  } data_t;
>>
>> +typedef struct {
>> +float r;
>> +float g;
>> +float b;
>> +} rgb_color_t;
>> +
>> +static void set_color(rgb_color_t *color, float r, float g, float b)
>> +{
>> +color->r = r;
>> +color->g = g;
>> +color->b = b;
>> +}
>> +
>> +static void rotate_colors(rgb_color_t *tl, rgb_color_t *tr, rgb_color_t *br,
>> +  rgb_color_t *bl, igt_rotation_t rotation) {
>> +rgb_color_t bl_tmp, br_tmp, tl_tmp, tr_tmp;
>> +
>> +if (rotation & IGT_REFLECT_X) {
>> +igt_swap(*tl, *tr);
>> +igt_swap(*bl, *br);
>> +}
>> +
>> +if (rotation & IGT_ROTATION_90) {
>> +bl_tmp = *bl;
>> +br_tmp = *br;
>> +tl_tmp = *tl;
>> +tr_tmp = *tr;
>> +*tl = tr_tmp;
>> +*bl = tl_tmp;
>> +*tr = br_tmp;
>> +*br = bl_tmp;
>> +} else if (rotation & IGT_ROTATION_180) {
>> +igt_swap(*tl, *br);
>> +igt_swap(*tr, *bl);
>> +} else if (rotation & IGT_ROTATION_270) {
>> +bl_tmp = *bl;
>> +br_tmp = *br;
>> +tl_tmp = *tl;
>> +tr_tmp = *tr;
>> +*tl = bl_tmp;
>> +*bl = br_tmp;
>> +*tr = tl_tmp;
>> +*br = tr_tmp;
>> +}
>> +}
>> +
>> +#define RGB_COLOR(color) \
>> +color.r, color.g, color.b
>> +
>>  static void
>>  paint_squares(data_t *data, igt_rotation_t rotation,
>>struct igt_fb *fb, float o)
>> @@ -52,35 +104,21 @@ paint_squares(data_t *data, igt_rotation_t rotation,
>>  cairo_t *cr;
>>  unsigned int w = fb->width;
>>  unsigned int h = fb->height;
>> +rgb_color_t tl, tr, bl, br;
>>
>>  cr = igt_get_cairo_ctx(data->gfx_fd, fb);
>>
>> -if (rotation == IGT_ROTATION_180) {
>> -cairo_translate(cr, w, h);
>> -cairo_rotate(cr, M_PI);
>> -}
>> +set_color(, o, 0.0f, 

Re: [Intel-gfx] [PATCH] drm/i915: Avoid PPS HW/SW state mismatch due to rounding

[Imre Deak]

On Wed, Nov 29, 2017 at 08:04:31PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 29, 2017 at 07:51:37PM +0200, Imre Deak wrote:
> > We store a SW state of the t11_t12 timing in 100usec units but have to
> > program it in 100msec as required by HW. The rounding used during
> > programming means there will be a mismatch between the SW and HW states
> > of this value triggering a "PPS state mismatch" error. Avoid this by
> > storing the already rounded-up value in the SW state.
> > 
> > Note that we still calculate panel_power_cycle_delay with the finer
> > 100usec granularity to avoid any needless waits using that version of
> > the delay.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
> > Cc: joks 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 957735c0b4c6..27d2529a3416 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5355,6 +5355,12 @@ intel_dp_init_panel_power_sequencer(struct intel_dp 
> > *intel_dp)
> >  */
> > final->t8 = 1;
> > final->t9 = 1;
> > +
> > +   /*
> > +* HW has only a 100msec granularity for t11_t12 so round it up
> > +* accordingly.
> > +*/
> > +   final->t11_t12 = roundup(final->t11_t12, 100 * 10);
> 
> Reviewed-by: Ville Syrjälä 
> 
> As a micro-optimization I guess we might want to move the division here
> as well. But maybe that would cause more confusion since all the other
> timings are in 100usec units. Dunno.

Yep, had v1 like that with the same dilemma. In any case that could be
done separately imo to keep this minimal in case someone wants to
backport it.

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

[Intel-gfx] [PATCH] drm/i915: Interlaced DP output doesn't work on VLV/CHV

[Ville Syrjala]

From: Ville Syrjälä 

Reject interlaced modes on VLV/CHV DP outputs. This simply does
not work correctly in the hardware. We do get some output, but
it's quite corrupted.

The available documentation fails to mention this fact. I
contacted some hardware people who eventually managed to locate
the relevant HSD for VLV, which was resolved by declaring
interlaced DP output as not supported. The HSD was never cloned
for CHV even though it inherited most of the hardware and
thus has the same problems with interlaced DP output.

Cc: Dennis Vshivkov 
Reported-by: Dennis Vshivkov 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103922
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 957735c0b4c6..61cde5cd04d3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1677,6 +1677,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
conn_state->scaling_mode);
}
 
+   if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
+   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
+   return false;
+
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;
 
@@ -6083,7 +6087,8 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
drm_connector_init(dev, connector, _dp_connector_funcs, type);
drm_connector_helper_add(connector, _dp_connector_helper_funcs);
 
-   connector->interlace_allowed = true;
+   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
+   connector->interlace_allowed = true;
connector->doublescan_allowed = 0;
 
intel_dp_init_connector_port_info(intel_dig_port);
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH] drm/i915: Avoid PPS HW/SW state mismatch due to rounding

[Ville Syrjälä]

On Wed, Nov 29, 2017 at 07:51:37PM +0200, Imre Deak wrote:
> We store a SW state of the t11_t12 timing in 100usec units but have to
> program it in 100msec as required by HW. The rounding used during
> programming means there will be a mismatch between the SW and HW states
> of this value triggering a "PPS state mismatch" error. Avoid this by
> storing the already rounded-up value in the SW state.
> 
> Note that we still calculate panel_power_cycle_delay with the finer
> 100usec granularity to avoid any needless waits using that version of
> the delay.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
> Cc: joks 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 957735c0b4c6..27d2529a3416 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5355,6 +5355,12 @@ intel_dp_init_panel_power_sequencer(struct intel_dp 
> *intel_dp)
>*/
>   final->t8 = 1;
>   final->t9 = 1;
> +
> + /*
> +  * HW has only a 100msec granularity for t11_t12 so round it up
> +  * accordingly.
> +  */
> + final->t11_t12 = roundup(final->t11_t12, 100 * 10);

Reviewed-by: Ville Syrjälä 

As a micro-optimization I guess we might want to move the division here
as well. But maybe that would cause more confusion since all the other
timings are in 100usec units. Dunno.

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

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

[Intel-gfx] [PATCH] drm/i915: Avoid PPS HW/SW state mismatch due to rounding

[Imre Deak]

We store a SW state of the t11_t12 timing in 100usec units but have to
program it in 100msec as required by HW. The rounding used during
programming means there will be a mismatch between the SW and HW states
of this value triggering a "PPS state mismatch" error. Avoid this by
storing the already rounded-up value in the SW state.

Note that we still calculate panel_power_cycle_delay with the finer
100usec granularity to avoid any needless waits using that version of
the delay.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
Cc: joks 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 957735c0b4c6..27d2529a3416 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5355,6 +5355,12 @@ intel_dp_init_panel_power_sequencer(struct intel_dp 
*intel_dp)
 */
final->t8 = 1;
final->t9 = 1;
+
+   /*
+* HW has only a 100msec granularity for t11_t12 so round it up
+* accordingly.
+*/
+   final->t11_t12 = roundup(final->t11_t12, 100 * 10);
 }
 
 static void
-- 
2.13.2

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

[Intel-gfx] ✓ Fi.CI.IGT: success for lib: Check and report if a subtest triggers a new kernel taint

[Patchwork]

== Series Details ==

Series: lib: Check and report if a subtest triggers a new kernel taint
URL   : https://patchwork.freedesktop.org/series/34616/
State : success

== Summary ==

Blacklisted hosts:
shard-hswtotal:2610 pass:1501 dwarn:3   dfail:1   fail:9   skip:1095 
time:8916s
shard-snbtotal:2591 pass:1256 dwarn:10  dfail:5   fail:9   skip:1307 
time:7637s

== Logs ==

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Restore GT performance in headless mode with DMC loaded

[Imre Deak]

On Wed, Nov 29, 2017 at 03:21:23PM +, Tvrtko Ursulin wrote:
> 
> On 29/11/2017 15:06, Imre Deak wrote:
> > On Wed, Nov 29, 2017 at 02:30:30PM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > It seems that the DMC likes to transition between the DC states a lot when
> > > there are no connected displays (no active power domains) during command
> > > submission.
> > > 
> > > This activity on DC states has a negative impact on the performance of the
> > > chip with huge latencies observed in the interrupt handlers and elsewhere.
> > > Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> > > eight.
> > > 
> > > Work around it by introducing a new power domain named,
> > > POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> > > held for the duration of command submission activity.
> > > 
> > > v2:
> > >   * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> > >   * Protect macro body with braces. (Jani Nikula)
> > > 
> > > v3:
> > >   * Add dedicated power domain for clarity. (Chris, Imre)
> > >   * Commit message and comment text updates.
> > >   * Apply to all big-core GEN9 parts apart for Skylake which is pending 
> > > DMC
> > > firmware release.
> > > 
> > > v4:
> > >   * Power domain should be inner to device runtime pm. (Chris)
> > >   * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
> > >   * Handle async DMC loading by moving the GT_IRQ power domain logic into
> > > intel_runtime_pm. (Daniel, Chris)
> > >   * Include small core GEN9 as well. (Imre)
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> > > Testcase: igt/gem_exec_nop/headless
> > > Cc: Imre Deak 
> > > Acked-by: Chris Wilson  (v2)
> > > Cc: Chris Wilson 
> > > Cc: Dmitry Rogozhkin 
> > > ---
> > >   drivers/gpu/drm/i915/i915_drv.h |  5 
> > >   drivers/gpu/drm/i915/i915_gem.c |  2 ++
> > >   drivers/gpu/drm/i915/i915_gem_request.c | 14 +++
> > >   drivers/gpu/drm/i915/intel_csr.c| 29 +-
> > >   drivers/gpu/drm/i915/intel_runtime_pm.c | 44 
> > > +++--
> > >   5 files changed, 76 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index bddd65839f60..37b3da4fd0d4 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> > >   POWER_DOMAIN_AUX_D,
> > >   POWER_DOMAIN_GMBUS,
> > >   POWER_DOMAIN_MODESET,
> > > + POWER_DOMAIN_GT_IRQ,
> > >   POWER_DOMAIN_INIT,
> > >   POWER_DOMAIN_NUM,
> > > @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> > >   #define GT_FREQUENCY_MULTIPLIER 50
> > >   #define GEN9_FREQ_SCALER 3
> > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > + ((dev_priv)->csr.dmc_payload && \
> > > +  IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
> > > +
> > >   #include "i915_trace.h"
> > >   static inline bool intel_vtd_active(void)
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 354b0546a191..a6f522e2d1a1 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3381,6 +3381,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
> > >   if (INTEL_GEN(dev_priv) >= 6)
> > >   gen6_rps_idle(dev_priv);
> > > +
> > > + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> > >   intel_runtime_pm_put(dev_priv);
> > >   out_unlock:
> > >   mutex_unlock(_priv->drm.struct_mutex);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > > b/drivers/gpu/drm/i915/i915_gem_request.c
> > > index a90bdd26571f..c28a4ceb016d 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > > @@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
> > >   GEM_BUG_ON(!i915->gt.active_requests);
> > >   intel_runtime_pm_get_noresume(i915);
> > > +
> > > + /*
> > > +  * It seems that the DMC likes to transition between the DC states a lot
> > > +  * when there are no connected displays (no active power domains) during
> > > +  * command submission.
> > > +  *
> > > +  * This activity has negative impact on the performance of the chip with
> > > +  * huge latencies observed in the interrupt handler and elsewhere.
> > > +  *
> > > +  * Work around it by grabbing a GT IRQ power domain whilst there is any
> > > +  * GT activity, preventing any DC state transitions.
> > > +  */
> > > + intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
> > > +
> > >   i915->gt.awake = true;
> > >

Re: [Intel-gfx] [PATCH V3 00/29] PCI: deprecate pci_get_bus_and_slot()

[Bjorn Helgaas]

Hi Sinan,

On Mon, Nov 27, 2017 at 11:57:37AM -0500, Sinan Kaya wrote:
> Deprecate pci_get_bus_and_slot() in favor of pci_get_domain_bus_and_slot()
> in order to remove domain 0 assumptions in the kernel.
> 
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.
> 
> Changes from v2:
> * commit text cleanups
> * remove implicit busfn assignments and use PCI_DEVFN call in place.
> * change storage type for local copy of pci_domain_nr() value to int
> 
> Sinan Kaya (29):
>   alpha/PCI: deprecate pci_get_bus_and_slot()
>   powerpc/PCI: deprecate pci_get_bus_and_slot()
>   x86/PCI: deprecate pci_get_bus_and_slot()
>   ata: deprecate pci_get_bus_and_slot()
>   agp: nvidia: deprecate pci_get_bus_and_slot()
>   edd: deprecate pci_get_bus_and_slot()
>   ibft: deprecate pci_get_bus_and_slot()
>   drm/gma500: deprecate pci_get_bus_and_slot()
>   drm/i915: deprecate pci_get_bus_and_slot()
>   drm/nouveau: deprecate pci_get_bus_and_slot()
>   Drivers: ide: deprecate pci_get_bus_and_slot()
>   iommu/amd: deprecate pci_get_bus_and_slot()
>   powerpc/powermac: deprecate pci_get_bus_and_slot()
>   bnx2x: deprecate pci_get_bus_and_slot()
>   pch_gbe: deprecate pci_get_bus_and_slot()
>   PCI: cpqhp: deprecate pci_get_bus_and_slot()
>   PCI: ibmphp: deprecate pci_get_bus_and_slot()
>   PCI/quirks: deprecate pci_get_bus_and_slot()
>   PCI/syscall: deprecate pci_get_bus_and_slot()
>   xen: deprecate pci_get_bus_and_slot()
>   openprom: deprecate pci_get_bus_and_slot()
>   [media] atomisp: deprecate pci_get_bus_and_slot()
>   staging: rts5208: remove rtsx_read_pci_cfg_byte()
>   backlight: deprecate pci_get_bus_and_slot()
>   video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
>   video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
>   video: fbdev: riva: deprecate pci_get_bus_and_slot()
>   i7300_idle: remove unused file
>   PCI: remove pci_get_bus_and_slot() function

Thanks for doing this work!

I see other maintainers are picking up some of these.  I'll wait until
later in the cycle and pick up any remaining ones and the PCI core
parts.

If you repost the series for any reason, please capitalize the first
word of the changelog summary to match the drivers/pci convention (for
non PCI patches, follow *their* convention, of course) and put the
acks/reviewed-by tags after your signed-off-by.  I use this order:

  Reported-by:
  Tested-by:
  Signed-off-by: (author)
  Signed-off-by: (chain)
  Reviewed-by:
  Acked-by:
  Cc: sta...@vger.kernel.org# 3.4+
  Cc: (other)

But don't bother reposting the series just for this reason; I can fix
these up myself.

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

[Intel-gfx] [PATCH 3/3] drm/i915: Fix has_audio readout for DDI A

[Ville Syrjala]

From: Ville Syrjälä 

Transcoder EDP does not support audio. Let's not try to
read the state of the audio enable bit HSW_AUD_PIN_ELD_CP_VLD
based on the pipe when using transcoder EDP.

While at it make the function static and flatten it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ddi.c | 20 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 --
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index eff3b51872eb..48ba9b7fdc78 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2513,17 +2513,17 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
*intel_dp)
udelay(600);
 }
 
-bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
-struct intel_crtc *intel_crtc)
+static bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
+  enum transcoder cpu_transcoder)
 {
-   u32 temp;
+   if (cpu_transcoder == TRANSCODER_EDP)
+   return false;
 
-   if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
-   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
-   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
-   return true;
-   }
-   return false;
+   if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO))
+   return false;
+
+   return I915_READ(HSW_AUD_PIN_ELD_CP_VLD) &
+   AUDIO_OUTPUT_ENABLE(cpu_transcoder);
 }
 
 void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
@@ -2616,7 +2616,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
}
 
pipe_config->has_audio =
-   intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
+   intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
 
if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp &&
pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c679df99d530..c55fa245cd8c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1288,8 +1288,6 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
*crtc_state);
 void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state);
 void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp);
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
-bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
-struct intel_crtc *intel_crtc);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config);
 
-- 
2.13.6

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

[Intel-gfx] [PATCH 1/3] drm/i915: Disable DP audio for g4x

[Ville Syrjala]

From: Ville Syrjälä 

Apparently g4x doesn't support audio over DP. Bspec lists the
bit as "Reserved for Audio Output Enable", and empirical evidence
tells us that the bit won't stick. So stop trying to enable DP
audio on g4x.

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 957735c0b4c6..0e1a20e625e4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1643,7 +1643,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
 
pipe_config->has_drrs = false;
-   if (port == PORT_A)
+   if (IS_G4X(dev_priv) || port == PORT_A)
pipe_config->has_audio = false;
else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
pipe_config->has_audio = intel_dp->has_audio;
-- 
2.13.6

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

[Intel-gfx] [PATCH 2/3] drm/i915: Don't add the "force audio" property to DP connectors that don't support audio

[Ville Syrjala]

From: Ville Syrjälä 

No point in adding the "force audio" property to DP connectors
that don't support audio (g4x or port A).

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e1a20e625e4..f8ead29e3c81 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5180,8 +5180,11 @@ static void
 intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector 
*connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   enum port port = dp_to_dig_port(intel_dp)->base.port;
+
+   if (!IS_G4X(dev_priv) && port != PORT_A)
+   intel_attach_force_audio_property(connector);
 
-   intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
 
if (intel_dp_is_edp(intel_dp)) {
-- 
2.13.6

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with lockdep: finer-grained completion key for kthread (rev2)

[Daniel Vetter]

On Wed, Nov 29, 2017 at 11:59:23AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with lockdep: finer-grained completion key for 
> kthread (rev2)
> URL   : https://patchwork.freedesktop.org/series/34603/
> State : success
> 
> == Summary ==
> 
> Series 34603v2 series starting with lockdep: finer-grained completion key for 
> kthread
> https://patchwork.freedesktop.org/api/1.0/series/34603/revisions/2/mbox/
> 
> Test debugfs_test:
> Subgroup read_all_entries:
> dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#103938 +1
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b:
> fail   -> PASS   (fi-skl-6700k) fdo#103191
> Subgroup suspend-read-crc-pipe-b:
> incomplete -> PASS   (fi-snb-2520m) fdo#103713
> 
> fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938
> fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
> fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

This indeed seems to fix the perf_pmu lockdep splat, so put into
topic/core-for-CI with Chris' and Tvrtko's acks.
-Daniel

> 
> fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
> time:444s
> fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
> time:445s
> fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
> time:384s
> fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
> time:516s
> fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
> time:283s
> fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
> time:505s
> fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
> time:508s
> fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
> time:492s
> fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
> time:474s
> fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
> time:430s
> fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
> time:272s
> fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
> time:540s
> fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
> time:363s
> fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
> time:264s
> fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
> time:486s
> fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
> time:484s
> fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
> time:528s
> fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:478s
> fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
> time:534s
> fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
> time:598s
> fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:463s
> fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
> time:540s
> fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
> time:569s
> fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
> time:521s
> fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:503s
> fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
> time:453s
> fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
> time:557s
> fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
> time:419s
> Blacklisted hosts:
> fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
> time:611s
> 
> c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s 
> UTC integration manifest
> c7410e9c26c2 lockdep: Up MAX_LOCKDEP_CHAINS
> 68049d7ef928 lockdep: finer-grained completion key for kthread
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7338/

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

[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Change default GuC FW for BXT to v9.29

[Sagar Arun Kamble]

This patch makes v9.29 firmware as default firmware for BXT.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v8.7):

- Added support to log media reset count for host to read it
- BXT WA for fixing MTP hangs. WaDisableDOPRenderClkGatingAtSubmit
- Sub-feature level control for power management features.
- Minor clean-up for power management interface.
- Unified power management interface and scheduler interface into
  1 file using same version.
- Bug Fix for multi context scheduler flag.
- DCC spec changes for BXT + DCT enabling
- Springboard based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Enabled IBC for BXT
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- SLPC Dynamic RPe fix to resolve issues where incorrect frequency was set.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- GuC clean up to align developer build in line to production build.
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- Clear forcewake in CSB when SQ is empty.
- SLPC IBC 1.6 for APL to ensure multiplier does not cap IA below Pe.
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change. No functional change done as part of this
  check in.
- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
  has come from ME spec
- During reset one parameter was not getting accounted
- Enabling Guc Log changes for ultra low logging for OCA
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 631e932..df2ff96 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -33,8 +33,8 @@
 #define SKL_FW_MAJOR 9
 #define SKL_FW_MINOR 33
 
-#define BXT_FW_MAJOR 8
-#define BXT_FW_MINOR 7
+#define BXT_FW_MAJOR 9
+#define BXT_FW_MINOR 29
 
 #define KBL_FW_MAJOR 9
 #define KBL_FW_MINOR 14
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Change default GuC FW for KBL to v9.39

[Sagar Arun Kamble]

This patch makes v9.39 firmware as default firmware for KBL.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v9.14):

- DCC spec changes for BXT + DCT enabling
- Bug Fix for power conservation feature SLPC_DCC
- Scheduler 1-element submission during DCC cycles.
- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- Async FW in Engine Schedule feature (not enabled from KMD)
- GuC clean up to align developer build in line to production build.
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- GuC Msg Channel Hang WA - Stall GUC for mmio access when IDI is low
  during CPD flow.
- Fix for submit queue over flow issue
- Enabling IBC on KBL GT3 15W, GT4 45W
- Disabling wrong device ID WA in production signed kernel
- Enabling WA for MSGCH hang issue upto required KBL stepping
- Clear forcewake in CSB when SQ is empty.
- 3Tries of GuC2CSME wake request
- During reset one parameter was not getting accounted
- Disable DCC 1-elem mode submission
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change.No functional change done as part of this
  check in.
- Enabling Guc Log changes for ultra low logging for OCA
- Enabling Dynamic Render Power Well Hysteresis Programming for Compute
  Worklaods
- Enabling build failure check to catch critical section overflow.
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Synchronize SLPC internal debug interface with other branches.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit
- Aggressive DCC implementation for supported platforms.

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index df2ff96..89862fa 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -37,7 +37,7 @@
 #define BXT_FW_MINOR 29
 
 #define KBL_FW_MAJOR 9
-#define KBL_FW_MINOR 14
+#define KBL_FW_MINOR 39
 
 #define GLK_FW_MAJOR 10
 #define GLK_FW_MINOR 56
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Change default GuC FW for SKL to v9.33

[Sagar Arun Kamble]

This patch makes v9.33 firmware as default firmware for SKL.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v6.1):

- HuC RSA Keys updated.
- Adding per engine preemption support in GuC scheduler
- Minor bug fixes.
- Added support to log media reset count for host to read it
- Sub-feature level control for power management features.
- Minor clean-up for power management interface.
- Unified power management interface and scheduler interface into
  1 file using same version.
- Bug Fix for multi context scheduler flag.
- DCC spec changes for BXT + DCT enabling
- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- Async FW in Engine Schedule feature (not enabled from KMD)
- GuC clean up to align developer build in line to production build.
- DCC consistency fix for SKL
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- Enabled WA for MSGCH hang issue
- Clear forcewake in CSB when SQ is empty.
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change.No functional change done as part of this
  check in.
- Enable decoupled freq for SKL GT4
- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
  has come from ME spec
- During reset one parameter was not getting accounted
- Enabling Guc Log changes for ultra low logging for OCA
- Enabling build failure check to catch critical section overflow.
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Synchronize SLPC internal debug interface with other branches.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index bbab4e1..631e932 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -30,8 +30,8 @@
 #include "intel_guc_fw.h"
 #include "i915_drv.h"
 
-#define SKL_FW_MAJOR 6
-#define SKL_FW_MINOR 1
+#define SKL_FW_MAJOR 9
+#define SKL_FW_MINOR 33
 
 #define BXT_FW_MAJOR 8
 #define BXT_FW_MINOR 7
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 0/3] drm/i915/guc: Update default GuC FW for SKL/BXT/KBL

[Sagar Arun Kamble]

With new GuC firmwares (SKL v9.33, BXT v9.29, KBL v9.39) merged now
in linux-firmware.git, let us update the default firmware versions.

Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 

Sagar Arun Kamble (3):
  drm/i915/guc: Change default GuC FW for SKL to v9.33
  drm/i915/guc: Change default GuC FW for BXT to v9.29
  drm/i915/guc: Change default GuC FW for KBL to v9.39

 drivers/gpu/drm/i915/intel_guc_fw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer

[Gustavo Padovan]

2017-11-24 Sean Paul :

> On Thu, Nov 23, 2017, 7:12 AM Jani Nikula  wrote:
> 
> > I'm juggling too many things, and drm-misc maintenance is one that I
> > keep dropping on the floor. Admit reality and remove myself as
> > maintainer. This still leaves us with a nice team of three who are
> > actually doing the drm-misc work, while I focus on drm-intel.
> >
> > Cc: Daniel Vetter 
> > Cc: Gustavo Padovan 
> > Cc: Sean Paul 
> > Cc: Dave Airlie 
> > Signed-off-by: Jani Nikula 
> >
> 
> :(
> 
> Relunctantly-Acked-By: Sean Paul 

oh :(
Thanks for all your work!

Acked-by: Gustavo Padovan 

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for meson: build a full dependency for lib_igt_perf

[Patchwork]

== Series Details ==

Series: meson: build a full dependency for lib_igt_perf
URL   : https://patchwork.freedesktop.org/series/34618/
State : failure

== Summary ==

Applying: meson: build a full dependency for lib_igt_perf
Patch failed at 0001 meson: build a full dependency for lib_igt_perf
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for meson: build a full dependency for lib_igt_perf

[Patchwork]

== Series Details ==

Series: meson: build a full dependency for lib_igt_perf
URL   : https://patchwork.freedesktop.org/series/34618/
State : failure

== Summary ==

Applying: meson: build a full dependency for lib_igt_perf
Patch failed at 0001 meson: build a full dependency for lib_igt_perf
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for meson: build a full dependency for lib_igt_perf

[Patchwork]

== Series Details ==

Series: meson: build a full dependency for lib_igt_perf
URL   : https://patchwork.freedesktop.org/series/34618/
State : failure

== Summary ==

Applying: meson: build a full dependency for lib_igt_perf
Patch failed at 0001 meson: build a full dependency for lib_igt_perf
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH v2 0/3] drm/i915/guc: Update default GuC FW for SKL/BXT/KBL

[Srivatsa, Anusha]

>-Original Message-
>From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
>Sent: Tuesday, November 28, 2017 11:11 PM
>To: Kamble, Sagar A ; intel-
>g...@lists.freedesktop.org
>Cc: Spotswood, John A ; Srivatsa, Anusha
>; Wajdeczko, Michal
>; Vivi, Rodrigo 
>Subject: Re: [PATCH v2 0/3] drm/i915/guc: Update default GuC FW for
>SKL/BXT/KBL
>
>On Wed, 2017-11-29 at 11:47 +0530, Sagar Arun Kamble wrote:
>> With new GuC firmwares (SKL v9.33, BXT v9.29, KBL v9.39) available now
>> at 01.org downloads, let us update the default firmware versions.
>
>I thought the agreement was for them to be at linux-firmware repo?

Yes. 
@Sagar, slight change in commit message would be nice. Mention - 
linux-firware.git (since firmware is already merged there and that will be the 
one main point to find blobs moving forward) instead of 01.org.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for meson: build a full dependency for lib_igt_perf

[Patchwork]

== Series Details ==

Series: meson: build a full dependency for lib_igt_perf
URL   : https://patchwork.freedesktop.org/series/34618/
State : failure

== Summary ==

Series 34618 revision 1 was fully merged or fully failed: no git log

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

Re: [Intel-gfx] [PATCH i-g-t 2/2] Revert "lib/igt_aux: Make procps optional"

[Daniel Vetter]

On Wed, Nov 29, 2017 at 03:24:41PM +0200, Arkadiusz Hiler wrote:
> On Wed, Nov 29, 2017 at 12:07:06PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 24, 2017 at 05:17:48PM +0200, Arkadiusz Hiler wrote:
> > > This reverts commit d7d3f4e87b827152f00bdf89a67871736672b492
> > > and gets rid of the config option from the meson.build.
> > > 
> > > It was needed only for the Android support.
> > > 
> > > Signed-off-by: Arkadiusz Hiler 
> > 
> > Acked-by: Daniel Vetter 
> > 
> > on both patches.
> > 
> > I think there's a bunch more things that are only optional because of
> > Android. Stuff like udev and glib iirc. But maybe we want to keep those,
> > to avoid to much pain for the next time around someone wants to implement
> > Android support natively.
> > -Daniel
> 
> Pushed, thanks for Acks and R-bs!
> 
> As of further cleanups, there is one really impending on us
> - the libunwind one.
> 
> We have huge sections of the code wrapped in ifdefs which bit us more
> than once - it's easy to misplace code in there, code that should always
> be compiled.
> 
> This needs a rework, initial ideas is to put all the unwind related mess
> into separate file and compile the whole thing conditionally - for
> clearer separation.
> 
> We would also need "fallback" noop implementation of some of those
> functions.
> 
> Or we may ask ourself, with Android support gone, is this really worth
> it and shouldn't we make libunwind non-optional and just get rid of the
> preprocessor macors? :-)

+1 on simply requiring libunwind. The other option is more work, and can
be done when we have a real ask for it (aka Android, in which case your
suggested split-out is probably what we want).
-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 3/3] drm/i915: Pass crtc state to intel_pipe_{enable, disable}()

[Chris Wilson]

Quoting Ville Syrjala (2017-11-29 15:37:32)
> From: Ville Syrjälä 
> 
> Get rid of the crtc->config usages from within
> intel_pipe_{enable,disable}() by passing in the appropriate
> crtc state.
> 
> Signed-off-by: Ville Syrjälä 

Looks mechanical, so I hope I didn't miss anything important,
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Wait for pipe to start on i830 as well

[Chris Wilson]

Quoting Ville Syrjala (2017-11-29 15:37:31)
> From: Ville Syrjälä 
> 
> We should make sure the pipe has fully started when we enable it from
> the i830 "power well". Otherwise theoretically i830 could also hit
> problems with vblank timestamps jumping around (since we skip the
> wait during modeset on i830). Additionally moving planes between the
> pipes etc. might not work correctly until both pipes are actually up and
> running.
> 
> v2: Less pointless duplication in the code (Chris)
> 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson  #v1
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Fix vblank timestamp/frame counter jumps on gen2

[Chris Wilson]

Quoting Ville Syrjala (2017-11-29 15:37:30)
> From: Ville Syrjälä 
> 
> Previously I was under the impression that the scanline counter
> reads 0 when the pipe is off. Turns out that's not correct, and
> instead the scanline counter simply stops when the pipe stops, and
> it retains it's last value until the pipe starts up again, at which
> point the scanline counter jumps to vblank start.
> 
> These jumps can cause the timestamp to jump backwards by one frame.
> Since we use the timestamps to guesstimage also the frame counter
> value on gen2, that would cause the frame counter to also jump
> backwards, which leads to a massice difference from the previous value.
> The end result is that flips/vblank events don't appear to complete as
> they're stuck waiting for the frame counter to catch up to that massive
> difference.
> 
> Fix the problem properly by actually making sure the scanline counter
> has started to move before we assume that it's safe to enable vblank
> processing.
> 
> v2: Less pointless duplication in the code (Chris)
> 
> Cc: sta...@vger.kernel.org
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson  #v1
> Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank 
> timestamps on gen2")
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

cross-release ftl

From Chris:

"Fwiw, this isn't cross-release but us reloading the module many times,
creating a whole host of new lockclasses. Even more fun is when the
module gets a slightly different address and the new lock address hashes
into an old lock...

"I did think about a module-hook to revoke the stale lockclasses, but
that still leaves all the hashed chains.

"This particular nuisance was temporarily pushed back by teaching igt not
to reload i915.ko on a whim."

Cc: Tvrtko Ursulin 
Cc: Marta Lofstedt 
References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
Signed-off-by: Daniel Vetter 
---
 kernel/locking/lockdep_internals.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep_internals.h 
b/kernel/locking/lockdep_internals.h
index d459d624ba2a..41630a5385c6 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -69,7 +69,7 @@ enum {
 #else
 #define MAX_LOCKDEP_ENTRIES32768UL
 
-#define MAX_LOCKDEP_CHAINS_BITS16
+#define MAX_LOCKDEP_CHAINS_BITS17
 
 /*
  * Stack-trace: tightly packed array of stack backtrace
-- 
2.15.0

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

[Intel-gfx] [PATCH 1/2] lockdep: finer-grained completion key for kthread

[Daniel Vetter]

Ideally we'd create the key through a macro at the real callers and
pass it all the way down. This would give us better coverage for cases
where a bunch of kthreads are created for the same thing.
But this gets the job done meanwhile and unblocks our CI. Refining
later on is always possible.

v2:
- make it compile
- use the right map (Tvrtko)

v3:

lockdep insist on a static key, so the cheap way didn't work. Wire
2 keys through all the callers.

I didn't extend this up to alloc_workqueue because the
lockdep_invariant_state() call should separate the work functions from
the workqueue kthread logic and prevent cross-release state from
leaking between unrelated work queues that happen to reuse the same
kthreads.

v4: CI found more compile fail :-/

Cc: Tvrtko Ursulin 
Cc: Marta Lofstedt 
References: https://bugs.freedesktop.org/show_bug.cgi?id=103950
Signed-off-by: Daniel Vetter 
---
 include/linux/kthread.h | 48 -
 kernel/kthread.c| 70 ++---
 2 files changed, 90 insertions(+), 28 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..7a9463f0be5c 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -6,10 +6,12 @@
 #include 
 #include 
 
-__printf(4, 5)
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+__printf(6, 7)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
   void *data,
   int node,
+  struct lock_class_key *exited_key,
+  struct lock_class_key *parked_key,
   const char namefmt[], ...);
 
 /**
@@ -25,12 +27,27 @@ struct task_struct *kthread_create_on_node(int 
(*threadfn)(void *data),
  */
 #define kthread_create(threadfn, data, namefmt, arg...) \
kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
+#define kthread_create_on_node(threadfn, data, node, namefmt, arg...)  \
+({ \
+   static struct lock_class_key __exited_key, __parked_key;\
+   _kthread_create_on_node(threadfn, data, node, &__exited_key,\
+  &__parked_key, namefmt, ##arg);  \
+})
 
 
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
  void *data,
  unsigned int cpu,
+ struct lock_class_key *exited_key,
+ struct lock_class_key *parked_key,
  const char *namefmt);
+#define kthread_create_on_cpu(threadfn, data, cpu, namefmt)\
+({ \
+   static struct lock_class_key __exited_key, __parked_key;\
+   _kthread_create_on_cpu(threadfn, data, cpu, &__exited_key,\
+  &__parked_key, namefmt); \
+})
+
 
 /**
  * kthread_run - create and wake a thread.
@@ -171,13 +188,30 @@ extern void __kthread_init_worker(struct kthread_worker 
*worker,
 
 int kthread_worker_fn(void *worker_ptr);
 
-__printf(2, 3)
+__printf(4, 5)
 struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...);
+_kthread_create_worker(unsigned int flags,
+  struct lock_class_key *exited_key,
+  struct lock_class_key *parked_key,
+  const char namefmt[], ...);
+#define kthread_create_worker(flags, namefmt...)   
\
+({ \
+   static struct lock_class_key __exited_key, __parked_key;\
+   _kthread_create_worker(flags, &__exited_key, &__parked_key, \
+  ##namefmt);  \
+})
 
-__printf(3, 4) struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+__printf(5, 6) struct kthread_worker *
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+  struct lock_class_key *exited_key,
+  struct lock_class_key *parked_key,
 const char namefmt[], ...);
+#define kthread_create_worker_on_cpu(cpu, flags, namefmt...)   \
+({ \
+   static struct lock_class_key __exited_key, __parked_key;\
+   _kthread_create_worker_on_cpu(cpu, flags, &__exited_key, &__parked_key,\
+  ##namefmt);   

[Intel-gfx] [PATCH 0/2] lockdep cross-release fallout from -rc1

[Daniel Vetter]

Hi all,

-rc1 set our CI on fire with a pile of issues that cross-release
highlights. The two patches in this series get things back into working
order on our side, so we pulled them into our local branches to unblock CI
and drm/i915.

But they're ofc far from polished, so pls look at this more as a bug
report than bugfix submission :-)

Cheers, Daniel

Daniel Vetter (2):
  lockdep: finer-grained completion key for kthread
  lockdep: Up MAX_LOCKDEP_CHAINS

 include/linux/kthread.h| 48 ++
 kernel/kthread.c   | 70 ++
 kernel/locking/lockdep_internals.h |  2 +-
 3 files changed, 91 insertions(+), 29 deletions(-)

-- 
2.15.0

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

[Intel-gfx] [PATCH v2 2/3] drm/i915: Wait for pipe to start on i830 as well

[Ville Syrjala]

From: Ville Syrjälä 

We should make sure the pipe has fully started when we enable it from
the i830 "power well". Otherwise theoretically i830 could also hit
problems with vblank timestamps jumping around (since we skip the
wait during modeset on i830). Additionally moving planes between the
pipes etc. might not work correctly until both pipes are actually up and
running.

v2: Less pointless duplication in the code (Chris)

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7280dd699316..e7309d4d4992 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14679,6 +14679,7 @@ int intel_modeset_init(struct drm_device *dev)
 
 void i830_enable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
+   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
/* 640x480@60Hz, ~25175 kHz */
struct dpll clock = {
.m1 = 18,
@@ -14742,6 +14743,8 @@ void i830_enable_pipe(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 
I915_WRITE(PIPECONF(pipe), PIPECONF_ENABLE | PIPECONF_PROGRESSIVE);
POSTING_READ(PIPECONF(pipe));
+
+   intel_wait_for_pipe_scanline_moving(crtc);
 }
 
 void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
-- 
2.13.6

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

[Intel-gfx] [PATCH 3/3] drm/i915: Pass crtc state to intel_pipe_{enable, disable}()

[Ville Syrjala]

From: Ville Syrjälä 

Get rid of the crtc->config usages from within
intel_pipe_{enable,disable}() by passing in the appropriate
crtc state.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 76 +++-
 1 file changed, 23 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e7309d4d4992..b547974b06bd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1038,28 +1038,14 @@ static void intel_wait_for_pipe_scanline_moving(struct 
intel_crtc *crtc)
wait_for_pipe_scanline_moving(crtc, true);
 }
 
-/*
- * intel_wait_for_pipe_off - wait for pipe to turn off
- * @crtc: crtc whose pipe to wait for
- *
- * After disabling a pipe, we can't wait for vblank in the usual way,
- * spinning on the vblank interrupt status bit, since we won't actually
- * see an interrupt when the pipe is disabled.
- *
- * On Gen4 and above:
- *   wait for the pipe register state bit to turn off
- *
- * Otherwise:
- *   wait for the display line value to settle (it usually
- *   ends up stopping at the start of the next frame).
- *
- */
-static void intel_wait_for_pipe_off(struct intel_crtc *crtc)
+static void
+intel_wait_for_pipe_off(const struct intel_crtc_state *old_crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
 
if (INTEL_GEN(dev_priv) >= 4) {
+   enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
i915_reg_t reg = PIPECONF(cpu_transcoder);
 
/* Wait for the Pipe State to go off */
@@ -1828,19 +1814,12 @@ enum pipe intel_crtc_pch_transcoder(struct intel_crtc 
*crtc)
return crtc->pipe;
 }
 
-/**
- * intel_enable_pipe - enable a pipe, asserting requirements
- * @crtc: crtc responsible for the pipe
- *
- * Enable @crtc's pipe, making sure that various hardware specific requirements
- * are met, if applicable, e.g. PLL enabled, LVDS pairs enabled, etc.
- */
-static void intel_enable_pipe(struct intel_crtc *crtc)
+static void intel_enable_pipe(const struct intel_crtc_state *new_crtc_state)
 {
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
enum pipe pipe = crtc->pipe;
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
i915_reg_t reg;
u32 val;
 
@@ -1854,12 +1833,12 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
 * need the check.
 */
if (HAS_GMCH_DISPLAY(dev_priv)) {
-   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DSI))
+   if (intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
assert_dsi_pll_enabled(dev_priv);
else
assert_pll_enabled(dev_priv, pipe);
} else {
-   if (crtc->config->has_pch_encoder) {
+   if (new_crtc_state->has_pch_encoder) {
/* if driving the PCH, we need FDI enabled */
assert_fdi_rx_pll_enabled(dev_priv,
  
intel_crtc_pch_transcoder(crtc));
@@ -1887,24 +1866,15 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
 * when it's derived from the timestamps. So let's wait for the
 * pipe to start properly before we call drm_crtc_vblank_on()
 */
-   if (dev->max_vblank_count == 0)
+   if (dev_priv->drm.max_vblank_count == 0)
intel_wait_for_pipe_scanline_moving(crtc);
 }
 
-/**
- * intel_disable_pipe - disable a pipe, asserting requirements
- * @crtc: crtc whose pipes is to be disabled
- *
- * Disable the pipe of @crtc, making sure that various hardware
- * specific requirements are met, if applicable, e.g. plane
- * disabled, panel fitter off, etc.
- *
- * Will wait until the pipe has shut down before returning.
- */
-static void intel_disable_pipe(struct intel_crtc *crtc)
+static void intel_disable_pipe(const struct intel_crtc_state *old_crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 val;
@@ -1926,7 +1896,7 @@ static void intel_disable_pipe(struct intel_crtc *crtc)
 * 

[Intel-gfx] [PATCH v2 1/3] drm/i915: Fix vblank timestamp/frame counter jumps on gen2

[Ville Syrjala]

From: Ville Syrjälä 

Previously I was under the impression that the scanline counter
reads 0 when the pipe is off. Turns out that's not correct, and
instead the scanline counter simply stops when the pipe stops, and
it retains it's last value until the pipe starts up again, at which
point the scanline counter jumps to vblank start.

These jumps can cause the timestamp to jump backwards by one frame.
Since we use the timestamps to guesstimage also the frame counter
value on gen2, that would cause the frame counter to also jump
backwards, which leads to a massice difference from the previous value.
The end result is that flips/vblank events don't appear to complete as
they're stuck waiting for the frame counter to catch up to that massive
difference.

Fix the problem properly by actually making sure the scanline counter
has started to move before we assume that it's safe to enable vblank
processing.

v2: Less pointless duplication in the code (Chris)

Cc: sta...@vger.kernel.org
Cc: Daniel Vetter 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  #v1
Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank 
timestamps on gen2")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 51 +---
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f7dc7b7fed80..7280dd699316 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -998,7 +998,8 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct 
drm_i915_private *dev_priv,
return crtc->config->cpu_transcoder;
 }
 
-static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe)
+static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv,
+   enum pipe pipe)
 {
i915_reg_t reg = PIPEDSL(pipe);
u32 line1, line2;
@@ -1013,7 +1014,28 @@ static bool pipe_dsl_stopped(struct drm_i915_private 
*dev_priv, enum pipe pipe)
msleep(5);
line2 = I915_READ(reg) & line_mask;
 
-   return line1 == line2;
+   return line1 != line2;
+}
+
+static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc, bool state)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+
+   /* Wait for the display line to settle/start moving */
+   if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
+   DRM_ERROR("pipe %c scanline %s wait timed out\n",
+ pipe_name(pipe), onoff(state));
+}
+
+static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
+{
+   wait_for_pipe_scanline_moving(crtc, false);
+}
+
+static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc)
+{
+   wait_for_pipe_scanline_moving(crtc, true);
 }
 
 /*
@@ -1036,7 +1058,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc 
*crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
-   enum pipe pipe = crtc->pipe;
 
if (INTEL_GEN(dev_priv) >= 4) {
i915_reg_t reg = PIPECONF(cpu_transcoder);
@@ -1047,9 +1068,7 @@ static void intel_wait_for_pipe_off(struct intel_crtc 
*crtc)
100))
WARN(1, "pipe_off wait timed out\n");
} else {
-   /* Wait for the display line to settle */
-   if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
-   WARN(1, "pipe_off wait timed out\n");
+   intel_wait_for_pipe_scanline_stopped(crtc);
}
 }
 
@@ -1862,15 +1881,14 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
POSTING_READ(reg);
 
/*
-* Until the pipe starts DSL will read as 0, which would cause
-* an apparent vblank timestamp jump, which messes up also the
-* frame count when it's derived from the timestamps. So let's
-* wait for the pipe to start properly before we call
-* drm_crtc_vblank_on()
+* Until the pipe starts PIPEDSL reads will return a stale value,
+* which causes an apparent vblank timestamp jump when PIPEDSL
+* resets to its proper value. That also messes up the frame count
+* when it's derived from the timestamps. So let's wait for the
+* pipe to start properly before we call drm_crtc_vblank_on()
 */
-   if (dev->max_vblank_count == 0 &&
-   wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 
50))
-   DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe));
+   if (dev->max_vblank_count == 0)
+   

Re: [Intel-gfx] [PATCH v4] drm/i915: Restore GT performance in headless mode with DMC loaded

[Tvrtko Ursulin]

On 29/11/2017 15:06, Imre Deak wrote:

On Wed, Nov 29, 2017 at 02:30:30PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

It seems that the DMC likes to transition between the DC states a lot when
there are no connected displays (no active power domains) during command
submission.

This activity on DC states has a negative impact on the performance of the
chip with huge latencies observed in the interrupt handlers and elsewhere.
Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
eight.

Work around it by introducing a new power domain named,
POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
held for the duration of command submission activity.

v2:
  * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
  * Protect macro body with braces. (Jani Nikula)

v3:
  * Add dedicated power domain for clarity. (Chris, Imre)
  * Commit message and comment text updates.
  * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
firmware release.

v4:
  * Power domain should be inner to device runtime pm. (Chris)
  * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
  * Handle async DMC loading by moving the GT_IRQ power domain logic into
intel_runtime_pm. (Daniel, Chris)
  * Include small core GEN9 as well. (Imre)

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak 
Acked-by: Chris Wilson  (v2)
Cc: Chris Wilson 
Cc: Dmitry Rogozhkin 
---
  drivers/gpu/drm/i915/i915_drv.h |  5 
  drivers/gpu/drm/i915/i915_gem.c |  2 ++
  drivers/gpu/drm/i915/i915_gem_request.c | 14 +++
  drivers/gpu/drm/i915/intel_csr.c| 29 +-
  drivers/gpu/drm/i915/intel_runtime_pm.c | 44 +++--
  5 files changed, 76 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..37b3da4fd0d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -398,6 +398,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
+   POWER_DOMAIN_GT_IRQ,
POWER_DOMAIN_INIT,
  
  	POWER_DOMAIN_NUM,

@@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
  #define GT_FREQUENCY_MULTIPLIER 50
  #define GEN9_FREQ_SCALER 3
  
+#define NEEDS_CSR_GT_PERF_WA(dev_priv) \

+   ((dev_priv)->csr.dmc_payload && \
+IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
+
  #include "i915_trace.h"
  
  static inline bool intel_vtd_active(void)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354b0546a191..a6f522e2d1a1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3381,6 +3381,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
  
  	if (INTEL_GEN(dev_priv) >= 6)

gen6_rps_idle(dev_priv);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
intel_runtime_pm_put(dev_priv);
  out_unlock:
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a90bdd26571f..c28a4ceb016d 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
GEM_BUG_ON(!i915->gt.active_requests);
  
  	intel_runtime_pm_get_noresume(i915);

+
+   /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+   intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
i915->gt.awake = true;
  
  	intel_enable_gt_powersave(i915);

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 07e4f7bc4412..8b188e9f283b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -403,24 +403,33 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
*dev_priv,
  
  static void csr_load_work_fn(struct work_struct *work)

  {
-   struct drm_i915_private *dev_priv;
-   struct intel_csr *csr;
+   struct drm_i915_private *dev_priv =
+   container_of(work, typeof(*dev_priv), csr.work);
+   struct intel_csr *csr = _priv->csr;
const struct 

[Intel-gfx] ✗ Fi.CI.BAT: failure for meson: build a full dependency for lib_igt_perf

[Patchwork]

== Series Details ==

Series: meson: build a full dependency for lib_igt_perf
URL   : https://patchwork.freedesktop.org/series/34618/
State : failure

== Summary ==

Series 34618 revision 1 was fully merged or fully failed: no git log

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

Re: [Intel-gfx] [PATCH i-g-t 0/2] kms_plane: Enumerate outputs before planes

[Daniel Vetter]

On Tue, Nov 21, 2017 at 09:52:52PM +0200, Imre Deak wrote:
> Enumerate outputs before planes means we can avoid doing an extra
> modeset when calculating the reference CRC during the test of each
> plane. In addition when testing multiple outputs we can avoid a full
> modeset we currently do whenever switching to a new output within a
> subtest. This speeds up things especially on internal panels with long
> power cycle delays.
> 
> Below is the runtime of kms_plane on my GLK before and after the change.
> I excluded from this the DPMS and suspend subtests, since those
> transitions have a bigger overhead, unrelated to this change.

Even better would be to push the modeset out of the subtests into
igt_fixtures, so that we can amortize them over all subtests. Since
somewhen in the future CI will run tests binaries-at-a-time, instead of
subtests.

That means we won't test all combinations of crtc/output, but for all the
hw I know there's no difference really. Timestamps are a different story,
but these tests here don't check for that.

And yes we need to make these tests faster, especially on gen9 kms takes
too long.

Either way this improves a lot already, on both patches:

Reviewed-by: Daniel Vetter 

> 
> With a single HDMI output:
>  42s vs 26s
> 
> With a single eDP output:
> 115s vs 50s
> 
> With eDP+HDMI output:
> 171s vs 74s
> 
> Imre Deak (2):
>   kms_plane: Enumerate outputs before planes in position subtests
>   kms_plane: Enumerate outputs before planes in panning subtests
> 
>  tests/kms_plane.c | 120 
> +++---
>  1 file changed, 51 insertions(+), 69 deletions(-)
> 
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Restore GT performance in headless mode with DMC loaded

[Imre Deak]

On Wed, Nov 29, 2017 at 02:30:30PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> It seems that the DMC likes to transition between the DC states a lot when
> there are no connected displays (no active power domains) during command
> submission.
> 
> This activity on DC states has a negative impact on the performance of the
> chip with huge latencies observed in the interrupt handlers and elsewhere.
> Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> eight.
> 
> Work around it by introducing a new power domain named,
> POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> held for the duration of command submission activity.
> 
> v2:
>  * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
>  * Protect macro body with braces. (Jani Nikula)
> 
> v3:
>  * Add dedicated power domain for clarity. (Chris, Imre)
>  * Commit message and comment text updates.
>  * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
>firmware release.
> 
> v4:
>  * Power domain should be inner to device runtime pm. (Chris)
>  * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
>  * Handle async DMC loading by moving the GT_IRQ power domain logic into
>intel_runtime_pm. (Daniel, Chris)
>  * Include small core GEN9 as well. (Imre)
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak 
> Acked-by: Chris Wilson  (v2)
> Cc: Chris Wilson 
> Cc: Dmitry Rogozhkin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  5 
>  drivers/gpu/drm/i915/i915_gem.c |  2 ++
>  drivers/gpu/drm/i915/i915_gem_request.c | 14 +++
>  drivers/gpu/drm/i915/intel_csr.c| 29 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 44 
> +++--
>  5 files changed, 76 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..37b3da4fd0d4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -398,6 +398,7 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_AUX_D,
>   POWER_DOMAIN_GMBUS,
>   POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_GT_IRQ,
>   POWER_DOMAIN_INIT,
>  
>   POWER_DOMAIN_NUM,
> @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define GT_FREQUENCY_MULTIPLIER 50
>  #define GEN9_FREQ_SCALER 3
>  
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + ((dev_priv)->csr.dmc_payload && \
> +  IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
> +
>  #include "i915_trace.h"
>  
>  static inline bool intel_vtd_active(void)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 354b0546a191..a6f522e2d1a1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3381,6 +3381,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
>  
>   if (INTEL_GEN(dev_priv) >= 6)
>   gen6_rps_idle(dev_priv);
> +
> + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
>   intel_runtime_pm_put(dev_priv);
>  out_unlock:
>   mutex_unlock(_priv->drm.struct_mutex);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index a90bdd26571f..c28a4ceb016d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
>   GEM_BUG_ON(!i915->gt.active_requests);
>  
>   intel_runtime_pm_get_noresume(i915);
> +
> + /*
> +  * It seems that the DMC likes to transition between the DC states a lot
> +  * when there are no connected displays (no active power domains) during
> +  * command submission.
> +  *
> +  * This activity has negative impact on the performance of the chip with
> +  * huge latencies observed in the interrupt handler and elsewhere.
> +  *
> +  * Work around it by grabbing a GT IRQ power domain whilst there is any
> +  * GT activity, preventing any DC state transitions.
> +  */
> + intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
> +
>   i915->gt.awake = true;
>  
>   intel_enable_gt_powersave(i915);
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 07e4f7bc4412..8b188e9f283b 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -403,24 +403,33 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
> *dev_priv,
>  
>  static void csr_load_work_fn(struct work_struct *work)
>  {
> - struct drm_i915_private *dev_priv;
> - struct intel_csr *csr;
> + struct drm_i915_private *dev_priv =
> +

[Intel-gfx] ✓ Fi.CI.BAT: success for lib: Check and report if a subtest triggers a new kernel taint

[Patchwork]

== Series Details ==

Series: lib: Check and report if a subtest triggers a new kernel taint
URL   : https://patchwork.freedesktop.org/series/34616/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
643dc097156fa9a0ab9286c7c159459cfbe3079e Revert "lib/igt_aux: Make procps 
optional"

with latest DRM-Tip kernel build CI_DRM_3407
05ece2ad7959 drm-tip: 2017y-11m-29d-13h-15m-55s UTC integration manifest

No testlist changes.

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:389s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:522s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:492s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:476s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:431s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:548s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:357s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:535s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:519s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:553s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:417s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:605s
fi-glk-dsi   total:63   pass:55   dwarn:0   dfail:0   fail:0   skip:7  

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

[Maarten Lankhorst]

Op 28-11-17 om 16:13 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Daniel Vetter wrote:
>
>> On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
>>> Some drivers like i915 start with crtc's enabled, but with deferred
>>> fbcon setup they were no longer disabled as part of fbdev setup.
>>> Headless units could no longer enter pc3 state because the crtc was
>>> still enabled.
>>>
>>> Fix this by calling restore_fbdev_mode when we would have called
>>> it otherwise once during initial fbdev setup.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
>>
>> Please use dim fixes to get a more complete Cc: list for regression fixes.
>>
>>> Cc:  # v4.14+
>>> Reported-by: Thomas Voegtle 
>>
>> Reviewed-by: Daniel Vetter 
>>
>> But please confirm with the reporter that it indeed fixes the issue before
>> pushing.
>> -Daniel
>
> I re-checked the latest version of the patch and it indeed fixes the problem.
>
> Thanks,
>
>    Thomas
>
Pushed, thanks for the report. :)

~Maarten

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

Re: [Intel-gfx] [PATCH i-g-t 5/5] tools/intel_watermark: Right justify register names

[Ville Syrjälä]

On Wed, Nov 22, 2017 at 11:44:32PM +, Pandiyan, Dhinakaran wrote:
> Reviewed-by: Dhinakaran Pandiyan  for the
> series.

Series pushed. Thanks for the review.

> 
> 
> On Tue, 2017-11-21 at 20:49 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > I think the dump is a more legible when the register names
> > are right justified. That way the register name and its value
> > are right next to each other.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Tvrtko Ursulin 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  tools/intel_watermark.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
> > index 3c70f4ec54fb..308e351dcd2f 100644
> > --- a/tools/intel_watermark.c
> > +++ b/tools/intel_watermark.c
> > @@ -248,7 +248,7 @@ static void skl_wm_dump(void)
> > }
> >  
> > for (pipe = 0; pipe < num_pipes; pipe++) {
> > -   printf("%-18s 0x%08x\t",
> > +   printf("%18s 0x%08x\t",
> >skl_wm_linetime_reg_name(pipe),
> >wm_linetime[pipe]);
> > }
> > @@ -260,7 +260,7 @@ static void skl_wm_dump(void)
> > if (plane >= skl_num_planes(devid, pipe))
> > break;
> >  
> > -   printf("%-18s 0x%08x\t" ,
> > +   printf("%18s 0x%08x\t" ,
> >skl_wm_reg_name(pipe, plane, level),
> >wm[level][pipe][plane]);
> > }
> > @@ -274,7 +274,7 @@ static void skl_wm_dump(void)
> > if (plane >= skl_num_planes(devid, pipe))
> > break;
> >  
> > -   printf("%-18s 0x%08x\t",
> > +   printf("%18s 0x%08x\t",
> >skl_wm_trans_reg_name(pipe, plane),
> >wm_trans[pipe][plane]);
> > }
> > @@ -287,7 +287,7 @@ static void skl_wm_dump(void)
> > if (plane >= skl_num_planes(devid, pipe))
> > break;
> >  
> > -   printf("%-18s 0x%08x\t",
> > +   printf("%18s 0x%08x\t",
> >skl_buf_cfg_reg_name(pipe, plane),
> >buf_cfg[pipe][plane]);
> > }

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

[Intel-gfx] [PATCH v4] drm/i915: Restore GT performance in headless mode with DMC loaded

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

It seems that the DMC likes to transition between the DC states a lot when
there are no connected displays (no active power domains) during command
submission.

This activity on DC states has a negative impact on the performance of the
chip with huge latencies observed in the interrupt handlers and elsewhere.
Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
eight.

Work around it by introducing a new power domain named,
POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
held for the duration of command submission activity.

v2:
 * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
 * Protect macro body with braces. (Jani Nikula)

v3:
 * Add dedicated power domain for clarity. (Chris, Imre)
 * Commit message and comment text updates.
 * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
   firmware release.

v4:
 * Power domain should be inner to device runtime pm. (Chris)
 * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
 * Handle async DMC loading by moving the GT_IRQ power domain logic into
   intel_runtime_pm. (Daniel, Chris)
 * Include small core GEN9 as well. (Imre)

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless
Cc: Imre Deak 
Acked-by: Chris Wilson  (v2)
Cc: Chris Wilson 
Cc: Dmitry Rogozhkin 
---
 drivers/gpu/drm/i915/i915_drv.h |  5 
 drivers/gpu/drm/i915/i915_gem.c |  2 ++
 drivers/gpu/drm/i915/i915_gem_request.c | 14 +++
 drivers/gpu/drm/i915/intel_csr.c| 29 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 44 +++--
 5 files changed, 76 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..37b3da4fd0d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -398,6 +398,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
+   POWER_DOMAIN_GT_IRQ,
POWER_DOMAIN_INIT,
 
POWER_DOMAIN_NUM,
@@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define GT_FREQUENCY_MULTIPLIER 50
 #define GEN9_FREQ_SCALER 3
 
+#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
+   ((dev_priv)->csr.dmc_payload && \
+IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
+
 #include "i915_trace.h"
 
 static inline bool intel_vtd_active(void)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354b0546a191..a6f522e2d1a1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3381,6 +3381,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
 
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
intel_runtime_pm_put(dev_priv);
 out_unlock:
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a90bdd26571f..c28a4ceb016d 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
GEM_BUG_ON(!i915->gt.active_requests);
 
intel_runtime_pm_get_noresume(i915);
+
+   /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+   intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
i915->gt.awake = true;
 
intel_enable_gt_powersave(i915);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 07e4f7bc4412..8b188e9f283b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -403,24 +403,33 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
*dev_priv,
 
 static void csr_load_work_fn(struct work_struct *work)
 {
-   struct drm_i915_private *dev_priv;
-   struct intel_csr *csr;
+   struct drm_i915_private *dev_priv =
+   container_of(work, typeof(*dev_priv), csr.work);
+   struct intel_csr *csr = _priv->csr;
const struct firmware *fw = NULL;
+   u32 *dmc_payload;
 
-   dev_priv = container_of(work, typeof(*dev_priv), csr.work);
-   csr 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop gem_hangcheck_forcewake.c

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop 
gem_hangcheck_forcewake.c
URL   : https://patchwork.freedesktop.org/series/34614/
State : success

== Summary ==

Blacklisted hosts:
shard-hswtotal:2631 pass:1511 dwarn:2   dfail:0   fail:11  skip:1106 
time:s
shard-snbtotal:2562 pass:1254 dwarn:8   dfail:3   fail:7   skip:1287 
time:7071s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

[Imre Deak]

On Wed, Nov 29, 2017 at 10:59:27AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> It seems that the DMC likes to transition between the DC states a lot when
> there are no connected displays (no active power domains) during command
> submission.
> 
> This activity on DC states has a negative impact on the performance of the
> chip with huge latencies observed in the interrupt handlers and elsewhere.
> Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> eight.
> 
> Work around it by introducing a new power domain named,
> POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> held for the duration of command submission activity.
> 
> v2:
>  * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
>  * Protect macro body with braces. (Jani Nikula)
> 
> v3:
>  * Add dedicated power domain for clarity. (Chris, Imre)
>  * Commit message and comment text updates.
>  * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
>firmware release.
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> Testcase: igt/gem_exec_nop/headless
> Cc: Imre Deak 
> Acked-by: Chris Wilson 
> Cc: Chris Wilson 
> Cc: Dmitry Rogozhkin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  5 +
>  drivers/gpu/drm/i915/i915_gem.c |  4 
>  drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  4 
>  4 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..17340aadc566 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -398,6 +398,7 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_AUX_D,
>   POWER_DOMAIN_GMBUS,
>   POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_GT_IRQ,
>   POWER_DOMAIN_INIT,
>  
>   POWER_DOMAIN_NUM,
> @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define GT_FREQUENCY_MULTIPLIER 50
>  #define GEN9_FREQ_SCALER 3
>  
> +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> + (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
> + IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))

BXT and GLK seems to be also affected so IS_GEN9().

> +
>  #include "i915_trace.h"
>  
>  static inline bool intel_vtd_active(void)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 354b0546a191..feec2a621120 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct *work)
>  
>   if (INTEL_GEN(dev_priv) >= 6)
>   gen6_rps_idle(dev_priv);
> +
>   intel_runtime_pm_put(dev_priv);
> +
> + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
>  out_unlock:
>   mutex_unlock(_priv->drm.struct_mutex);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index a90bdd26571f..619377a05810 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -251,6 +251,20 @@ static void mark_busy(struct drm_i915_private *i915)
>  
>   GEM_BUG_ON(!i915->gt.active_requests);
>  
> + /*
> +  * It seems that the DMC likes to transition between the DC states a lot
> +  * when there are no connected displays (no active power domains) during
> +  * command submission.
> +  *
> +  * This activity has negative impact on the performance of the chip with
> +  * huge latencies observed in the interrupt handler and elsewhere.
> +  *
> +  * Work around it by grabbing a GT IRQ power domain whilst there is any
> +  * GT activity, preventing any DC state transitions.
> +  */
> + if (NEEDS_CSR_GT_PERF_WA(i915))
> + intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
> +
>   intel_runtime_pm_get_noresume(i915);
>   i915->gt.awake = true;
>  
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 8315499452dc..f491c7aaa096 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -130,6 +130,8 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain domain)
>   return "INIT";
>   case POWER_DOMAIN_MODESET:
>   return "MODESET";
> + case POWER_DOMAIN_GT_IRQ:
> + return "GT_IRQ";
>   default:
>   MISSING_CASE(domain);
>   return "?";
> @@ -1705,6 +1707,7 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>   BIT_ULL(POWER_DOMAIN_INIT))
>  #define 

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

[Imre Deak]

On Wed, Nov 29, 2017 at 11:59:04AM +, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2017-11-29 11:53:41)
> > 
> > On 29/11/2017 11:40, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2017-11-29 11:34:27)
> > >>
> > >> On 29/11/2017 11:12, Daniel Vetter wrote:
> > >>> I think given that DMC is strongly recommended there shouldn't be a real
> > >>> cost with making this unconditional.
> > >>
> > >> I don't know, not liking it on the first go. But then again I have no
> > >> idea how much power would that waste for use cases where DMC fw is
> > >> deliberately not present.
> > >>
> > >> Perhaps it would be acceptable to mark GT busy during the async CSR
> > >> load. Chris, any thoughts?
> > > 
> > > It's tightly coupled to requests, adding in an external call seems
> > > troublesome.
> > > 
> > > What's the reason for depending on the CSR being loaded? The old fw is
> > > broke no matter what, it doesn't get any more broken by us holding a
> > > powerwell wakeref. I think we should go for simplicity and always take
> > > the powerwell along with the rpm?
> > 
> > It's the unknown, maybe only for me, on how much power always holding 
> > the power well would waste for use cases where DMC firmware has been 
> > deliberately removed.
> > 
> > If I understand correctly that the Daniel's and your proposal is to just 
> > got with HAS_CSR as the wa/ criteria, instead of fw loaded check.
> 
> If I am reading the powerwell code correctly, it already takes the dmc
> fw into account. I would transfer the problem to there :) i.e. we have
> an unconditional call from gt:mark_busy, gt:mark_idle and the powerwell
> code knows what needs to be done under the different circumstances.

Yes, a power well ref for all domains is held while the firmware is
being loaded, or the firmware fails to load. So taking it
unconditionally is ok (not counting the platform check due to the
corruption issue).

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Add GuC support for engine busy stats

[Tvrtko Ursulin]

On 29/11/2017 13:30, Patchwork wrote:

== Series Details ==

Series: series starting with [1/2] drm/i915: Add GuC support for engine busy 
stats
URL   : https://patchwork.freedesktop.org/series/34617/
State : failure

== Summary ==

Series 34617v1 series starting with [1/2] drm/i915: Add GuC support for engine 
busy stats
https://patchwork.freedesktop.org/api/1.0/series/34617/revisions/1/mbox/

Test debugfs_test:
 Subgroup read_all_entries:
 pass   -> DMESG-WARN (fi-skl-6260u)
 pass   -> DMESG-WARN (fi-skl-6600u)
 pass   -> DMESG-WARN (fi-skl-6700hq)
 pass   -> DMESG-WARN (fi-skl-6700k)
 pass   -> DMESG-WARN (fi-skl-6770hq)
 pass   -> DMESG-WARN (fi-skl-gvtdvm)
 pass   -> DMESG-WARN (fi-bxt-dsi)
 pass   -> DMESG-WARN (fi-bxt-j4205)
 pass   -> DMESG-WARN (fi-kbl-7500u) fdo#103285
 pass   -> DMESG-WARN (fi-kbl-7560u)
 pass   -> DMESG-WARN (fi-kbl-7567u)
 pass   -> DMESG-WARN (fi-kbl-r)
 pass   -> DMESG-WARN (fi-glk-1)


Looks like another case of alloc_workqueue under struct_mutex in the GuC 
code. Anyone in the mood to untangle it? :)


Regards,

Tvrtko


Test gem_exec_suspend:
 Subgroup basic-s3:
 pass   -> INCOMPLETE (fi-skl-6260u)
 pass   -> INCOMPLETE (fi-skl-6600u)
 pass   -> INCOMPLETE (fi-skl-6700hq)
 pass   -> INCOMPLETE (fi-skl-6700k)
 pass   -> INCOMPLETE (fi-skl-6770hq)
 pass   -> INCOMPLETE (fi-skl-gvtdvm)
 pass   -> INCOMPLETE (fi-bxt-dsi)
 pass   -> INCOMPLETE (fi-bxt-j4205)
 pass   -> INCOMPLETE (fi-kbl-7500u)
 pass   -> INCOMPLETE (fi-kbl-7560u)
 pass   -> INCOMPLETE (fi-kbl-7567u)
 pass   -> INCOMPLETE (fi-kbl-r)
Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-b:
 pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:505s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:108  pass:94   dwarn:1   dfail:0   fail:0   skip:12
fi-bxt-j4205 total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:478s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:424s
fi-glk-1 total:288  pass:259  dwarn:1   dfail:0   fail:0   skip:28  
time:523s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:374s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:270s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-kbl-7500u total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11
fi-kbl-7560u total:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3
fi-kbl-7567u total:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3
fi-kbl-r total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3
fi-skl-6600u total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11
fi-skl-6700hqtotal:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11
fi-skl-6700k total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11
fi-skl-6770hqtotal:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3
fi-skl-gvtdvmtotal:108  pass:102  dwarn:1   dfail:0   fail:0   skip:4
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:418s
Blacklisted hosts:
fi-cfl-s2total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11
fi-cnl-y total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:24
fi-glk-dsi   total:288  pass:257  dwarn:1   dfail:0   fail:0   skip:30  
time:471s

0645c6db8ac8375db3cb9f6741cfccb671ad5a0c drm-tip: 2017y-11m-29d-12h-29m-51s UTC 
integration manifest
965fb47f5085 drm/i915: HACK enable GuC for testing
dbe7a687455e drm/i915: Add GuC support for engine busy stats

== Logs ==

For more details see: 

Re: [Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters

[Michal Wajdeczko]

On Wed, 29 Nov 2017 14:40:05 +0100, Sagar Arun Kamble  
 wrote:





On 11/29/2017 5:44 PM, Michal Wajdeczko wrote:
On Tue, 28 Nov 2017 11:41:57 +0100, Sagar Arun Kamble  
 wrote:





On 11/28/2017 1:24 AM, Sujaritha Sundaresan wrote:

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).






+
+/* Making sure that our auto is well defined */
+GEM_BUG_ON(auto_enable_guc < 0);
+GEM_BUG_ON((auto_enable_guc > 0) && !HAS_GUC_FW(dev_priv));
+GEM_BUG_ON((auto_enable_guc & 2) && !HAS_HUC_FW(dev_priv));
+
+if (i915_modparams.enable_guc < 0)
+i915_modparams.enable_guc = auto_enable_guc;
+
+if (i915_modparams.enable_guc > 0) {
+if (!HAS_GUC(dev_priv) || !HAS_GUC_FW(dev_priv)) {
+DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+ i915_modparams.enable_guc,
+ !HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+i915_modparams.enable_guc = 0;
+}
  }
  -/* A negative value means "use platform default" */
-if (i915_modparams.enable_guc_loading < 0)
-i915_modparams.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
-
-/* Verify firmware version */
-if (i915_modparams.enable_guc_loading) {
-if (HAS_HUC_UCODE(dev_priv))
-intel_huc_select_fw(_priv->huc);
-
-if (intel_guc_fw_select(_priv->guc))
-i915_modparams.enable_guc_loading = 0;
+if (i915_modparams.enable_guc & 2) {
+if (!HAS_HUC_FW(dev_priv)) {
+DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+i915_modparams.enable_guc, "no HuC firmware");
+i915_modparams.enable_guc = 0;
Clearing only HuC status from enable_guc would be proper I guess.  
Sorry I did not see this earlier.


My understanding is that if user had specified non-zero positive value  
of
'enable_guc' then it means that he requests *all* GuC options to be  
available
(something like our old '2=required' mode). If any of required option  
is not

available then we should not try to cherry-pick/drop single option.
I think we wanted to enable HuC for some platforms but not enable GuC  
submission. Anusha can you

please confirm if such cherry-picking is needed through module parameter.


Cherry-picking through module parameter is fine.
And at the same time we should treat them as mandatory options.

I was referring to cherry-picking (or more precisely droping) during call
to sanitize_options(). So when user specify guc_enable as 3(submission+huc)
we should not convert it into 2(submission only).



Note that if user don't care about specific option, then user should  
use -1(auto)
mode and rely on driver decision what is available and in which  
configuration.
And for 'auto' mode we try to make sure to do not select broken  
configurations.
In that case we can just have 3 values for enable_guc (if cherry-picking  
is not to be done)

-1: auto (whatever is available)
0: all disabled
1: all enabled if available else all disabled


Michal

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

[Intel-gfx] [PATCH v2] drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails

[Chris Wilson]

History tells us that if we cannot reset the GPU now, we never will. This
then impacts everything that is run subsequently. On failing the reset,
we mark the driver as wedged, trying to prevent further execution on the
GPU, forcing userspace to fallback to using the CPU to update its
framebuffers and let the user know what happened.

We also want to go one step further and add a taint to the kernel so that
any subsequent faults can be traced back to this failure. This is
important for igt, where if the GPU/driver fails we want to reboot and
restart testing rather than continue on into oblivion.

TAINT_DIE is colloquially known as "system on fire", which seems
appropriate for unresponsive hardware.

v2: Also taint if the recovery fails (again history shows us that is
typically fatal).

References: https://bugs.freedesktop.org/show_bug.cgi?id=103514
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Daniel Vetter 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_drv.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 696d5cdf2779..eb90ddac7f8b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1897,18 +1897,21 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
disable_irq(i915->drm.irq);
ret = i915_gem_reset_prepare(i915);
if (ret) {
-   DRM_ERROR("GPU recovery failed\n");
+   dev_err(i915->drm.dev, "GPU recovery failed\n");
intel_gpu_reset(i915, ALL_ENGINES);
-   goto error;
+   goto taint;
}
 
ret = intel_gpu_reset(i915, ALL_ENGINES);
if (ret) {
-   if (ret != -ENODEV)
-   DRM_ERROR("Failed to reset chip: %i\n", ret);
-   else
+   if (ret != -ENODEV) {
+   dev_err(i915->drm.dev,
+   "Failed to reset chip: %i\n", ret);
+   goto taint;
+   } else {
DRM_DEBUG_DRIVER("GPU reset disabled\n");
-   goto error;
+   goto error;
+   }
}
 
i915_gem_reset(i915);
@@ -1951,6 +1954,19 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
wake_up_bit(>flags, I915_RESET_HANDOFF);
return;
 
+taint:
+   /*
+* History tells us that if we cannot reset the GPU now, we
+* never will. This then impacts everything that is run
+* subsequently. On failing the reset, we mark the driver
+* as wedged, preventing further execution on the GPU.
+* We also want to go one step further and add a taint to the
+* kernel so that any subsequent faults can be traced back to
+* this failure. This is important for igt, where if the
+* GPU/driver fails we want to reboot and restart testing
+* rather than continue on into oblivion.
+*/
+   add_taint(TAINT_DIE, LOCKDEP_STILL_OK);
 error:
i915_gem_set_wedged(i915);
i915_gem_retire_requests(i915);
-- 
2.15.0

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

[Intel-gfx] [PATCH] drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails

[Chris Wilson]

History tells us that if we cannot reset the GPU now, we never will. This
then impacts everything that is run subsequently. On failing the reset,
we mark the driver as wedged, trying to prevent further execution on the
GPU, forcing userspace to fallback to using the CPU to update its
framebuffers and let the user know what happened.

We also want to go one step further and add a taint to the kernel so that
any subsequent faults can be traced back to this failure. This is
important for igt, where if the GPU/driver fails we want to reboot and
restart testing rather than continue on into oblivion.

TAINT_DIE is colloquially known as "system on fire", which seems
appropriate for unresponsive hardware.

References: https://bugs.freedesktop.org/show_bug.cgi?id=103514
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Daniel Vetter 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_drv.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 696d5cdf2779..f08343be880c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1904,10 +1904,24 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
 
ret = intel_gpu_reset(i915, ALL_ENGINES);
if (ret) {
-   if (ret != -ENODEV)
-   DRM_ERROR("Failed to reset chip: %i\n", ret);
-   else
+   /*
+* History tells us that if we cannot reset the GPU now, we
+* never will. This then impacts everything that is run
+* subsequently. On failing the reset, we mark the driver
+* as wedged, preventing further execution on the GPU.
+* We also want to go one step further and add a taint to the
+* kernel so that any subsequent faults can be traced back to
+* this failure. This is important for igt, where if the
+* GPU/driver fails we want to reboot and restart testing
+* rather than continue on into oblivion.
+*/
+   if (ret != -ENODEV) {
+   dev_err(i915->drm.dev,
+   "Failed to reset chip: %i\n", ret);
+   add_taint(TAINT_DIE, LOCKDEP_STILL_OK);
+   } else {
DRM_DEBUG_DRIVER("GPU reset disabled\n");
+   }
goto error;
}
 
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add RGB565 90 degree test for gen>9

[Juha-Pekka Heikkila]

On 28.11.2017 13:53, Maarten Lankhorst wrote:

Hey,

Op 21-11-17 om 15:02 schreef Juha-Pekka Heikkila:

Gen10 onwards 90 and 270 degree rotations are supported for RGB565 format.

v2 (Ville Syrjälä):
As a side effect to keep bad-pixel-format test valid on all supported
platforms it need to use DRM_FORMAT_C8 now.

While at it clean up kms_rotation_crc test a bit, take out
test_plane_rotation_ytiled_obj() function as
test_plane_rotation() can basically do the same.

v3 (Ville Syrjälä):
repurpose test_plane_rotation_ytiled_obj() function for
bad pixel testing with DRM_FORMAT_C8 as igt doesn't
support this format.

Signed-off-by: Juha-Pekka Heikkila 

At this point there is no correct order to apply the tests then.

What I would like to see is the bad-pixel-format changes in a separate commit, 
so we can commit that first, and then commit kernel change, watch CI results 
for regressions and then add the new IGT test..

With that fixed the patches can be applied. :)



Hei, thanks for the comment Maarten. I'll make the change and add you as 
cc once done. :)


/Juha-Pekka

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

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Chris Wilson]

Quoting Chris Wilson (2017-11-29 12:30:23)
> +static const struct kernel_taint {
> +   const char *msg;
> +   unsigned int flags;
> +} taints[] = {
> +   { "Non-GPL module loaded" },
> +   { "Forced module load" },
> +   { "Unsafe SMP processor" },
> +   { "Forced module unload" },
> +   { "Machine Check Exception", TAINT_WARN },
> +   { "Bad page detected", TAINT_ERROR },
> +   { "Tainted by user request", TAINT_WARN },
> +   { "System is on fire", TAINT_ERROR },
> +   { "ACPI DSDT has been overridden by user" },
> +   { "OOPS", TAINT_ERROR },
> +   { "Staging driver loaded; are you mad?" },
> +   { "Severe firmware bug workaround active", TAINT_WARN },
> +   { "Out-of-tree module loaded" },
> +   { "Unsigned module loaded" },
> +   { "Soft-lockup detected", TAINT_WARN },
> +   { "Kernel has been live patched" },

There's now also TAINT_AUX, which is unused in the kernel.
{ "Some other reason!" }

Maybe should also add
const char *name;
for "AUX" etc.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters

[Sagar Arun Kamble]

On 11/29/2017 5:44 PM, Michal Wajdeczko wrote:
On Tue, 28 Nov 2017 11:41:57 +0100, Sagar Arun Kamble 
 wrote:





On 11/28/2017 1:24 AM, Sujaritha Sundaresan wrote:

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).






+
+    /* Making sure that our auto is well defined */
+    GEM_BUG_ON(auto_enable_guc < 0);
+    GEM_BUG_ON((auto_enable_guc > 0) && !HAS_GUC_FW(dev_priv));
+    GEM_BUG_ON((auto_enable_guc & 2) && !HAS_HUC_FW(dev_priv));
+
+    if (i915_modparams.enable_guc < 0)
+    i915_modparams.enable_guc = auto_enable_guc;
+
+    if (i915_modparams.enable_guc > 0) {
+    if (!HAS_GUC(dev_priv) || !HAS_GUC_FW(dev_priv)) {
+    DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+ i915_modparams.enable_guc,
+ !HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+    i915_modparams.enable_guc = 0;
+    }
  }
  -    /* A negative value means "use platform default" */
-    if (i915_modparams.enable_guc_loading < 0)
-    i915_modparams.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
-
-    /* Verify firmware version */
-    if (i915_modparams.enable_guc_loading) {
-    if (HAS_HUC_UCODE(dev_priv))
-    intel_huc_select_fw(_priv->huc);
-
-    if (intel_guc_fw_select(_priv->guc))
-    i915_modparams.enable_guc_loading = 0;
+    if (i915_modparams.enable_guc & 2) {
+    if (!HAS_HUC_FW(dev_priv)) {
+    DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+    i915_modparams.enable_guc, "no HuC firmware");
+    i915_modparams.enable_guc = 0;
Clearing only HuC status from enable_guc would be proper I guess. 
Sorry I did not see this earlier.


My understanding is that if user had specified non-zero positive value of
'enable_guc' then it means that he requests *all* GuC options to be 
available
(something like our old '2=required' mode). If any of required option 
is not

available then we should not try to cherry-pick/drop single option.
I think we wanted to enable HuC for some platforms but not enable GuC 
submission. Anusha can you

please confirm if such cherry-picking is needed through module parameter.


Note that if user don't care about specific option, then user should 
use -1(auto)
mode and rely on driver decision what is available and in which 
configuration.
And for 'auto' mode we try to make sure to do not select broken 
configurations.
In that case we can just have 3 values for enable_guc (if cherry-picking 
is not to be done)

-1: auto (whatever is available)
0: all disabled
1: all enabled if available else all disabled


Michal


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Add GuC support for engine busy stats

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Add GuC support for engine busy 
stats
URL   : https://patchwork.freedesktop.org/series/34617/
State : failure

== Summary ==

Series 34617v1 series starting with [1/2] drm/i915: Add GuC support for engine 
busy stats
https://patchwork.freedesktop.org/api/1.0/series/34617/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u) fdo#103285
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-skl-6600u)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-skl-6700k)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-skl-gvtdvm)
pass   -> INCOMPLETE (fi-bxt-dsi)
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-kbl-7560u)
pass   -> INCOMPLETE (fi-kbl-7567u)
pass   -> INCOMPLETE (fi-kbl-r)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:505s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:108  pass:94   dwarn:1   dfail:0   fail:0   skip:12 
fi-bxt-j4205 total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11 
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:478s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:424s
fi-glk-1 total:288  pass:259  dwarn:1   dfail:0   fail:0   skip:28  
time:523s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:374s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:270s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-kbl-7500u total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11 
fi-kbl-7560u total:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3  
fi-kbl-7567u total:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3  
fi-kbl-r total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11 
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3  
fi-skl-6600u total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11 
fi-skl-6700hqtotal:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11 
fi-skl-6700k total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11 
fi-skl-6770hqtotal:108  pass:103  dwarn:1   dfail:0   fail:0   skip:3  
fi-skl-gvtdvmtotal:108  pass:102  dwarn:1   dfail:0   fail:0   skip:4  
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:418s
Blacklisted hosts:
fi-cfl-s2total:108  pass:95   dwarn:1   dfail:0   fail:0   skip:11 
fi-cnl-y total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:24 
fi-glk-dsi   total:288  pass:257  dwarn:1   dfail:0   fail:0   skip:30  
time:471s

0645c6db8ac8375db3cb9f6741cfccb671ad5a0c drm-tip: 2017y-11m-29d-12h-29m-51s UTC 
integration manifest
965fb47f5085 drm/i915: HACK enable GuC for testing
dbe7a687455e drm/i915: Add GuC support for engine busy stats

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with lockdep: finer-grained completion key for kthread (rev2)

[Patchwork]

== Series Details ==

Series: series starting with lockdep: finer-grained completion key for kthread 
(rev2)
URL   : https://patchwork.freedesktop.org/series/34603/
State : success

== Summary ==

Blacklisted hosts:
shard-apltotal:2476 pass:1560 dwarn:10  dfail:8   fail:14  skip:879 
time:12836s
shard-hswtotal:2661 pass:1534 dwarn:1   dfail:0   fail:9   skip:1117 
time:9575s
shard-kbltotal:2448 pass:1601 dwarn:49  dfail:11  fail:17  skip:764 
time:9121s
shard-snbtotal:2539 pass:1236 dwarn:8   dfail:8   fail:6   skip:1277 
time:7128s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 1/2] igt: Remove Android support

[Szwichtenberg, Radoslaw]

On Fri, 2017-11-24 at 17:17 +0200, Arkadiusz Hiler wrote:
> This patch gets rid of the Android support, deleting all the hacks and
> moving code around to the places it belongs.
> 
> Android build is not really maintained properly and rots rather fast.
> With recent push for Meson here and Android going for Soong it will only
> accelerate.
> 
> It's a good time to drop the illusion of providing any support.
> 
> Cc: Daniel Vetter 
> Cc: Kalyan Kondapally 
> Cc: Petri Latvala 
> Cc: Radoslaw Szwichtenberg 
> Signed-off-by: Arkadiusz Hiler 
Reviewed-by: Radoslaw Szwichtenberg 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/2] Revert "lib/igt_aux: Make procps optional"

[Arkadiusz Hiler]

On Wed, Nov 29, 2017 at 12:07:06PM +0100, Daniel Vetter wrote:
> On Fri, Nov 24, 2017 at 05:17:48PM +0200, Arkadiusz Hiler wrote:
> > This reverts commit d7d3f4e87b827152f00bdf89a67871736672b492
> > and gets rid of the config option from the meson.build.
> > 
> > It was needed only for the Android support.
> > 
> > Signed-off-by: Arkadiusz Hiler 
> 
> Acked-by: Daniel Vetter 
> 
> on both patches.
> 
> I think there's a bunch more things that are only optional because of
> Android. Stuff like udev and glib iirc. But maybe we want to keep those,
> to avoid to much pain for the next time around someone wants to implement
> Android support natively.
> -Daniel

Pushed, thanks for Acks and R-bs!

As of further cleanups, there is one really impending on us
- the libunwind one.

We have huge sections of the code wrapped in ifdefs which bit us more
than once - it's easy to misplace code in there, code that should always
be compiled.

This needs a rework, initial ideas is to put all the unwind related mess
into separate file and compile the whole thing conditionally - for
clearer separation.

We would also need "fallback" noop implementation of some of those
functions.

Or we may ask ourself, with Android support gone, is this really worth
it and shouldn't we make libunwind non-optional and just get rid of the
preprocessor macors? :-)

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

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Chris Wilson]

Quoting Szwichtenberg, Radoslaw (2017-11-29 13:14:52)
> On Wed, 2017-11-29 at 12:40 +, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-11-29 12:30:23)
> > > Checking for a tainted kernel is a convenient way to see if the test
> > > generated a critical error such as a oops, or machine check.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > > Cc: Radoslaw Szwichtenberg 
> > > ---
> > > diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
> > > new file mode 100644
> > > index ..86d9cd20
> > > --- /dev/null
> > > +++ b/lib/igt_kernel_taint.c
> > > @@ -0,0 +1,95 @@
> > > +/*
> > > + * Copyright 2017 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a
> > > + * copy of this software and associated documentation files (the
> > > "Software"),
> > > + * to deal in the Software without restriction, including without
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the
> > > next
> > > + * paragraph) shall be included in all copies or substantial portions of
> > > the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS
> > > OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > > OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > > DEALINGS
> > > + * IN THE SOFTWARE.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include "igt.h"
> > > +#include "igt_kernel_taint.h"
> > > +#include "igt_sysfs.h"
> > > +
> > > +#define BIT(x) (1ul << (x))
> > > +
> > > +static const struct kernel_taint {
> > > +   const char *msg;
> > > +   unsigned int flags;
> > > +} taints[] = {
> > > +   { "Non-GPL module loaded" },
> > > +   { "Forced module load" },
> > > +   { "Unsafe SMP processor" },
> > > +   { "Forced module unload" },
> > > +   { "Machine Check Exception", TAINT_WARN },
> > > +   { "Bad page detected", TAINT_ERROR },
> > > +   { "Tainted by user request", TAINT_WARN },
> > 
> > Since unsafe modparams generate these and we are still using them
> > extensively, we should probably ignore this one.
> > 
> > > +   { "System is on fire", TAINT_ERROR },
> > > +   { "ACPI DSDT has been overridden by user" },
> > > +   { "OOPS", TAINT_ERROR },
> > > +   { "Staging driver loaded; are you mad?" },
> > > +   { "Severe firmware bug workaround active", TAINT_WARN },
> > > +   { "Out-of-tree module loaded" },
> > > +   { "Unsigned module loaded" },
> > > +   { "Soft-lockup detected", TAINT_WARN },
> > > +   { "Kernel has been live patched" },
> > > +};
> > > +
> > > +unsigned long igt_read_kernel_taint(void)
> > 
> > One thing I haven't checked is whether we can clear the kernel taints.
> > At the moment, once we see an oops, we never report a second test
> > generating another oops.
> > -Chris
> 
> I guess that clearing kernel taints is not needed when you hit oops - you
> probably should stop executing tests and reboot the machine, right?

Oops in the driver tends to stop igt pretty hard. A good rule of thumb
is indeed to abandon all hope and reboot. I'm thinking that with this
sort of early-warning detection in place, we can use the kernel_taint
when we do detect a persistent error, e.g. abandon the run if one flip
times out, or if we fail to park or reset the GPU. All to make that
catastrophic error stand out and not pollute other test results.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Szwichtenberg, Radoslaw]

On Wed, 2017-11-29 at 12:40 +, Chris Wilson wrote:
> Quoting Chris Wilson (2017-11-29 12:30:23)
> > Checking for a tainted kernel is a convenient way to see if the test
> > generated a critical error such as a oops, or machine check.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> > Cc: Radoslaw Szwichtenberg 
> > ---
> > diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
> > new file mode 100644
> > index ..86d9cd20
> > --- /dev/null
> > +++ b/lib/igt_kernel_taint.c
> > @@ -0,0 +1,95 @@
> > +/*
> > + * Copyright 2017 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the
> > next
> > + * paragraph) shall be included in all copies or substantial portions of
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include "igt.h"
> > +#include "igt_kernel_taint.h"
> > +#include "igt_sysfs.h"
> > +
> > +#define BIT(x) (1ul << (x))
> > +
> > +static const struct kernel_taint {
> > +   const char *msg;
> > +   unsigned int flags;
> > +} taints[] = {
> > +   { "Non-GPL module loaded" },
> > +   { "Forced module load" },
> > +   { "Unsafe SMP processor" },
> > +   { "Forced module unload" },
> > +   { "Machine Check Exception", TAINT_WARN },
> > +   { "Bad page detected", TAINT_ERROR },
> > +   { "Tainted by user request", TAINT_WARN },
> 
> Since unsafe modparams generate these and we are still using them
> extensively, we should probably ignore this one.
> 
> > +   { "System is on fire", TAINT_ERROR },
> > +   { "ACPI DSDT has been overridden by user" },
> > +   { "OOPS", TAINT_ERROR },
> > +   { "Staging driver loaded; are you mad?" },
> > +   { "Severe firmware bug workaround active", TAINT_WARN },
> > +   { "Out-of-tree module loaded" },
> > +   { "Unsigned module loaded" },
> > +   { "Soft-lockup detected", TAINT_WARN },
> > +   { "Kernel has been live patched" },
> > +};
> > +
> > +unsigned long igt_read_kernel_taint(void)
> 
> One thing I haven't checked is whether we can clear the kernel taints.
> At the moment, once we see an oops, we never report a second test
> generating another oops.
> -Chris

I guess that clearing kernel taints is not needed when you hit oops - you
probably should stop executing tests and reboot the machine, right?

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

[Intel-gfx] [PATCH i-g-t] meson: build a full dependency for lib_igt_perf

[Daniel Vetter]

meson prefers packages dependencies over passing arount static
libraries, because those also include linker flags, include dirs and
everything else.

While at it pull the special cases out from the common build stanzas
like we do with other special cases.

Just a bit of ocd to keep everything polished.

Cc: Tvrtko Ursulin 
Signed-off-by: Daniel Vetter 
---
 benchmarks/meson.build |  9 +++--
 lib/meson.build|  5 -
 overlay/meson.build|  4 ++--
 tests/meson.build  | 11 +--
 4 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/benchmarks/meson.build b/benchmarks/meson.build
index fa7f07643a97..4afd204f82b2 100644
--- a/benchmarks/meson.build
+++ b/benchmarks/meson.build
@@ -12,7 +12,6 @@ benchmark_progs = [
'gem_prw',
'gem_set_domain',
'gem_syslatency',
-   'gem_wsim',
'kms_vblank',
'prime_lookup',
'vgem_mmap',
@@ -31,11 +30,9 @@ endif
 foreach prog : benchmark_progs
# FIXME meson doesn't like binaries with the same name
# meanwhile just suffix with _bench
-   link = []
-   if prog == 'gem_wsim'
-   link += lib_igt_perf
-   endif
executable(prog + '_bench', prog + '.c',
-  link_with : link,
   dependencies : test_deps)
 endforeach
+
+executable('gem_wsim_bench', 'gem_wsim.c',
+  dependencies : test_deps + [ lib_igt_perf ])
diff --git a/lib/meson.build b/lib/meson.build
index 29d89cf09b58..d06d85b438b2 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -180,8 +180,11 @@ lib_igt = declare_dependency(link_with : lib_igt_build,
 
 igt_deps = [ lib_igt ] + lib_deps
 
-lib_igt_perf = static_library('igt_perf',
+lib_igt_perf_build = static_library('igt_perf',
['igt_perf.c']
 )
 
+lib_igt_perf = declare_dependency(link_with : lib_igt_perf_build,
+ include_directories : inc)
+
 subdir('tests')
diff --git a/overlay/meson.build b/overlay/meson.build
index 6b479eb89890..afacff5ecf60 100644
--- a/overlay/meson.build
+++ b/overlay/meson.build
@@ -21,7 +21,8 @@ dri2proto = dependency('dri2proto', version : '>= 2.6', 
required : false)
 cairo_xlib = dependency('cairo-xlib', required : false)
 xrandr = dependency('xrandr', version : '>=1.3', required : false)
 
-gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm, libdrm_intel ]
+gpu_overlay_deps = [ realtime, math, cairo, pciaccess, libdrm,
+   libdrm_intel, lib_igt_perf ]
 
 both_x11_src = ''
 
@@ -55,6 +56,5 @@ if xrandr.found() and cairo.found()
include_directories : inc,
c_args : gpu_overlay_cflags,
dependencies : gpu_overlay_deps,
-   link_with : lib_igt_perf,
install : true)
 endif
diff --git a/tests/meson.build b/tests/meson.build
index 088c37ec9b15..58fe0b0557a3 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -193,7 +193,6 @@ test_progs = [
'kms_vblank',
'meta_test',
'perf',
-   'perf_pmu',
'pm_backlight',
'pm_lpsp',
'pm_rc6_residency',
@@ -263,17 +262,17 @@ libexecdir = join_paths(get_option('prefix'), 
get_option('libexecdir'), 'intel-g
 test_executables = []
 
 foreach prog : test_progs
-   link = []
-   if prog == 'perf_pmu'
-   link += lib_igt_perf
-   endif
test_executables += executable(prog, prog + '.c',
   dependencies : test_deps,
   install_dir : libexecdir,
-  link_with : link,
   install : true)
 endforeach
 
+test_executables += executable('perf_pmu', 'perf_pmu.c',
+  dependencies : test_deps + [ lib_igt_perf ],
+  install_dir : libexecdir,
+  install : true)
+
 executable('testdisplay', ['testdisplay.c', 'testdisplay_hotplug.c'],
   dependencies : test_deps,
   install_dir : libexecdir,
-- 
2.15.0

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] lib: avoid < in gtkdoc comments

[Patchwork]

== Series Details ==

Series: series starting with [1/2] lib: avoid < in gtkdoc comments
URL   : https://patchwork.freedesktop.org/series/34609/
State : success

== Summary ==

Blacklisted hosts:
shard-apltotal:2452 pass:1519 dwarn:28  dfail:15  fail:9   skip:877 
time:12292s
shard-hswtotal:2650 pass:1518 dwarn:8   dfail:0   fail:10  skip:1113 
time:9009s
shard-kbltotal:2293 pass:1455 dwarn:90  dfail:12  fail:13  skip:715 
time:8063s
shard-snbtotal:2576 pass:1253 dwarn:16  dfail:4   fail:8   skip:1293 
time:6763s

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Fix deadlock in i830_disable_pipe()

[Ville Syrjala]

From: Ville Syrjälä 

i830_disable_pipe() gets called from the power well code, and thus
we're already holding the power domain mutex. That means we can't
call plane->get_hw_state() as it will also try to grab the
same mutex and will thus deadlock.

Replace the assert_plane() calls (which calls ->get_hw_state()) with
just raw register reads in i830_disable_pipe(). As a bonus we can
now get a warning if plane C is enabled even though we don't even
expose it as a drm plane.

v2: Do a separate WARN_ON() for each plane (Chris)

Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
Fixes: 51f5a0963984 ("drm/i915: Add .get_hw_state() method for planes")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d67c7c498b34..674b86bbe7d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14731,8 +14731,11 @@ void i830_disable_pipe(struct drm_i915_private 
*dev_priv, enum pipe pipe)
DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
  pipe_name(pipe));
 
-   assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_A));
-   assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_B));
+   WARN_ON(I915_READ(DSPCNTR(PLANE_A)) & DISPLAY_PLANE_ENABLE);
+   WARN_ON(I915_READ(DSPCNTR(PLANE_B)) & DISPLAY_PLANE_ENABLE);
+   WARN_ON(I915_READ(DSPCNTR(PLANE_C)) & DISPLAY_PLANE_ENABLE);
+   WARN_ON(I915_READ(CURCNTR(PIPE_A)) & CURSOR_MODE);
+   WARN_ON(I915_READ(CURCNTR(PIPE_B)) & CURSOR_MODE);
 
I915_WRITE(PIPECONF(pipe), 0);
POSTING_READ(PIPECONF(pipe));
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix deadlock in i830_disable_pipe()

[Ville Syrjälä]

On Tue, Nov 28, 2017 at 09:05:00PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-28 15:48:53)
> > From: Ville Syrjälä 
> > 
> > i830_disable_pipe() gets called from the power well code, and thus
> > we're already holding the power domain mutex. That means we can't
> > call plane->get_hw_state() as it will also try to grab the
> > same mutex and will thus deadlock.
> > 
> > Replace the assert_plane() calls (which calls ->get_hw_state()) with
> > just raw register reads in i830_disable_pipe(). As a bonus we can
> > now get a warning if plane C is enabled even though we don't even
> > expose it as a drm plane.
> > 
> > Fixes: 51f5a0963984 ("drm/i915: Add .get_hw_state() method for planes")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d67c7c498b34..48d9332b196f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14731,8 +14731,11 @@ void i830_disable_pipe(struct drm_i915_private 
> > *dev_priv, enum pipe pipe)
> > DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
> >   pipe_name(pipe));
> >  
> > -   assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_A));
> > -   assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_B));
> > +   WARN_ON(I915_READ(DSPCNTR(PLANE_A)) & DISPLAY_PLANE_ENABLE ||
> > +   I915_READ(DSPCNTR(PLANE_B)) & DISPLAY_PLANE_ENABLE ||
> > +   I915_READ(DSPCNTR(PLANE_C)) & DISPLAY_PLANE_ENABLE ||
> > +   I915_READ(CURCNTR(PIPE_A)) & CURSOR_MODE ||
> > +   I915_READ(CURCNTR(PIPE_B)) & CURSOR_MODE);
> 
> Ok. Avoiding mutex recursion sounds sensible, but a recursion sounds
> like a layering violation. i830_disable_pipe is only used by the
> powerwell, and I guess you could make the i830_enable_pipe in
> i9xx_crtc_disable into a call to the powerdomain instead.

That wouldn't actully work. We already hold the power domain
reference so the power well enable hook wouldn't even be called,
and even if it was it would just be a nop as the pipe is already
up and running.

I guess it would be possible to redesign that stuff somehow to do what
we want, but that probably means we'd have to redesign the power domain
initialization as well to never call the enable hook if the power well
is already active on boot.

So this would involve a bunch of work, and I can't actually see any
benefit from taking a detour through the power well code.

> 
> That sounds like more work than desired to fix the immediate problem!
> 
> However, I think you will miss the loss in precision by putting all the
> checks into one WARN_ON. If it either fires, we've no idea what went
> wrong?
> 
> Would it be worth just making each of those a separate WARN_ON()? I
> think so.

Yeah, I guess having that extra bit of information might be somewhat
helpful. I'll split it up.

> 
> Either way, I've checked that your explanation matches the code...
> Reviewed-by: Chris Wilson 

Thanks.

> -Chris

-- 
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: Restore GT performance in headless mode with DMC loaded

[Daniel Vetter]

On Wed, Nov 29, 2017 at 11:34:27AM +, Tvrtko Ursulin wrote:
> 
> On 29/11/2017 11:12, Daniel Vetter wrote:
> > On Wed, Nov 29, 2017 at 10:59:27AM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > It seems that the DMC likes to transition between the DC states a lot when
> > > there are no connected displays (no active power domains) during command
> > > submission.
> > > 
> > > This activity on DC states has a negative impact on the performance of the
> > > chip with huge latencies observed in the interrupt handlers and elsewhere.
> > > Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> > > eight.
> > > 
> > > Work around it by introducing a new power domain named,
> > > POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> > > held for the duration of command submission activity.
> > > 
> > > v2:
> > >   * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> > >   * Protect macro body with braces. (Jani Nikula)
> > > 
> > > v3:
> > >   * Add dedicated power domain for clarity. (Chris, Imre)
> > >   * Commit message and comment text updates.
> > >   * Apply to all big-core GEN9 parts apart for Skylake which is pending 
> > > DMC
> > > firmware release.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> > > Testcase: igt/gem_exec_nop/headless
> > > Cc: Imre Deak 
> > > Acked-by: Chris Wilson 
> > > Cc: Chris Wilson 
> > > Cc: Dmitry Rogozhkin 
> > > ---
> > >   drivers/gpu/drm/i915/i915_drv.h |  5 +
> > >   drivers/gpu/drm/i915/i915_gem.c |  4 
> > >   drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> > >   drivers/gpu/drm/i915/intel_runtime_pm.c |  4 
> > >   4 files changed, 27 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index bddd65839f60..17340aadc566 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> > >   POWER_DOMAIN_AUX_D,
> > >   POWER_DOMAIN_GMBUS,
> > >   POWER_DOMAIN_MODESET,
> > > + POWER_DOMAIN_GT_IRQ,
> > >   POWER_DOMAIN_INIT,
> > >   POWER_DOMAIN_NUM,
> > > @@ -3285,6 +3286,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> > >   #define GT_FREQUENCY_MULTIPLIER 50
> > >   #define GEN9_FREQ_SCALER 3
> > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > + (HAS_CSR(dev_priv) && (dev_priv)->csr.dmc_payload && \
> > 
> > Doesn't this check race with the async dmc loading? I.e. when you submit
> > something right at boot-up, before DMC is fully loaded, we might end up
> > with an unbalanced pm refcount.
> 
> Oh yeah, well spotted.
> 
> > I think given that DMC is strongly recommended there shouldn't be a real
> > cost with making this unconditional.
> 
> I don't know, not liking it on the first go. But then again I have no idea
> how much power would that waste for use cases where DMC fw is deliberately
> not present.
> 
> Perhaps it would be acceptable to mark GT busy during the async CSR load.
> Chris, any thoughts?

I only meant that we pm_put without pm_get (because when we would have
called pm_get dmc_payload == NULL and then != NULL when we reach the check
for pm_put).

The actual get/put vs. dmc loading should be protected already by the
async dmc load code holding pm references to prevent any havoc.
-Daniel

> 
> Regards,
> 
> Tvrtko
> 
> > With that changed:
> > 
> > Reviewed-by: Daniel Vetter 
> > 
> > > + IS_GEN9_BC(dev_priv) && !IS_SKYLAKE(dev_priv))
> > > +
> > >   #include "i915_trace.h"
> > >   static inline bool intel_vtd_active(void)
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 354b0546a191..feec2a621120 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3381,7 +3381,11 @@ i915_gem_idle_work_handler(struct work_struct 
> > > *work)
> > >   if (INTEL_GEN(dev_priv) >= 6)
> > >   gen6_rps_idle(dev_priv);
> > > +
> > >   intel_runtime_pm_put(dev_priv);
> > > +
> > > + if (NEEDS_CSR_GT_PERF_WA(dev_priv))
> > > + intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> > >   out_unlock:
> > >   mutex_unlock(_priv->drm.struct_mutex);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > > b/drivers/gpu/drm/i915/i915_gem_request.c
> > > index a90bdd26571f..619377a05810 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > > @@ -251,6 +251,20 @@ static void mark_busy(struct drm_i915_private *i915)
> > >   GEM_BUG_ON(!i915->gt.active_requests);
> > > + /*
> > > +  * It 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop gem_hangcheck_forcewake.c

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] tests/gem_hangcheck_forcewake: Drop 
gem_hangcheck_forcewake.c
URL   : https://patchwork.freedesktop.org/series/34614/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
380cc811486ba3fefbe3ebe4761afa7e169dcd3e tests/perf_pmu: Sync invalid-init with 
i915 changes

with latest DRM-Tip kernel build CI_DRM_3405
22153f2e9d4d drm-tip: 2017y-11m-29d-11h-53m-01s UTC integration manifest

Testlist changes:
-igt@gem_hangcheck_forcewake
-igt@gem_pin
-igt@gem_seqno_wrap

Test kms_frontbuffer_tracking:
Subgroup basic:
incomplete -> PASS   (fi-skl-6700k) fdo#103735
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:387s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:517s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:493s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:423s
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:268s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:382s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:436s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:490s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:527s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:542s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:512s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:452s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:420s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:613s
fi-cnl-y total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:556s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s

== Logs ==

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

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Chris Wilson]

Quoting Chris Wilson (2017-11-29 12:30:23)
> Checking for a tainted kernel is a convenient way to see if the test
> generated a critical error such as a oops, or machine check.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Radoslaw Szwichtenberg 
> ---
> diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
> new file mode 100644
> index ..86d9cd20
> --- /dev/null
> +++ b/lib/igt_kernel_taint.c
> @@ -0,0 +1,95 @@
> +/*
> + * Copyright 2017 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +
> +#include "igt.h"
> +#include "igt_kernel_taint.h"
> +#include "igt_sysfs.h"
> +
> +#define BIT(x) (1ul << (x))
> +
> +static const struct kernel_taint {
> +   const char *msg;
> +   unsigned int flags;
> +} taints[] = {
> +   { "Non-GPL module loaded" },
> +   { "Forced module load" },
> +   { "Unsafe SMP processor" },
> +   { "Forced module unload" },
> +   { "Machine Check Exception", TAINT_WARN },
> +   { "Bad page detected", TAINT_ERROR },
> +   { "Tainted by user request", TAINT_WARN },

Since unsafe modparams generate these and we are still using them
extensively, we should probably ignore this one.

> +   { "System is on fire", TAINT_ERROR },
> +   { "ACPI DSDT has been overridden by user" },
> +   { "OOPS", TAINT_ERROR },
> +   { "Staging driver loaded; are you mad?" },
> +   { "Severe firmware bug workaround active", TAINT_WARN },
> +   { "Out-of-tree module loaded" },
> +   { "Unsigned module loaded" },
> +   { "Soft-lockup detected", TAINT_WARN },
> +   { "Kernel has been live patched" },
> +};
> +
> +unsigned long igt_read_kernel_taint(void)

One thing I haven't checked is whether we can clear the kernel taints.
At the moment, once we see an oops, we never report a second test
generating another oops.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Add GuC support for engine busy stats

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Wire up the engine busy stats accounting to the GuC submission backend.

Since there is not context out interrupt we need to place the accounting
callbacks per-request in order to correctly pair with user interrupts.

v2: Rebase.
v3: Commit update.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 912ff143d531..d80d2a3214da 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -781,6 +781,7 @@ static void guc_dequeue(struct intel_engine_cs *engine)
INIT_LIST_HEAD(>priotree.link);
 
__i915_gem_request_submit(rq);
+   intel_engine_context_in(rq->engine);
trace_i915_gem_request_in(rq,
  port_index(port, execlists));
last = rq;
@@ -813,6 +814,7 @@ static void guc_submission_tasklet(unsigned long data)
 
rq = port_request([0]);
while (rq && i915_gem_request_completed(rq)) {
+   intel_engine_context_out(rq->engine);
trace_i915_gem_request_out(rq);
i915_gem_request_put(rq);
 
@@ -1453,8 +1455,6 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
-
-   engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
 
return 0;
-- 
2.14.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: HACK enable GuC for testing

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_params.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 8321bd86cba5..69ee2484c6bb 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -42,8 +42,8 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc_loading, 0) \
-   param(int, enable_guc_submission, 0) \
+   param(int, enable_guc_loading, 1) \
+   param(int, enable_guc_submission, 1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.14.1

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

[Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

[Chris Wilson]

Checking for a tainted kernel is a convenient way to see if the test
generated a critical error such as a oops, or machine check.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Radoslaw Szwichtenberg 
---
 lib/Makefile.sources   |  2 ++
 lib/igt_core.c | 19 +-
 lib/igt_kernel_taint.c | 95 ++
 lib/igt_kernel_taint.h | 34 ++
 4 files changed, 149 insertions(+), 1 deletion(-)
 create mode 100644 lib/igt_kernel_taint.c
 create mode 100644 lib/igt_kernel_taint.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6e968d9f..15215390 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -22,6 +22,8 @@ lib_source_list = \
igt_gt.h\
igt_gvt.c   \
igt_gvt.h   \
+   igt_kernel_taint.c  \
+   igt_kernel_taint.h  \
igt_primes.c\
igt_primes.h\
igt_rand.c  \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 6ce83bec..7e656323 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -63,6 +63,7 @@
 #include "intel_chipset.h"
 #include "intel_io.h"
 #include "igt_debugfs.h"
+#include "igt_kernel_taint.h"
 #include "version.h"
 #include "config.h"
 
@@ -258,6 +259,7 @@ static bool list_subtests = false;
 static char *run_single_subtest = NULL;
 static bool run_single_subtest_found = false;
 static const char *in_subtest = NULL;
+static unsigned long saved_kernel_taint;
 static struct timespec subtest_time;
 static clockid_t igt_clock = (clockid_t)-1;
 static bool in_fixture = false;
@@ -1002,6 +1004,8 @@ bool __igt_run_subtest(const char *subtest_name)
return false;
}
 
+   saved_kernel_taint = igt_read_kernel_taint();
+
kmsg(KERN_INFO "[IGT] %s: starting subtest %s\n", command_str, 
subtest_name);
igt_debug("Starting subtest: %s\n", subtest_name);
 
@@ -1148,8 +1152,21 @@ void __igt_skip_check(const char *file, const int line,
 void igt_success(void)
 {
succeeded_one = true;
-   if (in_subtest)
+   if (in_subtest) {
+   unsigned long new_kernel_taints =
+   igt_read_kernel_taint() & ~saved_kernel_taint;
+   unsigned int tainted = igt_kernel_tainted(new_kernel_taints);
+
+   if (tainted) {
+   igt_kernel_taint_print(new_kernel_taints);
+   if (tainted & TAINT_ERROR)
+   exit_subtest("FAIL");
+   else
+   exit_subtest("WARN");
+   }
+
exit_subtest("SUCCESS");
+   }
 }
 
 /**
diff --git a/lib/igt_kernel_taint.c b/lib/igt_kernel_taint.c
new file mode 100644
index ..86d9cd20
--- /dev/null
+++ b/lib/igt_kernel_taint.c
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_kernel_taint.h"
+#include "igt_sysfs.h"
+
+#define BIT(x) (1ul << (x))
+
+static const struct kernel_taint {
+   const char *msg;
+   unsigned int flags;
+} taints[] = {
+   { "Non-GPL module loaded" },
+   { "Forced module load" },
+   { "Unsafe SMP processor" },
+   { "Forced module unload" },
+   { "Machine Check Exception", TAINT_WARN },
+   { "Bad page detected", TAINT_ERROR },
+   { "Tainted by user request", TAINT_WARN },
+   { "System is on fire", TAINT_ERROR },
+   { "ACPI DSDT has been overridden by user" },
+   { "OOPS", TAINT_ERROR },
+   { "Staging driver loaded; are you mad?" },
+   { "Severe firmware bug workaround active", TAINT_WARN },
+   { "Out-of-tree module loaded" },
+   { "Unsigned module loaded" },
+