Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-02-27 06:54:46)
> 
> 
> On 2/27/2018 2:22 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2018-02-26 16:57:11)
> >> As you said we do always reset GuC no matter the value of the modparam,
> >> but that does not reset the doorbell HW. If we're coming out of S3 and
> >> the state as been preserved this will cause the doorbell HW to be left
> >> in an unclean state, which could cause spurious doorbell interrupts to
> >> be sent to GuC, not sure how the firmware handles those. The code as
> >> moved since last time I looked at this in detail and I think we're now
> >> most likely going to overwrite those unclean doorbells, but there are
> >> unlikely corner cases (preempt context failing to be created) where we
> >> might not do so.
> > I'm still going "wait, we can put the device into D3 and the GuC is
> > still powered?" Something feels wrong if the GuC retains state after the
> > HW is powered down.
> GuC will be powered down, with RC6. Just that firmware in WOPCM can get 
> wiped off if
> memory is reset/powered down during resume. In case of mem sleep 
> generally WOPCM stays intact and if we exit
> RC6 on resume from sleep, firmware will be restored into GuC without 
> driver intervention.
> But since we do full GPU reset as part of sanitize we have to load it 
> from driver again.

On resume, we don't know if we are coming from module load, resume from
S3, resume S3+RST, resume from S4, or resume from kexec. (S3+RST, kexec
are truly without our knowledge, the others we could feed the
information through but RST makes that moot.) Ergo, you cannot know if
the right fw image is loaded and aiui you should treat the state as
undefined and always reload. Does that make sense? Is there a way you
can query what fw is loaded and so skip instead?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

[Sagar Arun Kamble]

On 2/26/2018 10:27 PM, Daniele Ceraolo Spurio wrote:



On 25/02/18 22:17, Sagar Arun Kamble wrote:



On 2/23/2018 10:31 PM, Daniele Ceraolo Spurio wrote:



On 23/02/18 06:04, Michal Wajdeczko wrote:
Right after GPU reset there will be a small window of time during 
which

some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.

v2: s/reset_prepare/prepare_to_reset (Michel)
 don't forget about gem_sanitize path (Daniele)

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem.c    |  5 -
  drivers/gpu/drm/i915/intel_guc.h   |  5 +
  drivers/gpu/drm/i915/intel_huc.h   |  5 +
  drivers/gpu/drm/i915/intel_uc.c    | 14 ++
  drivers/gpu/drm/i915/intel_uc.h    |  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 14c855b..ae2c4ba 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct 
drm_i915_private *dev_priv)

  }
    i915_gem_revoke_fences(dev_priv);
+    intel_uc_prepare_to_reset(dev_priv);
    return err;
  }
@@ -4881,8 +4882,10 @@ void i915_gem_sanitize(struct 
drm_i915_private *i915)
   * it may impact the display and we are uncertain about the 
stability

   * of the reset, so this could be applied to even earlier gen.
   */
-    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
+    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
+    intel_uc_prepare_to_reset(i915);


This leaves the status with an incorrect value if we boot with 
i915.reset=0, 
It depends on whether WOPCM is locked (In case of resume from S3 I 
have seen it to be the case often).

Then we need not reload GuC also unless we are not doing full GPU reset.
but I think this is still the right place to add this in. 

Yes
There are several things with GuC that are going to break if we use 
reset=0 (e.g. doorbell cleanup) 

Can you elaborate how it might break.
i915 isn't currently communicating to GuC (destroy_doorbell) during 
doorbell cleanup and if we start communicating then it should
not fail as GuC will be available with reset=0.  Also 
__intel_uc_reset_hw isn't gated by reset modparam.


As you said we do always reset GuC no matter the value of the 
modparam, but that does not reset the doorbell HW. If we're coming out 
of S3 and the state as been preserved this will cause the doorbell HW 
to be left in an unclean state, which could cause spurious doorbell 
interrupts to be sent to GuC, not sure how the firmware handles those. 
The code as moved since last time I looked at this in detail and I 
think we're now most likely going to overwrite those unclean 
doorbells, but there are unlikely corner cases (preempt context 
failing to be created) where we might not do so.
More generally, my concern was that in the code flow we assume GuC and 
related HW to be reset and in need of a re-init when we come out of 
suspend when actually as you reported that might not be the case if we 
have reset=0. Even if we have no major concerns now, issues might 
arise in the future after code reworks or new feature additions if we 
start from a wrong assumption. Instead of changing the flow to 
consider the reset=0 (which isn't really a supported scenario) I think 
it'd be more useful to just enforce the fact that we don't support 
that use-case with GuC, hence my suggestion. And yes, I'm probably 
just being uber-paranoid :P



Makes sense . Agree on sanitizing with GuC to now allow reset=0
We could also fix this if we could reset doorbell unit alone at resume 
and acquire needed doorbells but AFAIK earlier guc_init_doorbell_hw is 
the way to reset all doorbells (that needed GuC). As you said we can 
skip these changes though since reset=0 isn't supported scenario.

Daniele

so I wouldn't consider this a regression, but we might want to start 
sanitizing the modparams to not allow reset=0 with GuC.


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+    }
  }
    int i915_gem_suspend(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 52856a9..0f6adb1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,9 @@ static inline u32 guc_ggtt_offset(struct 
i915_vma *vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, 
u32 size);

  u32 

Re: [Intel-gfx] [PATCH 1/1 RFC] drivers/gpu/drm/i915:Documentation for batchbuffer submission

[Rogovin, Kevin]

Hi,

> These documentation improvements are much welcome, here are a few comments 
> from me.

Thankyou!

>Quoting kevin.rogo...@intel.com (2018-02-16 16:04:22)
>> +Intel GPU Basics
>> +
>> +
>> +An Intel GPU has multiple engines. There are several engine types.
>> +
>> +- RCS engine is for rendering 3D and performing compute, this is named 
>> `I915_EXEC_DEFAULT` in user space.

>I'd call out I915_EXEC_RENDER existence here and introduce I915_EXEC_DEFAULT 
>as its own line.

I agree; though what exactly is I915_EXECI_DEFAULT supposed to mean? it appears 
(to me) as just an alias
for I915_EXEC_RENDER.

>> +- BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user 
>> space.
> +- VCS is a video encode and decode engine, this is named 
> +`I915_EXEC_BSD` in user space
>> +- VECS is video enhancement engine, this is named `I915_EXEC_VEBOX` in user 
>> space.
>> +
>> +The Intel GPU family is a familiy of integrated GPU's using Unified 
>> +Memory Access. For having the GPU "do work", user space will feed the 
>> +GPU batch buffers via one of the ioctls 
>> +`DRM_IOCTL_I915_GEM_EXECBUFFER`, `DRM_IOCTL_I915_GEM_EXECBUFFER2` or 
>> +`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will 
>> +instruct the

> I'd also call out DRM_IOCTL_I915_GEM_EXECBUFFER to be legacy submission 
> method and primarily mention I915_GEM_EXECBUFFER2_WR.

Agreed. 

>> +GPU to perform work (for example rendering) and that work needs 
>> +memory from which to read and memory to which to write. All memory is 
>> +encapsulated within GEM buffer objects (usually created with the ioctl 
>> DRM_IOCTL_I915_GEM_CREATE).
>> +An ioctl providing a batchbuffer for the GPU to create will also list 
>> +all GEM buffer objects that the batchbuffer reads and/or writes.
>> +

>In chronological order, maybe first introduce the hardware contexts?
>Only then go to PPGTT.

Sure.

- snip (quoting patch) -

>> +Common Code
>> +~~~
>> +
>> +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> +   :doc: User command execution
>> +
>> +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> +   :functions: i915_gem_do_execbuffer

>I'm not sure about referring to internal functions as they're bound to change 
>often. No strong feeling on this, I just see this will be easy to miss when 
>changing the related code.

I can place the text in the source file itself and have the .rst reference it, 
does this sound good?

>> +
>> +Batchbuffer Submission Varieties
>> +~
>> +
>> +As stated before, there are several varieties in how to submit 
>> +batchbuffers to the GPU; which one in use is controlled by function 
>> +pointer values in the c-struct intel_engine_cs (defined in 
>> +drivers/gpu/drm/i915/intel_ringbuffer.h)
>> +
>> +- request_alloc
>> +- submit_request

> Same here. Due to the being here in a separate file, I'm not sure if this 
> level of detail is going to be kept up when changing the actual code?

I can place the text in the source file as well; one of the goals I have is 
that the documentation has sufficient details within
it so that a new person can not only have an idea of what the driver is doing, 
but where the code is located.

>> +
>> +The three varieties for submitting batchbuffer to the GPU are the following.
>> +
>> +1. Batchbuffers are subbmitted directly to a ring buffer; this is the most 
>> basic way to submit batchbuffers to the GPU and is for generations strictly 
>> before Gen8. When batchbuffers are submitted this older way, their contents 
>> are checked via Batchbuffer Parsing, see `Batchbuffer Parsing`_.

> Just for editing and reading pleasure, there must be a way of cutting long 
> lines in lists.

This was something that I had troubles with; when I cut the long lines, the 
produced html output would not make it a list;
I had tried each of the following to cut the long lines:

  1. just cut the long lines to multiple lines

  2. add a \ between line-breaks

  3. cut long line and add white space to force alignment

Each of these resulted in just one item instead of a list. Any advice/pointers 
are greatly appreciated.

> But more importantly, do refer to Command Parser/Parsing as the code uses cmd 
> parser aka. command parser extensively.

The item (3) has a link to the section "Batchbuffer Parsing" whose contents are 
the information on the command parser. Would you 
like me to rename the section "Batchbuffer Parsing" to "Command Parser" as well?

And again, thankyou for the comments (as this is just an RFC); I will be 
posting more (hopefully) by the end of the week with
all feedback taken into use and additional content (namely how/when those 
various function pointers are called and the entire
IRQ dance for submission and other details,  (for example) GuC submission).

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

Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

[Sagar Arun Kamble]

On 2/27/2018 2:22 AM, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2018-02-26 16:57:11)


On 25/02/18 22:17, Sagar Arun Kamble wrote:


On 2/23/2018 10:31 PM, Daniele Ceraolo Spurio wrote:


On 23/02/18 06:04, Michal Wajdeczko wrote:

Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.

v2: s/reset_prepare/prepare_to_reset (Michel)
  don't forget about gem_sanitize path (Daniele)

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
   drivers/gpu/drm/i915/i915_gem.c    |  5 -
   drivers/gpu/drm/i915/intel_guc.h   |  5 +
   drivers/gpu/drm/i915/intel_huc.h   |  5 +
   drivers/gpu/drm/i915/intel_uc.c    | 14 ++
   drivers/gpu/drm/i915/intel_uc.h    |  1 +
   drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
   6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 14c855b..ae2c4ba 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct
drm_i915_private *dev_priv)
   }
     i915_gem_revoke_fences(dev_priv);
+    intel_uc_prepare_to_reset(dev_priv);
     return err;
   }
@@ -4881,8 +4882,10 @@ void i915_gem_sanitize(struct drm_i915_private
*i915)
    * it may impact the display and we are uncertain about the
stability
    * of the reset, so this could be applied to even earlier gen.
    */
-    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
+    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
+    intel_uc_prepare_to_reset(i915);

This leaves the status with an incorrect value if we boot with
i915.reset=0,

It depends on whether WOPCM is locked (In case of resume from S3 I have
seen it to be the case often).
Then we need not reload GuC also unless we are not doing full GPU reset.

but I think this is still the right place to add this in.

Yes

There are several things with GuC that are going to break if we use
reset=0 (e.g. doorbell cleanup)

Can you elaborate how it might break.
i915 isn't currently communicating to GuC (destroy_doorbell) during
doorbell cleanup and if we start communicating then it should
not fail as GuC will be available with reset=0.  Also
__intel_uc_reset_hw isn't gated by reset modparam.

As you said we do always reset GuC no matter the value of the modparam,
but that does not reset the doorbell HW. If we're coming out of S3 and
the state as been preserved this will cause the doorbell HW to be left
in an unclean state, which could cause spurious doorbell interrupts to
be sent to GuC, not sure how the firmware handles those. The code as
moved since last time I looked at this in detail and I think we're now
most likely going to overwrite those unclean doorbells, but there are
unlikely corner cases (preempt context failing to be created) where we
might not do so.

I'm still going "wait, we can put the device into D3 and the GuC is
still powered?" Something feels wrong if the GuC retains state after the
HW is powered down.
GuC will be powered down, with RC6. Just that firmware in WOPCM can get 
wiped off if
memory is reset/powered down during resume. In case of mem sleep 
generally WOPCM stays intact and if we exit
RC6 on resume from sleep, firmware will be restored into GuC without 
driver intervention.
But since we do full GPU reset as part of sanitize we have to load it 
from driver again.

  (So I'm wondering why this isn't just part of the
normal guc init path for module load/resume.)
-Chris


--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH v9] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

[Sagar Arun Kamble]

On 2/27/2018 4:34 AM, Oscar Mateo wrote:



On 2/25/2018 9:22 PM, Sagar Arun Kamble wrote:



On 2/23/2018 4:35 AM, Oscar Mateo wrote:





+ * We might have detected that some engines are fused off after 
we initialized
+ * the forcewake domains. Prune them, to make sure they only 
reference existing

+ * engines.
+ */
+void intel_uncore_prune(struct drm_i915_private *dev_priv)
+{
+    if (INTEL_GEN(dev_priv) >= 11) {
+    enum forcewake_domains fw_domains = 
dev_priv->uncore.fw_domains;

+    enum forcewake_domain_id domain_id;
+    int i;
+
+    for (i = 0; i < I915_MAX_VCS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VDBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VCS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
fw_domains check seems redundant as it is initialized based on 
HAS_ENGINE.

we can just have
if (!HAS_ENGINE(dev_priv, _VCS(i)))
    fw_domain_fini(dev_priv, domain_id);


I don't want to call fw_domain_fini on something we never 
initialized in the first place (e.g. VCS1/3 and VECS1/2/3 on an 
ICL-LP).



Right. Makes sense.
for loop iterating over engines based on ring_mask can help us rely 
on only HAS_ENGINE condition and then we can have complete pruning in 
single for loop.

what do you think?


Hmmm.. I'm not sure I follow: intel_device_info_init_mmio modifies 
ring_mask, so if I loop over engines based on ring_mask I am going to 
miss those I want to prune, right?



Oops ... you are right ...
My suggestion about skipping fw_domains check will not work currently. 
In future may be if we create default ring_mask and runtime ring_mask it 
can be reworked.


Other suggestion to use single for loop (for_each_engine()) can be done 
I think.
It will make it generic for all engine types.  Below is what I am 
thinking of as part of intel_uncore_prune:


for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
    if (HAS_ENGINE(dev_priv, i))
        continue;
    if (fw_domains & BIT(i))
        fw_domain_fini(dev_priv, i);
}

+ fw_domain_fini(dev_priv, domain_id);
+    }
+
+    for (i = 0; i < I915_MAX_VECS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VEBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VECS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
+    fw_domain_fini(dev_priv, domain_id);
+    }
+    }
+}
+
  void intel_uncore_fini(struct drm_i915_private *dev_priv)
  {
  /* Paranoia: make sure we have disabled everything before we 
exit. */
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h

index 53ef77d..28feabf 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -129,6 +129,7 @@ struct intel_uncore {
    void intel_uncore_sanitize(struct drm_i915_private *dev_priv);
  void intel_uncore_init(struct drm_i915_private *dev_priv);
+void intel_uncore_prune(struct drm_i915_private *dev_priv);
  bool intel_uncore_unclaimed_mmio(struct drm_i915_private 
*dev_priv);
  bool intel_uncore_arm_unclaimed_mmio_detection(struct 
drm_i915_private *dev_priv);

  void intel_uncore_fini(struct drm_i915_private *dev_priv);










--
Thanks,
Sagar

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Check for power state control capability.

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Check for power state control capability.
URL   : https://patchwork.freedesktop.org/series/39006/
State : success

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-a-query-forked-busy-hang:
dmesg-warn -> PASS   (shard-hsw)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-hsw) k.org#196691
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-atomic:
pass   -> FAIL   (shard-hsw) fdo#104873
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-apl) fdo#103167

k.org#196691 https://bugzilla.kernel.org/show_bug.cgi?id=196691
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:3460 pass:1818 dwarn:1   dfail:0   fail:7   skip:1633 
time:12188s
shard-hswtotal:3460 pass:1765 dwarn:1   dfail:0   fail:2   skip:1691 
time:11710s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6536s
Blacklisted hosts:
shard-kbltotal:3442 pass:1924 dwarn:1   dfail:0   fail:7   skip:1509 
time:9222s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Fix the order of platforms for setting DP source rates

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Fix the order of platforms for setting DP source rates
URL   : https://patchwork.freedesktop.org/series/39004/
State : success

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-a-query-forked-busy-hang:
dmesg-warn -> PASS   (shard-hsw)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_flip:
Subgroup 2x-flip-vs-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Subgroup modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-apl) fdo#103167 +1
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test perf:
Subgroup oa-exponents:
pass   -> INCOMPLETE (shard-apl) fdo#102254

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-apltotal:3431 pass:1800 dwarn:1   dfail:0   fail:8   skip:1621 
time:11910s
shard-hswtotal:3460 pass:1766 dwarn:1   dfail:0   fail:2   skip:1690 
time:11624s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6595s
Blacklisted hosts:
shard-kbltotal:3460 pass:1942 dwarn:1   dfail:0   fail:8   skip:1509 
time:9447s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Enable VBT based BL control for DP (v3) (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Enable VBT based BL control for DP (v3) (rev8)
URL   : https://patchwork.freedesktop.org/series/38559/
State : success

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-a-query-forked-busy-hang:
dmesg-warn -> PASS   (shard-hsw)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-hsw) k.org#196691
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Subgroup modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-apl) fdo#103167
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test perf:
Subgroup oa-exponents:
pass   -> INCOMPLETE (shard-apl) fdo#102254
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

k.org#196691 https://bugzilla.kernel.org/show_bug.cgi?id=196691
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3431 pass:1801 dwarn:1   dfail:0   fail:7   skip:1621 
time:11855s
shard-hswtotal:3460 pass:1764 dwarn:1   dfail:0   fail:3   skip:1691 
time:11641s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6612s
Blacklisted hosts:
shard-kbltotal:3425 pass:1912 dwarn:1   dfail:0   fail:8   skip:1502 
time:8930s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Check for power state control capability.

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Check for power state control capability.
URL   : https://patchwork.freedesktop.org/series/39006/
State : success

== Summary ==

Series 39006v1 drm/i915/psr: Check for power state control capability.
https://patchwork.freedesktop.org/api/1.0/series/39006/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
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:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:462s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:518s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

7c50cf4f0dc70112cd82f4475308299df810f302 drm-tip: 2018y-02m-26d-22h-51m-08s UTC 
integration manifest
82fc31e49ad0 drm/i915/psr: Check for power state control capability.

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Fix the order of platforms for setting DP source rates

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Fix the order of platforms for setting DP source rates
URL   : https://patchwork.freedesktop.org/series/39004/
State : success

== Summary ==

Series 39004v1 drm/i915/dp: Fix the order of platforms for setting DP source 
rates
https://patchwork.freedesktop.org/api/1.0/series/39004/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (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:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
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:476s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:462s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:407s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:448s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:482s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s

7c50cf4f0dc70112cd82f4475308299df810f302 drm-tip: 2018y-02m-26d-22h-51m-08s UTC 
integration manifest
1efebff63e44 drm/i915/dp: Fix the order of platforms for setting DP source rates

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable VBT based BL control for DP (v3) (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Enable VBT based BL control for DP (v3) (rev8)
URL   : https://patchwork.freedesktop.org/series/38559/
State : success

== Summary ==

Series 38559v8 drm/i915: Enable VBT based BL control for DP (v3)
https://patchwork.freedesktop.org/api/1.0/series/38559/revisions/8/mbox/

 Possible new issues:

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-hsw-4770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-skl-6260u)

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:477s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:418s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:504s
fi-hsw-4770  total:108  pass:99   dwarn:0   dfail:0   fail:0   skip:8  
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:244  pass:227  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:389s

7c50cf4f0dc70112cd82f4475308299df810f302 drm-tip: 2018y-02m-26d-22h-51m-08s UTC 
integration manifest
926e05a8a5cf drm/i915: Enable VBT based BL control for DP

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915/skl+: Add and enable DP AUX CH mutex

[Pandiyan, Dhinakaran]

On Mon, 2018-02-26 at 14:41 -0800, Rodrigo Vivi wrote:
> On Mon, Feb 26, 2018 at 01:48:37PM -0800, José Roberto de Souza wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent access by hardware and driver.
> > Older gen handling will be done separated.
> > 
> > Reference: 
> > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
> > Page 198 - AUX programming sequence
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h |  9 
> >  drivers/gpu/drm/i915/intel_dp.c | 47 
> > +
> >  2 files changed, 56 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index eea5b2c537d4..f36e839b4b4f 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5385,6 +5385,15 @@ enum {
> >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> >  
> > +#define _DPA_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6402C)
> > +#define _DPB_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6412C)
> > +#define _DPC_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6422C)
> > +#define _DPD_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6432C)
> > +#define _DPF_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6452C)
> > +#define DP_AUX_CH_MUTEX(port)  _MMIO_PORT(port, _DPA_AUX_CH_MUTEX, 
> > _DPB_AUX_CH_MUTEX)
> 
> s/port/aux_ch
> 
> > +#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
> > +#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
> > +
> >  /*
> >   * Computing GMCH M and N values for the Display Port link
> >   *
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2c3eb90b9499..7004239e4c9e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1081,6 +1081,42 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
> > intel_dp *intel_dp,
> > aux_clock_divider);
> >  }
> >  
> > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 9)
> > +   return true;
> > +
> > +   /* Spec says that mutex is acquired when status bit is read as unset,
> > +* here waiting for 2msec(+-4 aux transactions) before give up.
> > +*/
> > +   if (intel_wait_for_register(dev_priv, DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > +   DP_AUX_CH_MUTEX_STATUS, 0, 2)) {
> > +   DRM_DEBUG_KMS("aux channel %c locked for 2msec, timing out\n",
> > + aux_ch_name(intel_dp->aux_ch));
> > +   return false;
> > +   }
> > +

With nits that Rodrigo pointed out addressed, feel free to use

Reviewed-by: Dhinakaran Pandiyan 

Btw for future reference, including change log in the commit message is
a good idea in the absence of a cover letter.


> > +   return true;
> > +}
> > +
> > +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 9)
> > +   return;
> > +
> > +   /* set the status bit releases the mutex + keeping mutex enabled */
> > +   I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > +  DP_AUX_CH_MUTEX_ENABLE | DP_AUX_CH_MUTEX_STATUS);
> > +}
> > +
> >  static int
> >  intel_dp_aux_ch(struct intel_dp *intel_dp,
> > const uint8_t *send, int send_bytes,
> > @@ -1119,6 +1155,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> >  
> > intel_dp_check_edp(intel_dp);
> >  
> > +   if (!intel_dp_aux_ch_trylock(intel_dp)) {
> > +   ret = -EBUSY;
> > +   goto out_locked;
> 
> out_"locked" confused me here...
> 
> not sure about a better name...
> 
> maybe out_aux_unlocked ?! :/
> 
> > +   }
> > +
> > /* Try to wait for any previous AUX channel activity */
> > for (try = 0; try < 3; try++) {
> > status = I915_READ_NOTRACE(ch_ctl);
> > @@ -1248,6 +1289,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> >  
> > ret = recv_bytes;
> >  out:
> > +   intel_dp_aux_ch_unlock(intel_dp);
> > +out_locked:
> > 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add a parameter to disable SAGV

[Patchwork]

== Series Details ==

Series: drm/i915: Add a parameter to disable SAGV
URL   : https://patchwork.freedesktop.org/series/38992/
State : success

== Summary ==

 Possible new issues:

Test kms_atomic_transition:
Subgroup plane-all-modeset-transition-fencing:
pass   -> DMESG-WARN (shard-apl)
Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-atomic:
pass   -> DMESG-WARN (shard-apl)
Subgroup short-flip-after-cursor-toggle:
pass   -> DMESG-WARN (shard-apl)
Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-none:
pass   -> DMESG-WARN (shard-apl)
Subgroup legacy-pipe-a-tiling-x:
pass   -> DMESG-WARN (shard-apl)
Test kms_properties:
Subgroup connector-properties-atomic:
pass   -> DMESG-WARN (shard-apl)
Test kms_vblank:
Subgroup pipe-a-query-forked-busy-hang:
dmesg-warn -> PASS   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_color:
Subgroup pipe-a-ctm-green-to-red:
pass   -> DMESG-WARN (shard-apl) fdo#104852
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
pass   -> DMESG-WARN (shard-apl) fdo#102670
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-apl) fdo#103167
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-apl) fdo#101623

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104852 https://bugs.freedesktop.org/show_bug.cgi?id=104852
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:3357 pass:1759 dwarn:9   dfail:0   fail:8   skip:1579 
time:11390s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11695s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6573s
Blacklisted hosts:
shard-kbltotal:3374 pass:1894 dwarn:2   dfail:0   fail:8   skip:1468 
time:9034s

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/psr: Check for power state control capability.

[Dhinakaran Pandiyan]

eDP spec says - "If PSR/PSR2 is supported, the SET_POWER_CAPABLE bit in the
EDP_GENERAL_CAPABILITY_1 register (DPCD Address 00701h, bit d7) must be set
to 1."

Reject PSR on panels without this cap bit set as such panels cannot be
controlled via SET_POWER & SET_DP_PWR_VOLTAGE register and the DP source
needs to be able to do that for PSR.

Thanks to Nathan for debugging this.

Panel cap checks like this can be done just once, let's fix this
when PSR dpcd init movement lands.

Cc: Nathan D Ciobanu 
Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 89f41d28c44a..e0701b7f87f7 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -405,6 +405,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
 
+   if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
+   DRM_DEBUG_KMS("PSR condition failed: panel lacks power state 
control\n");
+   return;
+   }
+
/*
 * FIXME psr2_support is messed up. It's both computed
 * dynamically during PSR enable, and extracted from sink
-- 
2.14.1

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

[Intel-gfx] [PATCH] drm/i915/dp: Fix the order of platforms for setting DP source rates

[Manasi Navare]

The usual if ladder order should be from newest to oldest
platform. However the CNL conditional statement was misplaced.
This patch sets the DP source for platforms starting from the newest
to oldest.

Suggested-by: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 56db518..1c0aeda 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -278,13 +278,13 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
/* This should only be done once */
WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
 
-   if (IS_GEN9_LP(dev_priv)) {
-   source_rates = bxt_rates;
-   size = ARRAY_SIZE(bxt_rates);
-   } else if (IS_CANNONLAKE(dev_priv)) {
+   if (IS_CANNONLAKE(dev_priv)) {
source_rates = cnl_rates;
size = ARRAY_SIZE(cnl_rates);
max_rate = cnl_max_source_rate(intel_dp);
+   } else if (IS_GEN9_LP(dev_priv)) {
+   source_rates = bxt_rates;
+   size = ARRAY_SIZE(bxt_rates);
} else if (IS_GEN9_BC(dev_priv)) {
source_rates = skl_rates;
size = ARRAY_SIZE(skl_rates);
-- 
2.7.4

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

[Intel-gfx] [PATCH] [V3] drm/i915: Enable VBT based BL control for DP

[Mustamin B Mustaffa]

Currently, BXT_PP is hardcoded with value '0'.
It practically disabled eDP backlight on MRB (BXT) platform.

This patch will tell which BXT_PP registers (there are two set of
PP_CONTROL in the spec) to be used as defined in VBT (Video Bios Timing
table) and this will enabled eDP backlight controller on MRB (BXT)
platform.

v2:
 - Remove unnecessary information in commit message.
 - Assign vbt.backlight.controller to a backlight_controller variable and
   return the variable value.
v3:
 - Rebased to latest code base.
 - updated commit title.

Signed-off-by: Mustamin B Mustaffa 
---
 drivers/gpu/drm/i915/intel_dp.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 475a19d76a49..20e3fcd2bf7e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -655,18 +655,15 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
 
+   int backlight_controller = dev_priv->vbt.backlight.controller;
+
lockdep_assert_held(_priv->pps_mutex);
 
/* We should never land here with regular DP ports */
WARN_ON(!intel_dp_is_edp(intel_dp));
 
-   /*
-* TODO: BXT has 2 PPS instances. The correct port->PPS instance
-* mapping needs to be retrieved from VBT, for now just hard-code to
-* use instance #0 always.
-*/
if (!intel_dp->pps_reset)
-   return 0;
+   return backlight_controller;
 
intel_dp->pps_reset = false;
 
@@ -676,7 +673,7 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
 */
intel_dp_init_panel_power_sequencer_registers(intel_dp, false);
 
-   return 0;
+   return backlight_controller;
 }
 
 typedef bool (*vlv_pipe_check)(struct drm_i915_private *dev_priv,
-- 
2.16.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 series starting with [v6,1/2] drm/i915: Move a bunch of workaround-related code to its own file (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v6,1/2] drm/i915: Move a bunch of 
workaround-related code to its own file (rev2)
URL   : https://patchwork.freedesktop.org/series/38891/
State : success

== Summary ==

 Possible new issues:

Test kms_flip:
Subgroup flip-vs-fences:
pass   -> DMESG-WARN (shard-hsw)
Test kms_vblank:
Subgroup pipe-a-query-forked-busy-hang:
dmesg-warn -> PASS   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-apl) fdo#103167
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#99912
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755

shard-apltotal:3391 pass:1786 dwarn:1   dfail:0   fail:7   skip:1596 
time:11813s
shard-hswtotal:3460 pass:1766 dwarn:2   dfail:0   fail:1   skip:1690 
time:11710s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6579s
Blacklisted hosts:
shard-kbltotal:3443 pass:1922 dwarn:9   dfail:0   fail:8   skip:1503 
time:9268s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Enable VBT based BL control for DP (v3) (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915: Enable VBT based BL control for DP (v3) (rev7)
URL   : https://patchwork.freedesktop.org/series/38559/
State : failure

== Summary ==

Applying: drm/i915: Enable VBT based BL control for DP
error: corrupt patch at line 40
error: could not build fake ancestor
Patch failed at 0001 drm/i915: Enable VBT based BL control for DP
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] [PATCH] [V3] drm/i915: Enable VBT based BL control for DP

[Mustamin B Mustaffa]

Currently, BXT_PP is hardcoded with value '0'.
It practically disabled eDP backlight on MRB (BXT) platform.

This patch will tell which BXT_PP registers (there are two set of
PP_CONTROL in the spec) to be used as defined in VBT (Video Bios Timing
table) and this will enabled eDP backlight controller on MRB (BXT)
platform.

v2:
 - Remove unnecessary information in commit message.
 - Assign vbt.backlight.controller to a backlight_controller variable and
   return the variable value.
v3:
 - Rebased to latest code base.
 - updated commit title.

Signed-off-by: Mustamin B Mustaffa 
---
 drivers/gpu/drm/i915/intel_dp.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1868f73f730c..b9068bd1943f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -655,18 +655,16 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
 
+   int backlight_controller = dev_priv->vbt.backlight.controller;
+
lockdep_assert_held(_priv->pps_mutex);
 
/* We should never land here with regular DP ports */
WARN_ON(!intel_dp_is_edp(intel_dp));
 
-   /*
-* TODO: BXT has 2 PPS instances. The correct port->PPS instance
-* mapping needs to be retrieved from VBT, for now just hard-code to
-* use instance #0 always.
-*/
if (!intel_dp->pps_reset)
-   return 0;
+   return backlight_controller;
 
intel_dp->pps_reset = false;
 
@@ -676,7 +674,7 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
 */
intel_dp_init_panel_power_sequencer_registers(intel_dp, false);
 
-   return 0;
+   return backlight_controller;
 }
 
 typedef bool (*vlv_pipe_check)(struct drm_i915_private *dev_priv,
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT

[Pandiyan, Dhinakaran]

> -Original Message-
> From: Runyan, Arthur J
> Sent: Tuesday, January 9, 2018 11:55 AM
> To: Pandiyan, Dhinakaran ; Singh, Gaurav K
> 
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo 
> Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> 
> Sorry, I've been out.  I'm checking on this.


Hi Art,

Is AUD_CHICKENBIT_REG:15 needed for BXT to fix code enumeration issues?

-DK

> 
> -Original Message-
> From: Pandiyan, Dhinakaran
> Sent: Thursday, 4 January, 2018 2:00 PM
> To: Singh, Gaurav K 
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> subransu.s.pru...@intel.com; Runyan, Arthur J 
> Subject: Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> 
> +Art
> 
> On Thu, 2018-01-04 at 22:13 +0530, Singh, Gaurav K wrote:
> >
> > On 1/4/2018 2:48 AM, Rodrigo Vivi wrote:
> > > On Wed, Jan 03, 2018 at 08:31:10PM +, Pandiyan, Dhinakaran wrote:
> > >> On Thu, 2018-01-04 at 00:48 +0530, Gaurav K Singh wrote:
> > >>> From: Gaurav Singh 
> > >>>
> > >>> On Apollolake, with stress test warm reboot, audio card was not
> > >>> getting enumerated after reboot. This was a
> > >> The problem looks similar to
> > >> https://lists.freedesktop.org/archives/intel-gfx/2017-October/14449
> > >> 5.html
> > >>
> > >> although the proposed solutions are vastly different. I have Cc'd
> > >> some more people.
> > >>
> > >>> spurious issue happening on Apollolake. HW codec and HD audio
> > >>> controller link was going out of sync for which there was a fix in
> > >>> i915 driver but was not getting invoked for BXT. Extending this
> > >>> fix to BXT as well.
> > >>>
> > >>> Tested on apollolake chromebook by stress test warm reboot with
> > >>> 2500 iterations.
> > >>>
> > >>> Signed-off-by: Gaurav K Singh 
> > >>> ---
> > >>>   drivers/gpu/drm/i915/intel_audio.c | 2 +-
> > >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > >>> b/drivers/gpu/drm/i915/intel_audio.c
> > >>> index f1502a0188eb..c71c04e1c3f6 100644
> > >>> --- a/drivers/gpu/drm/i915/intel_audio.c
> > >>> +++ b/drivers/gpu/drm/i915/intel_audio.c
> > >>> @@ -729,7 +729,7 @@ static void
> i915_audio_component_codec_wake_override(struct device *kdev,
> > >>> struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > >>> u32 tmp;
> > >>>
> > >>> -   if (!IS_GEN9_BC(dev_priv))
> > >>> +   if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
> > >> IS_GEN9()? GLK might need this too.
> > > I think this is applicable for all Gen9 platforms.
> >
> > > if GLK need there is the possibility of CNL also needing it...
> > > So not sure where to stop.
> > >
> > > Also looking to the original patch that introduced this function,
> > > commit '632f3ab95fe2 ("drm/i915/audio: add codec wakeup override
> > > enabled/disable callback")'
> > >
> > > it tells that the reason was:
> > > "In SKL, HDMI/DP codec and PCH HD Audio Controller are in different
> > > p$ wells, so it's necessary to reset display audio codecs when power
> > > we$ otherwise display audio codecs will disappear when resume from
> > > low p$ state."
> > >
> > > Is this the case here on BXT?
> > Yes, its the same case with BXT.
> > >
> > > Another interesting thing I noticed on Spec when searching for this
> > > bit was that this bit is related to an workaround on SKL/KBL/CFL...
> > > no mention to BXT.
> > >
> > > "This workaround is needed for an HW issue in SKL and KBL in which
> > > HW codec and HD audio controller link was going out of sync."
> > Yes, in Bspec it has been mentioned only for SKL and KBL. But without
> > this fix, sound card was not getting enumerated for BXT.
> 
> 
> Art,
> 
> Can you please help us here? To summarize, the question is what platforms need
> the AUD_CHICKENBIT_REG:15 bit to be set to avoid code enumeration failures?
> 
> -DK
> 
> > >
> > > Thanks,
> > > Rodrigo.
> > >
> > >>
> > >>> return;
> > >>>
> > >>> i915_audio_component_get_power(kdev);
> > >> ___
> > >> 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/cnl: Add WaRsDisableCoarsePowerGating

[Radhakrishna Sripada]

On Thu, Feb 22, 2018 at 12:05:35PM -0800, Rodrigo Vivi wrote:
> Old Wa added now forever on CNL all steppings.
> 
> With CPU P states enabled along with RC6, dispatcher
> hangs can happen.
> 
> Cc: Rafael Antognolli 
> Signed-off-by: Rodrigo Vivi 
Reviewed-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 5 +++--
>  drivers/gpu/drm/i915/intel_guc.c | 2 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 82a106b1bdbc..7bbec5546d12 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2788,9 +2788,10 @@ intel_info(const struct drm_i915_private *dev_priv)
>  /* Early gen2 have a totally busted CS tlb and require pinned batches. */
>  #define HAS_BROKEN_CS_TLB(dev_priv)  (IS_I830(dev_priv) || 
> IS_I845G(dev_priv))
>  
> -/* WaRsDisableCoarsePowerGating:skl,bxt */
> +/* WaRsDisableCoarsePowerGating:skl,cnl */
>  #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
> - (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> + (IS_CANNONLAKE(dev_priv) || \
> +  IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
>  
>  /*
>   * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> interrupts
> diff --git a/drivers/gpu/drm/i915/intel_guc.c 
> b/drivers/gpu/drm/i915/intel_guc.c
> index 21140ccd7a97..e6512cccef75 100644
> --- a/drivers/gpu/drm/i915/intel_guc.c
> +++ b/drivers/gpu/drm/i915/intel_guc.c
> @@ -370,7 +370,7 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
>   u32 action[2];
>  
>   action[0] = INTEL_GUC_ACTION_SAMPLE_FORCEWAKE;
> - /* WaRsDisableCoarsePowerGating:skl,bxt */
> + /* WaRsDisableCoarsePowerGating:skl,cnl */
>   if (!HAS_RC6(dev_priv) || NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
>   action[1] = 0;
>   else
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 731b3808a62e..c5e495dfa387 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6695,7 +6695,7 @@ static void gen9_enable_rc6(struct drm_i915_private 
> *dev_priv)
>  
>   /*
>* 3b: Enable Coarse Power Gating only when RC6 is enabled.
> -  * WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be 
> disabled with RC6.
> +  * WaRsDisableCoarsePowerGating:skl,cnl - Render/Media PG need to be 
> disabled with RC6.
>*/
>   if (NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
>   I915_WRITE(GEN9_PG_ENABLE, 0);
> -- 
> 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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add and enable DP AUX CH mutex (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Add and enable DP AUX CH mutex (rev3)
URL   : https://patchwork.freedesktop.org/series/38655/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_flip_tiling:
Subgroup flip-yf-tiled:
fail   -> PASS   (shard-apl) fdo#103822
Test kms_plane:
Subgroup plane-position-hole-dpms-pipe-b-planes:
pass   -> FAIL   (shard-apl) fdo#103166
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925

shard-apltotal:3460 pass:1818 dwarn:1   dfail:0   fail:8   skip:1632 
time:12309s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11824s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6658s
Blacklisted hosts:
shard-kbltotal:3460 pass:1944 dwarn:1   dfail:0   fail:7   skip:1508 
time:9631s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8164/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: Add a parameter to disable SAGV

[Rodrigo Vivi]

On Mon, Feb 26, 2018 at 03:45:51PM -0800, Azhar Shaikh wrote:
> SAGV handling is currently broken which can result in system hangs.
> Add a parameter to disable SAGV, till the SAGV handling is fixed.

Not just handling of the limitations we have with SAGV is broken but
also probably some hidden DBUF config issue that is worst when SAGV
is enabled.

But also the handling broken is not a good reason for the parameter
itself. But the good part of this is the ability to debug display
hard hangs issues with SAGV requirements.

I'm in favor of the paramenter. We just need a different justification
here.

> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104975
> Signed-off-by: Azhar Shaikh 
> ---
>  drivers/gpu/drm/i915/i915_params.c | 3 +++
>  drivers/gpu/drm/i915/i915_params.h | 3 ++-
>  drivers/gpu/drm/i915/intel_pm.c| 2 +-
>  3 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 08108ce5be21..6aede52240b0 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -167,6 +167,9 @@ struct i915_params i915_modparams __read_mostly = {
>  i915_param_named_unsafe(enable_dp_mst, bool, 0600,
>   "Enable multi-stream transport (MST) for new DisplayPort sinks. 
> (default: true)");
>  
> +i915_param_named_unsafe(disable_sagv, bool, 0600,
> + "Disable SAGV (default: false)");
> +

I understand that SAGV is default to enable and enabled by BIOS so we
actually need to disable it.

However the name will cause the same old confusion as disable power well 
disable

So I'm in favor of bool i915.enable_sagv defaults to enable
and use i915.enable_sagv=0 when we need to disable it.

>  #if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
>  i915_param_named_unsafe(inject_load_failure, uint, 0400,
>   "Force an error after a number of failure check points (0:disabled 
> (default), N:force failure at the Nth failure check point)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 430f5f9d0ff4..ff3c7d5dee2d 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -69,7 +69,8 @@
>   param(bool, nuclear_pageflip, false) \
>   param(bool, enable_dp_mst, true) \
>   param(bool, enable_dpcd_backlight, false) \
> - param(bool, enable_gvt, false)
> + param(bool, enable_gvt, false) \
> + param(bool, disable_sagv, false)
>  
>  #define MEMBER(T, member, ...) T member;
>  struct i915_params {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 21dac6ebc202..0b1a6cbf45aa 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3693,7 +3693,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state 
> *state)
>   int level, latency;
>   int sagv_block_time_us;
>  
> - if (!intel_has_sagv(dev_priv))
> + if (!intel_has_sagv(dev_priv) || i915_modparams.disable_sagv)
>   return false;
>  
>   if (IS_GEN9(dev_priv))
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Google Summer of Code 2018

[Martin Peres]

Hi everyone,

Just a quick word to remind you that the X.Org Foundation got accepted
to the Google Summer of Code 2018!

As a potential mentor, if you have a project falling under the
foundation's (large) umbrella that you would like to kick start or get
help finishing, please add it to the list on the ideas page[1] as soon
as possible. Students will start applying on the 12th of March, see the
full timeline[2].

As a student, check out the projects our ideas' page[1]. If you find one
that interests you, check out our application guidelines[3] and, if you
are eligible, contact your potential mentor and start discussing right
away with him/her. We welcome any student who finds the prospect of
working on our Open Source Graphics stack exciting!

I will be once again the primary contact for the X.Org Foundation, so
please ask me anything by email or on IRC (mupuf on freenode). Other
administrators are Alex Deucher and Taylor Campbell (both Cc:ed).

Looking forward to interacting with old and new contributors, and maybe
welcome previous GSoC/EVoC students as mentors now that they grew to
become core contributors and/or have full-time jobs in the Graphics
stack (*wink wink nudge nudge*)!

Martin, on behalf of the X.Org Foundation

[1] https://www.x.org/wiki/SummerOfCodeIdeas/
[2] https://developers.google.com/open-source/gsoc/timeline
[3] https://www.x.org/wiki/GSoCApplication/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add a parameter to disable SAGV

[Patchwork]

== Series Details ==

Series: drm/i915: Add a parameter to disable SAGV
URL   : https://patchwork.freedesktop.org/series/38992/
State : success

== Summary ==

Series 38992v1 drm/i915: Add a parameter to disable SAGV
https://patchwork.freedesktop.org/api/1.0/series/38992/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (fi-skl-6700k2) fdo#104108
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:411s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:377s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
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:478s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:421s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
fi-skl-6700k2total:288  pass:263  dwarn:0   dfail:0   fail:1   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s

7c50cf4f0dc70112cd82f4475308299df810f302 drm-tip: 2018y-02m-26d-22h-51m-08s UTC 
integration manifest
58b2b3f7d935 drm/i915: Add a parameter to disable SAGV

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/2] drm/i915: Move a bunch of workaround-related code to its own file (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v6,1/2] drm/i915: Move a bunch of 
workaround-related code to its own file (rev2)
URL   : https://patchwork.freedesktop.org/series/38891/
State : success

== Summary ==

Series 38891v2 series starting with [v6,1/2] drm/i915: Move a bunch of 
workaround-related code to its own file
https://patchwork.freedesktop.org/api/1.0/series/38891/revisions/2/mbox/

 Known issues:

Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-bdw-5557u) fdo#104008

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

fi-bdw-5557u total:288  pass:266  dwarn:0   dfail:0   fail:1   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
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:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:282s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:404s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:495s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s

7c50cf4f0dc70112cd82f4475308299df810f302 drm-tip: 2018y-02m-26d-22h-51m-08s UTC 
integration manifest
36b7c865f15d drm/i915: Split out functions for different kinds of workarounds
564e0da061e5 drm/i915: Move a bunch of workaround-related code to its own file

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Add a parameter to disable SAGV

[Azhar Shaikh]

SAGV handling is currently broken which can result in system hangs.
Add a parameter to disable SAGV, till the SAGV handling is fixed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104975
Signed-off-by: Azhar Shaikh 
---
 drivers/gpu/drm/i915/i915_params.c | 3 +++
 drivers/gpu/drm/i915/i915_params.h | 3 ++-
 drivers/gpu/drm/i915/intel_pm.c| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce5be21..6aede52240b0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -167,6 +167,9 @@ struct i915_params i915_modparams __read_mostly = {
 i915_param_named_unsafe(enable_dp_mst, bool, 0600,
"Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");
 
+i915_param_named_unsafe(disable_sagv, bool, 0600,
+   "Disable SAGV (default: false)");
+
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
 i915_param_named_unsafe(inject_load_failure, uint, 0400,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..ff3c7d5dee2d 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -69,7 +69,8 @@
param(bool, nuclear_pageflip, false) \
param(bool, enable_dp_mst, true) \
param(bool, enable_dpcd_backlight, false) \
-   param(bool, enable_gvt, false)
+   param(bool, enable_gvt, false) \
+   param(bool, disable_sagv, false)
 
 #define MEMBER(T, member, ...) T member;
 struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 21dac6ebc202..0b1a6cbf45aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3693,7 +3693,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
int level, latency;
int sagv_block_time_us;
 
-   if (!intel_has_sagv(dev_priv))
+   if (!intel_has_sagv(dev_priv) || i915_modparams.disable_sagv)
return false;
 
if (IS_GEN9(dev_priv))
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,1/2] drm/i915: Move a bunch of workaround-related code to its own file (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v6,1/2] drm/i915: Move a bunch of 
workaround-related code to its own file (rev2)
URL   : https://patchwork.freedesktop.org/series/38891/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Move a bunch of workaround-related code to its own file
+drivers/gpu/drm/i915/intel_workarounds.c:684:1: warning: no newline at end of 
file

Commit: drm/i915: Split out functions for different kinds of workarounds
-O:drivers/gpu/drm/i915/intel_workarounds.c:684:1: warning: no newline at end 
of file
+

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

Re: [Intel-gfx] [PATCH 0/5] HDCP1.4 fixes

[Rodrigo Vivi]

On Mon, Feb 26, 2018 at 10:42:34PM +0530, Ramalingam C wrote:
> This series addresses the requriement of below HDCP compliance tests
>   DP: 1A-06 and 1B-05
>   HDMI: 1A-04 and 1A-07a
> 
> One of the patch uses the I915 power infra-structure for checking
> the power state of PW#1. Which enables the init path for all legacy
> platforms.
> 
> And encoder specific msg availability detection is moved into hdcp_shim.
> This will help to sync with DP hdcp data availability in the best
> possible way by fielding the CP_IRQ.

Do we want any of these on 4.16 or backported?
Please consider the use of "Fixes:" on whatever makes sense.

Thanks,
Rodrigo.

> 
> 
> Ramalingam C (5):
>   drm/i915: Read HDCP R0 thrice in case of mismatch
>   drm/i915: read Vprime thrice incase of mismatch
>   drm/i915: Check hdcp key loadability
>   drm/i915: Poll hdcp register on sudden NACK
>   drm/i915: Move hdcp msg detection into shim
> 
>  drivers/gpu/drm/i915/intel_dp.c   |  70 ++--
>  drivers/gpu/drm/i915/intel_drv.h  |   6 +-
>  drivers/gpu/drm/i915/intel_hdcp.c | 166 
> +++---
>  drivers/gpu/drm/i915/intel_hdmi.c |  28 ++-
>  4 files changed, 214 insertions(+), 56 deletions(-)
> 
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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 drm/i915/guc: Fill preempt context once at init time (rev2)

[Patchwork]

== Series Details ==

Series: series starting with drm/i915/guc: Fill preempt context once at init 
time (rev2)
URL   : https://patchwork.freedesktop.org/series/38975/
State : success

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test kms_vblank:
Subgroup pipe-c-ts-continuation-dpms-suspend:
pass   -> INCOMPLETE (shard-hsw)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-snb) fdo#102365
Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_flip_tiling:
Subgroup flip-yf-tiled:
fail   -> PASS   (shard-apl) fdo#103822
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3460 pass:1812 dwarn:2   dfail:0   fail:13  skip:1633 
time:12506s
shard-hswtotal:3436 pass:1754 dwarn:1   dfail:0   fail:2   skip:1677 
time:11589s
shard-snbtotal:3460 pass:1358 dwarn:1   dfail:0   fail:1   skip:2100 
time:6632s
Blacklisted hosts:
shard-kbltotal:3414 pass:1877 dwarn:4   dfail:2   fail:17  skip:1513 
time:9679s

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915/psr: Kill scheduled work for Core platforms.

[Pandiyan, Dhinakaran]

On Mon, 2018-02-26 at 15:12 -0800, Rodrigo Vivi wrote:
> On Fri, Feb 23, 2018 at 03:46:09PM -0800, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > > It is a fact that scheduled work is now improved.
> > > 
> > > But it is also a fact that on core platforms that shouldn't
> > > be needed. We only need to actually wait on VLV/CHV.
> > > 
> > > The immediate enabling is actually not an issue for the
> > > HW perspective for core platforms that have HW tracking.
> > > HW will wait few identical idle frames before transitioning
> > > to actual psr active anyways.
> > > 
> > > Note that this patch also remove the delayed activation
> > > on HSW and BDW introduced by commit 'd0ac896a477d
> > > ("drm/i915: Delay first PSR activation.")'. This was
> > > introduced to fix a blank screen on VLV/CHV and also
> > > masked some frozen screens on other core platforms.
> > > Probably the same that we are now properly hunting and fixing.
> > > 
> > > Furthermore, if we stop using delayed activation on core
> > > platforms we will be able, on following up patches,
> > > to use available workarounds to make HW tracking properly
> > > exit PSR instead of the big nuke of disabling psr and
> > > re-enable on exit and activate respectively.
> > > At least on few reliable cases.
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 14 +++---
> > >  drivers/gpu/drm/i915/intel_psr.c| 27 +++
> > >  2 files changed, 26 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index da80ee16a3cf..541290c307c7 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2522,18 +2522,18 @@ static int i915_edp_psr_status(struct seq_file 
> > > *m, void *data)
> > >   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> > >  dev_priv->psr.busy_frontbuffer_bits);
> > >  
> > > - if (timer_pending(_priv->psr.activate_timer))
> > > - seq_printf(m, "Activate scheduled: yes, in %dms\n",
> > > -
> > > jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
> > > - else
> > > - seq_printf(m, "Activate scheduled: no\n");
> > > -
> > > - if (HAS_DDI(dev_priv)) {
> > > + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
> > 
> > I don't get this change, it is better to retain HAS_DDI().
> > 
> > 
> > >   if (dev_priv->psr.psr2_support)
> > >   enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > >   else
> > >   enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > >   } else {
> > > + if (timer_pending(_priv->psr.activate_timer))
> > > + seq_printf(m, "Activate scheduled: yes, in %dms\n",
> > > +
> > > jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
> > > + else
> > > + seq_printf(m, "Activate scheduled: no\n");
> > > +
> > >   for_each_pipe(dev_priv, pipe) {
> > >   enum transcoder cpu_transcoder =
> > >   intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 826b480841ac..13409c6301e8 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -455,6 +455,8 @@ static void intel_psr_schedule(struct 
> > > drm_i915_private *i915,
> > >  {
> > >   unsigned long next;
> > >  
> > > + WARN_ON(!IS_VALLEYVIEW(i915) && !IS_CHERRYVIEW(i915));
> > > +
> > How about using only !(IS_VLV() || IS_CHV) in this file.
> > 
> > I think this is a reasonable check to have, please add a return too.
> > WARN_ON(!(IS_VLV() || IS_CHV())
> > return; 
> > 
> > >   lockdep_assert_held(>psr.lock);
> > >  
> > >   /*
> > > @@ -543,7 +545,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> > >   dev_priv->psr.enable_source(intel_dp, crtc_state);
> > >   dev_priv->psr.enabled = intel_dp;
> > >  
> > > - if (INTEL_GEN(dev_priv) >= 9) {
> > > + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
> > 
> > How about inverting this? 
> > 
> > if (IS_VLV() || IS_CHV())
> > intel_psr_schedule()
> > else 
> > intel_psr_activate()
> > 
> > is easier to follow IMO.
> > 
> >
> > What is the reason to not use HAS_DDI() ?
> 
> I believe HAS_DDI is not meaningful here. It is just a coincidence.
> 
> maybe we could simplify everything with has_hw_tracking but also
> a coincidence in other cases...
> 
> maybe create something meaninfull like VLV_PSR... :/
> 
> no strong feelings actually...
> 

Thanks for the clarification, IS_VLV() || IS_CHV() is good enough in
that case. Since you also have a comment 

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915: Move a bunch of workaround-related code to its own file

[Chris Wilson]

Quoting Oscar Mateo (2018-02-26 23:01:50)
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 41dc881..e41678f 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -58,6 +58,12 @@ Intel GVT-g Host Support(vGPU device model)
>  .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
> :internal:
>  
> +Workarounds
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +   :doc: Hardware workarounds
> +

If the kerneldoc insists on having the overview + index being in a
separate namespace to the code, could we at least have a symlink to
drivers/gpu/drm/i915/i915.rst so that we don't have to keep hunting for
it?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Pandiyan, Dhinakaran]

On Mon, 2018-02-26 at 15:08 -0800, Rodrigo Vivi wrote:
> On Fri, Feb 23, 2018 at 04:24:35PM -0800, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > > the CPU host modify writes may not get updated on the Display
> > > as expected.
> > > WA: Write 0x to CUR_SURFLIVE_A with every CPU
> > > host modify write to trigger PSR exit."
> > > 
> > > We can also find on spec other cases where they describe
> > > bogus writes to cursor registers to force PSR exit with
> > > HW tracking. And it was confirmed by HW engineers that
> > > this Wa can be safely applied for any frontbuffer activity.
> > > 
> > 
> > So the idea is to do a dummy MMIO write to trigger PSR exit.
> 
> yeap. But not good for PSR2 though :(
> We would need something else...
> 

We have to figure out HW frontbuffer tracking for PSR2 and I have been
mostly refraining from thinking about PSR2 problems until now. If this
helps PSR1, let's go with it.

> any idea?
> 
> So I will hold the v2 for now...
> 
> > 
> > > So let's use this more and more here instead of forcibly
> > > disable and re-enable PSR everytime that we have a simple
> > > reliable flush case.
> > > 
> > > Other commits improve the fbcon/fbdev use a lot, but this
> > > approach is the only when where we can get a fully reliable
> > > console with no slowness or missed frames and PSR still
> > > enabled and active.
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> > >  drivers/gpu/drm/i915/intel_psr.c | 15 +--
> > >  2 files changed, 16 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index f6afa5e5e7c1..ac09d17cd835 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -6007,6 +6007,9 @@ enum {
> > >  #define IVB_CURSOR_B_OFFSET 0x71080
> > >  #define IVB_CURSOR_C_OFFSET 0x72080
> > >  
> > > +#define _CUR_SURLIVE 0x700AC
> > > +#define CUR_SURLIVE(pipe)_CURSOR2(pipe, _CUR_SURLIVE)
> > 
> > Register address is correct.
> > This is a *status* register that provides current surface base address.
> > We aren't reading this register anywhere, so writing to it should be
> > fine.
> > 
> > > +
> > >  /* Display A control */
> > >  #define _DSPACNTR0x70180
> > >  #define   DISPLAY_PLANE_ENABLE   (1<<31)
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 13409c6301e8..49554036ffb8 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -946,8 +946,19 @@ void intel_psr_flush(struct drm_i915_private 
> > > *dev_priv,
> > >   dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
> > >  
> > >   /* By definition flush = invalidate + flush */
> > > - if (frontbuffer_bits)
> > > - intel_psr_exit(dev_priv);
> > > + if (frontbuffer_bits) {
> > > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > > + intel_psr_exit(dev_priv);
> > > + } else {
> > > + /*
> > > +  * Display WA #0884: all
> > > +  * This documented WA for bxt can be safely applied
> > > +  * broadly so we can force HW tracking to exit PSR
> > > +  * instead of disabling and re-enabling.
> > > +  */
> > > + I915_WRITE(CUR_SURLIVE(pipe), 0);
> > 
> > The workaround asks 0 to be written to CUR_SURFLIVE_A. But I think
> > writing to the active pipe register makes sense.Can you add that to the
> > comment since the patch deviates from the workaround?
> 
> yeap, worth a comment...
> 
> > 
> > 
> > > + }
> > > + }
> > >  
> > >   if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) {
> > >   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > 
> > 
> > There is a psr_activate that follows, you should remove that too. HW
> > should be able to activate PSR by itself.
> 
> agreed
> 
> > 
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915/psr: Kill scheduled work for Core platforms.

[Rodrigo Vivi]

On Fri, Feb 23, 2018 at 03:46:09PM -0800, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > It is a fact that scheduled work is now improved.
> > 
> > But it is also a fact that on core platforms that shouldn't
> > be needed. We only need to actually wait on VLV/CHV.
> > 
> > The immediate enabling is actually not an issue for the
> > HW perspective for core platforms that have HW tracking.
> > HW will wait few identical idle frames before transitioning
> > to actual psr active anyways.
> > 
> > Note that this patch also remove the delayed activation
> > on HSW and BDW introduced by commit 'd0ac896a477d
> > ("drm/i915: Delay first PSR activation.")'. This was
> > introduced to fix a blank screen on VLV/CHV and also
> > masked some frozen screens on other core platforms.
> > Probably the same that we are now properly hunting and fixing.
> > 
> > Furthermore, if we stop using delayed activation on core
> > platforms we will be able, on following up patches,
> > to use available workarounds to make HW tracking properly
> > exit PSR instead of the big nuke of disabling psr and
> > re-enable on exit and activate respectively.
> > At least on few reliable cases.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 14 +++---
> >  drivers/gpu/drm/i915/intel_psr.c| 27 +++
> >  2 files changed, 26 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index da80ee16a3cf..541290c307c7 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2522,18 +2522,18 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> >dev_priv->psr.busy_frontbuffer_bits);
> >  
> > -   if (timer_pending(_priv->psr.activate_timer))
> > -   seq_printf(m, "Activate scheduled: yes, in %dms\n",
> > -  
> > jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
> > -   else
> > -   seq_printf(m, "Activate scheduled: no\n");
> > -
> > -   if (HAS_DDI(dev_priv)) {
> > +   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
> 
> I don't get this change, it is better to retain HAS_DDI().
> 
> 
> > if (dev_priv->psr.psr2_support)
> > enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > else
> > enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > } else {
> > +   if (timer_pending(_priv->psr.activate_timer))
> > +   seq_printf(m, "Activate scheduled: yes, in %dms\n",
> > +  
> > jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
> > +   else
> > +   seq_printf(m, "Activate scheduled: no\n");
> > +
> > for_each_pipe(dev_priv, pipe) {
> > enum transcoder cpu_transcoder =
> > intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 826b480841ac..13409c6301e8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -455,6 +455,8 @@ static void intel_psr_schedule(struct drm_i915_private 
> > *i915,
> >  {
> > unsigned long next;
> >  
> > +   WARN_ON(!IS_VALLEYVIEW(i915) && !IS_CHERRYVIEW(i915));
> > +
> How about using only !(IS_VLV() || IS_CHV) in this file.
> 
> I think this is a reasonable check to have, please add a return too.
>   WARN_ON(!(IS_VLV() || IS_CHV())
>   return; 
> 
> > lockdep_assert_held(>psr.lock);
> >  
> > /*
> > @@ -543,7 +545,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> > dev_priv->psr.enable_source(intel_dp, crtc_state);
> > dev_priv->psr.enabled = intel_dp;
> >  
> > -   if (INTEL_GEN(dev_priv) >= 9) {
> > +   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
> 
> How about inverting this? 
> 
> if (IS_VLV() || IS_CHV())
>   intel_psr_schedule()
> else 
>   intel_psr_activate()
> 
> is easier to follow IMO.
> 
>
> What is the reason to not use HAS_DDI() ?

I believe HAS_DDI is not meaningful here. It is just a coincidence.

maybe we could simplify everything with has_hw_tracking but also
a coincidence in other cases...

maybe create something meaninfull like VLV_PSR... :/

no strong feelings actually...

> 
> > intel_psr_activate(intel_dp);
> > } else {
> > /*
> > @@ -553,8 +555,6 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> >  * However on some platforms we face issues when first
> >  * activation follows a modeset so quickly.
> >  * - On VLV/CHV we get bank screen on 

Re: [Intel-gfx] [PATCH 3/5] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Rodrigo Vivi]

On Fri, Feb 23, 2018 at 04:24:35PM -0800, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > the CPU host modify writes may not get updated on the Display
> > as expected.
> > WA: Write 0x to CUR_SURFLIVE_A with every CPU
> > host modify write to trigger PSR exit."
> > 
> > We can also find on spec other cases where they describe
> > bogus writes to cursor registers to force PSR exit with
> > HW tracking. And it was confirmed by HW engineers that
> > this Wa can be safely applied for any frontbuffer activity.
> > 
> 
> So the idea is to do a dummy MMIO write to trigger PSR exit.

yeap. But not good for PSR2 though :(
We would need something else...

any idea?

So I will hold the v2 for now...

> 
> > So let's use this more and more here instead of forcibly
> > disable and re-enable PSR everytime that we have a simple
> > reliable flush case.
> > 
> > Other commits improve the fbcon/fbdev use a lot, but this
> > approach is the only when where we can get a fully reliable
> > console with no slowness or missed frames and PSR still
> > enabled and active.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> >  drivers/gpu/drm/i915/intel_psr.c | 15 +--
> >  2 files changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f6afa5e5e7c1..ac09d17cd835 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6007,6 +6007,9 @@ enum {
> >  #define IVB_CURSOR_B_OFFSET 0x71080
> >  #define IVB_CURSOR_C_OFFSET 0x72080
> >  
> > +#define _CUR_SURLIVE   0x700AC
> > +#define CUR_SURLIVE(pipe)  _CURSOR2(pipe, _CUR_SURLIVE)
> 
> Register address is correct.
> This is a *status* register that provides current surface base address.
> We aren't reading this register anywhere, so writing to it should be
> fine.
> 
> > +
> >  /* Display A control */
> >  #define _DSPACNTR  0x70180
> >  #define   DISPLAY_PLANE_ENABLE (1<<31)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 13409c6301e8..49554036ffb8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -946,8 +946,19 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
> > dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
> >  
> > /* By definition flush = invalidate + flush */
> > -   if (frontbuffer_bits)
> > -   intel_psr_exit(dev_priv);
> > +   if (frontbuffer_bits) {
> > +   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > +   intel_psr_exit(dev_priv);
> > +   } else {
> > +   /*
> > +* Display WA #0884: all
> > +* This documented WA for bxt can be safely applied
> > +* broadly so we can force HW tracking to exit PSR
> > +* instead of disabling and re-enabling.
> > +*/
> > +   I915_WRITE(CUR_SURLIVE(pipe), 0);
> 
> The workaround asks 0 to be written to CUR_SURFLIVE_A. But I think
> writing to the active pipe register makes sense.Can you add that to the
> comment since the patch deviates from the workaround?

yeap, worth a comment...

> 
> 
> > +   }
> > +   }
> >  
> > if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) {
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> 
> 
> There is a psr_activate that follows, you should remove that too. HW
> should be able to activate PSR by itself.

agreed

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Display WA #1130: bxt, glk

[Rodrigo Vivi]

On Fri, Feb 23, 2018 at 04:40:38PM -0800, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > Host/Render modifications do not trigger PSR exit
> > or Wireless quick capture exit correctly.
> > 
> 
> I don't get this workaround either. The wording indicates frontbuffer
> modifications are expected to trigger PSR exit in HW. But we rely on the
> driver's frontbuffer tracking to do that for us.

With us moving more towards more HW tracking I believe it is good
to have hw tracking Wa related in place just in case.

> 
> 
> 
> > WA: Set MMIO register 0x4653C bit 31 = 1b.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 1 +
> >  drivers/gpu/drm/i915/intel_pm.c | 7 +++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 0f423cd52983..8a4cd8b4bd7c 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3924,6 +3924,7 @@ enum {
> >  #define   PWM1_GATING_DIS  (1 << 13)
> >  
> >  #define GEN9_CLKGATE_DIS_4 _MMIO(0x4653C)
> > +#define   BXT_DCIPH_GATING_DIS (1 << 31)
> >  #define   BXT_GMBUS_GATING_DIS (1 << 14)
> >  
> >  #define _CLKGATE_DIS_PSL_A 0x46520
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 7e15b261821d..a0a6b4b7c47b 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -114,6 +114,10 @@ static void bxt_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> >  */
> > I915_WRITE(GEN9_CLKGATE_DIS_0, I915_READ(GEN9_CLKGATE_DIS_0) |
> >PWM1_GATING_DIS | PWM2_GATING_DIS);
> > +
> > +   /* Display WA #1130:bxt */
> > +   I915_WRITE(GEN9_CLKGATE_DIS_4, I915_READ(GEN9_CLKGATE_DIS_4) |
> > +  BXT_DCIPH_GATING_DIS);
> >  }
> >  
> >  static void glk_init_clock_gating(struct drm_i915_private *dev_priv)
> > @@ -137,6 +141,9 @@ static void glk_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> > I915_WRITE(CHICKEN_MISC_2, val);
> > }
> >  
> > +   /* Display WA #1130:glk */
> > +   I915_WRITE(GEN9_CLKGATE_DIS_4, I915_READ(GEN9_CLKGATE_DIS_4) |
> > +  BXT_DCIPH_GATING_DIS);
> >  }
> >  
> >  static void i915_pineview_get_mem_freq(struct drm_i915_private *dev_priv)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

[Oscar Mateo]

On 2/25/2018 9:22 PM, Sagar Arun Kamble wrote:



On 2/23/2018 4:35 AM, Oscar Mateo wrote:





+ * We might have detected that some engines are fused off after we 
initialized
+ * the forcewake domains. Prune them, to make sure they only 
reference existing

+ * engines.
+ */
+void intel_uncore_prune(struct drm_i915_private *dev_priv)
+{
+    if (INTEL_GEN(dev_priv) >= 11) {
+    enum forcewake_domains fw_domains = 
dev_priv->uncore.fw_domains;

+    enum forcewake_domain_id domain_id;
+    int i;
+
+    for (i = 0; i < I915_MAX_VCS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VDBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VCS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
fw_domains check seems redundant as it is initialized based on 
HAS_ENGINE.

we can just have
if (!HAS_ENGINE(dev_priv, _VCS(i)))
    fw_domain_fini(dev_priv, domain_id);


I don't want to call fw_domain_fini on something we never initialized 
in the first place (e.g. VCS1/3 and VECS1/2/3 on an ICL-LP).



Right. Makes sense.
for loop iterating over engines based on ring_mask can help us rely on 
only HAS_ENGINE condition and then we can have complete pruning in 
single for loop.

what do you think?


Hmmm.. I'm not sure I follow: intel_device_info_init_mmio modifies 
ring_mask, so if I loop over engines based on ring_mask I am going to 
miss those I want to prune, right?



+ fw_domain_fini(dev_priv, domain_id);
+    }
+
+    for (i = 0; i < I915_MAX_VECS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VEBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VECS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
+    fw_domain_fini(dev_priv, domain_id);
+    }
+    }
+}
+
  void intel_uncore_fini(struct drm_i915_private *dev_priv)
  {
  /* Paranoia: make sure we have disabled everything before we 
exit. */
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h

index 53ef77d..28feabf 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -129,6 +129,7 @@ struct intel_uncore {
    void intel_uncore_sanitize(struct drm_i915_private *dev_priv);
  void intel_uncore_init(struct drm_i915_private *dev_priv);
+void intel_uncore_prune(struct drm_i915_private *dev_priv);
  bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
  bool intel_uncore_arm_unclaimed_mmio_detection(struct 
drm_i915_private *dev_priv);

  void intel_uncore_fini(struct drm_i915_private *dev_priv);








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

[Intel-gfx] [PATCH v6 1/2] drm/i915: Move a bunch of workaround-related code to its own file

[Oscar Mateo]

This has grown to be a sizable amount of code, so move it to
its own file before we try to refactor anything. For the moment,
we are leaving behind the WA BB code and the WAs that get applied
(incorrectly) in init_clock_gating, but we will deal with it later.

v2: Use intel_ prefix for code that deals with the hardware (Chris)
v3: Rebased
v4:
  - Rebased
  - New license header
v5:
  - Rebased
  - Added some organisational notes to the file (Chris)
v6: Include DOC section in the documentation build (Jani)

Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
Cc: Jani Nikula 
Reviewed-by: Chris Wilson 
---
 Documentation/gpu/i915.rst   |   6 +
 drivers/gpu/drm/i915/Makefile|   3 +-
 drivers/gpu/drm/i915/intel_engine_cs.c   | 634 
 drivers/gpu/drm/i915/intel_lrc.c |   1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   1 +
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   3 -
 drivers/gpu/drm/i915/intel_workarounds.c | 684 +++
 drivers/gpu/drm/i915/intel_workarounds.h |  13 +
 8 files changed, 707 insertions(+), 638 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_workarounds.c
 create mode 100644 drivers/gpu/drm/i915/intel_workarounds.h

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 41dc881..e41678f 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,12 @@ Intel GVT-g Host Support(vGPU device model)
 .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
:internal:
 
+Workarounds
+---
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
+   :doc: Hardware workarounds
+
 Display Hardware Handling
 =
 
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 881d712..3b7330b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -43,7 +43,8 @@ i915-y := i915_drv.o \
  intel_csr.o \
  intel_device_info.o \
  intel_pm.o \
- intel_runtime_pm.o
+ intel_runtime_pm.o \
+ intel_workarounds.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ce7fcf5..88c41d4 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -826,640 +826,6 @@ void intel_engine_get_instdone(struct intel_engine_cs 
*engine,
}
 }
 
-static int wa_add(struct drm_i915_private *dev_priv,
- i915_reg_t addr,
- const u32 mask, const u32 val)
-{
-   const u32 idx = dev_priv->workarounds.count;
-
-   if (WARN_ON(idx >= I915_MAX_WA_REGS))
-   return -ENOSPC;
-
-   dev_priv->workarounds.reg[idx].addr = addr;
-   dev_priv->workarounds.reg[idx].value = val;
-   dev_priv->workarounds.reg[idx].mask = mask;
-
-   dev_priv->workarounds.count++;
-
-   return 0;
-}
-
-#define WA_REG(addr, mask, val) do { \
-   const int r = wa_add(dev_priv, (addr), (mask), (val)); \
-   if (r) \
-   return r; \
-   } while (0)
-
-#define WA_SET_BIT_MASKED(addr, mask) \
-   WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
-
-#define WA_CLR_BIT_MASKED(addr, mask) \
-   WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
-
-#define WA_SET_FIELD_MASKED(addr, mask, value) \
-   WA_REG(addr, mask, _MASKED_FIELD(mask, value))
-
-static int wa_ring_whitelist_reg(struct intel_engine_cs *engine,
-i915_reg_t reg)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   struct i915_workarounds *wa = _priv->workarounds;
-   const uint32_t index = wa->hw_whitelist_count[engine->id];
-
-   if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
-   return -EINVAL;
-
-   I915_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
-  i915_mmio_reg_offset(reg));
-   wa->hw_whitelist_count[engine->id]++;
-
-   return 0;
-}
-
-static int gen8_init_workarounds(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
-
-   /* WaDisableAsyncFlipPerfMode:bdw,chv */
-   WA_SET_BIT_MASKED(MI_MODE, ASYNC_FLIP_PERF_DISABLE);
-
-   /* WaDisablePartialInstShootdown:bdw,chv */
-   WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
- PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
-
-   /* Use Force Non-Coherent whenever executing a 3D context. This is a
-* workaround for for a possible hang in the unlikely event a TLB
-* invalidation occurs during a PSD flush.
-*/
-   /* WaForceEnableNonCoherent:bdw,chv */
-   /* WaHdcDisableFetchWhenMasked:bdw,chv */
-   

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Chris Wilson]

Quoting Ramalingam C (2018-02-26 17:12:39)
> DP and HDMI HDCP specifications are varying with respect to
> detecting the R0 and ksv_fifo availability.
> 
> DP will produce CP_IRQ and set a bit for indicating the R0 and
> FIFO_READY status.
> 
> Whereas HDMI will set a bit for FIFO_READY but there is no bit
> indication for R0 ready. And also polling of READY bit is needed for
> HDMI as ther is no CP_IRQ.
> 
> So Fielding the CP_IRQ for DP and the polling the READY bit for a
> period and blindly waiting for a fixed time for R0 incase of HDMI are
> moved into corresponding hdcp_shim.
> 
> Signed-off-by: Ramalingam C 
> ---
> +static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
> +int timeout)
> +{
> +   long ret;
> +
> +   if (completion_done(cp_irq_recved))
> +   reinit_completion(cp_irq_recved);
> +
> +   ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
> +   msecs_to_jiffies(
> +   timeout));
> +   reinit_completion(cp_irq_recved);

This is not thread-safe.

The trick is to use a waitqueue to interrupt the sleeps inside the wait
loops to complete the polling quicker. (As stated, you can't escape the
polling, and you always need to check the IRQ was for the event you
expected anyway.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: expose RCS topology to userspace (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace (rev2)
URL   : https://patchwork.freedesktop.org/series/38981/
State : success

== Summary ==

 Possible new issues:

Test pm_sseu:
Subgroup full-enable:
pass   -> FAIL   (shard-apl)

 Known issues:

Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_flip_tiling:
Subgroup flip-yf-tiled:
fail   -> PASS   (shard-apl) fdo#103822
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:8   skip:1632 
time:12347s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11823s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6691s
Blacklisted hosts:
shard-kbltotal:3460 pass:1941 dwarn:2   dfail:0   fail:8   skip:1509 
time:9651s

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915/skl+: Add and enable DP AUX CH mutex

[Rodrigo Vivi]

On Mon, Feb 26, 2018 at 01:48:37PM -0800, José Roberto de Souza wrote:
> When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> self, so lets use the mutex register that is available in gen9+ to
> avoid concurrent access by hardware and driver.
> Older gen handling will be done separated.
> 
> Reference: 
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
> Page 198 - AUX programming sequence
> 
> Cc: Rodrigo Vivi 
> Cc: Jani Nikula 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  9 
>  drivers/gpu/drm/i915/intel_dp.c | 47 
> +
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index eea5b2c537d4..f36e839b4b4f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5385,6 +5385,15 @@ enum {
>  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
>  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
>  
> +#define _DPA_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6402C)
> +#define _DPB_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6412C)
> +#define _DPC_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6422C)
> +#define _DPD_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6432C)
> +#define _DPF_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6452C)
> +#define DP_AUX_CH_MUTEX(port)_MMIO_PORT(port, _DPA_AUX_CH_MUTEX, 
> _DPB_AUX_CH_MUTEX)

s/port/aux_ch

> +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> +
>  /*
>   * Computing GMCH M and N values for the Display Port link
>   *
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2c3eb90b9499..7004239e4c9e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1081,6 +1081,42 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
> intel_dp *intel_dp,
>   aux_clock_divider);
>  }
>  
> +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> +
> + if (INTEL_GEN(dev_priv) < 9)
> + return true;
> +
> + /* Spec says that mutex is acquired when status bit is read as unset,
> +  * here waiting for 2msec(+-4 aux transactions) before give up.
> +  */
> + if (intel_wait_for_register(dev_priv, DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> + DP_AUX_CH_MUTEX_STATUS, 0, 2)) {
> + DRM_DEBUG_KMS("aux channel %c locked for 2msec, timing out\n",
> +   aux_ch_name(intel_dp->aux_ch));
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> +
> + if (INTEL_GEN(dev_priv) < 9)
> + return;
> +
> + /* set the status bit releases the mutex + keeping mutex enabled */
> + I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> +DP_AUX_CH_MUTEX_ENABLE | DP_AUX_CH_MUTEX_STATUS);
> +}
> +
>  static int
>  intel_dp_aux_ch(struct intel_dp *intel_dp,
>   const uint8_t *send, int send_bytes,
> @@ -1119,6 +1155,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  
>   intel_dp_check_edp(intel_dp);
>  
> + if (!intel_dp_aux_ch_trylock(intel_dp)) {
> + ret = -EBUSY;
> + goto out_locked;

out_"locked" confused me here...

not sure about a better name...

maybe out_aux_unlocked ?! :/

> + }
> +
>   /* Try to wait for any previous AUX channel activity */
>   for (try = 0; try < 3; try++) {
>   status = I915_READ_NOTRACE(ch_ctl);
> @@ -1248,6 +1289,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  
>   ret = recv_bytes;
>  out:
> + intel_dp_aux_ch_unlock(intel_dp);
> +out_locked:
>   pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
>  
>   if (vdd)
> @@ -1544,6 +1587,10 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
>   else
>   intel_dp->get_aux_send_ctl = g4x_get_aux_send_ctl;
>  
> + if (INTEL_GEN(dev_priv) >= 9)
> + I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> +DP_AUX_CH_MUTEX_ENABLE);
> +

Cool! I believe we are in a good shape now...

with s/port/aux_ch corrected and preferably with a 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add and enable DP AUX CH mutex (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Add and enable DP AUX CH mutex (rev3)
URL   : https://patchwork.freedesktop.org/series/38655/
State : success

== Summary ==

Series 38655v3 drm/i915: Add and enable DP AUX CH mutex
https://patchwork.freedesktop.org/api/1.0/series/38655/revisions/3/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1

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:424s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:493s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:289s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:395s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:418s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:296s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:444s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:594s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:466s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
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:392s

3a86cab5785058d50346e5a26f51dacbaab29c2e drm-tip: 2018y-02m-26d-15h-41m-02s UTC 
integration manifest
0e9c7c490026 drm/i915/skl+: Add and enable DP AUX CH mutex

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Move underrun work from fbc to fifo_underrun.

[Rodrigo Vivi]

On Mon, Feb 26, 2018 at 09:00:50PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-02-26 20:53:08)
> > -void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
> > -{
> > -   struct intel_fbc *fbc = _priv->fbc;
> > -
> > -   if (!fbc_supported(dev_priv))
> > -   return;
> > -
> > -   /* There's no guarantee that underrun_detected won't be set to true
> > -* right after this check and before the work is scheduled, but 
> > that's
> > -* not a problem since we'll check it again under the work function
> > -* while FBC is locked. This check here is just to prevent us from
> > -* unnecessarily scheduling the work, and it relies on the fact 
> > that we
> > -* never switch underrun_detect back to false after it's true. */
> > -   if (READ_ONCE(fbc->underrun_detected))
> > -   return;
> > -
> > -   schedule_work(>underrun_work);
> > -}
> 
> > +static void intel_handle_fifo_underrun_irq(struct drm_i915_private 
> > *dev_priv)
> > +{
> > +   if (!HAS_FBC(dev_priv))
> > +   return;
> > +
> > +   spin_lock(_priv->underrun.lock);
> > +
> > +   if (dev_priv->underrun.detected)
> > +   goto out;
> > +   dev_priv->underrun.detected = true;
> > +
> > +   schedule_work(_priv->underrun.work);
> > +out:
> > +   spin_unlock(_priv->underrun.lock);
> 
> This locking (or bool) isn't required by the following patch either. But
> I presume the boolean is printed at some point, although that's probably
> less useful than whatever FBC/SAGV would say about being disabled.

I honestly didn't fully followed the initial goal of checking the detection
before scheduling the work So I assumed it was some underrun storm
and a mechanism to avoid multiple calls to fbc disable...

But yeap... I think we could live without it if no storm is possible
or if internal sagv and fbc are already handling those properly.

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

[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP1.4 fixes

[Patchwork]

== Series Details ==

Series: HDCP1.4 fixes
URL   : https://patchwork.freedesktop.org/series/38978/
State : success

== Summary ==

 Known issues:

Test kms_cursor_legacy:
Subgroup short-flip-after-cursor-atomic-transitions-varying-size:
pass   -> SKIP   (shard-snb) fdo#102670
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-snb) fdo#103060 +2
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_flip_tiling:
Subgroup flip-yf-tiled:
fail   -> PASS   (shard-apl) fdo#103822
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-blt:
pass   -> SKIP   (shard-snb) fdo#101623
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925

fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925

shard-apltotal:3558 pass:1869 dwarn:1   dfail:0   fail:7   skip:1680 
time:12471s
shard-hswtotal:3558 pass:1821 dwarn:1   dfail:0   fail:2   skip:1733 
time:12225s
shard-snbtotal:3460 pass:1356 dwarn:1   dfail:0   fail:2   skip:2101 
time:6624s
Blacklisted hosts:
shard-kbltotal:3379 pass:1885 dwarn:1   dfail:1   fail:8   skip:1482 
time:8946s

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Introduce SAGV mutex.

[Rodrigo Vivi]

On Mon, Feb 26, 2018 at 09:21:19PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-02-26 20:53:07)
> > Now that we are spreading the places we can manipulate
> > sagv status let's protect it.
> 
> This needs a lot more information about the protection you need. "sagv
> status" is too similar to sagv_status, so it seems like you are simply
> talking about protecting access to that variable, which doesn't make
> sense. So I presume you are talking about ordering enable/disable, which
> opens up a heap of questions as to why, and what should be done about
> the implied races in wanting to disable sagv
> before/during/immediately-after enabling it. (Even accepting the race
> conditions exist, you only needed to correct access to sagv; a mutex for
> a single variable is massive overkill. So again, the reader is left
> presuming you intend more.)

Yeap... Many intentions missing here indeed... sorry.

The intention here is to disable SAGV on any first fifo underrun interrupt
that could happen at anytime. And keep that disabled forever.
I don't want the sagv enable during modeset to enable that again. Because
I don't know what is happening to the machine anymore. Better to waste some
power than having the risk of hanging the machine.

So the sagv status variable already contain the
SAGV_NOT_CONTROLLED state and I wanted to use that to block SAGV.

I also want to disable SAGV as needed on any atomic commit, not only on
full modeset. [1] (Main missing part on this series probably)

The concurrence on disable wouldn't be a problem because the disable
sequence itself is already protected by the pcu mutex. However
the end result of sagv.status would be problematic. Because if plane
update disable sagv leaving STATUS_DISABLED, the next modeset would
enable SAGV back.

[1] https://patchwork.freedesktop.org/series/38806/

> -Chris
___
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 [v2,1/2] drm/i915/guc: Fill preempt context once at init time

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/guc: Fill preempt context once 
at init time
URL   : https://patchwork.freedesktop.org/series/38975/
State : success

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_flip_tiling:
Subgroup flip-yf-tiled:
fail   -> PASS   (shard-apl) fdo#103822
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925

fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925

shard-apltotal:3460 pass:1809 dwarn:2   dfail:0   fail:15  skip:1633 
time:12531s
shard-hswtotal:3460 pass:1766 dwarn:1   dfail:0   fail:2   skip:1690 
time:11751s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6638s
Blacklisted hosts:
shard-kbltotal:3348 pass:1843 dwarn:2   dfail:0   fail:15  skip:1485 
time:8736s

== Logs ==

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

[Intel-gfx] [PATCH v4 0/1] drm/i915: Add and enable DP AUX CH mutex

[José Roberto de Souza]

v2
- removed the PSR dependency, now getting lock all the times when available
- renamed functions to avoid nested calls
- moved register bits right after the DP_AUX_CH_MUTEX()
- removed 'drm/i915: keep AUX powered while PSR is enabled' Dhinakaran Pandiyan 
will sent a better and final version
v3
- rebased on top of Ville's AUX series
- moved port registers to above DP_AUX_CH_MUTEX()
- using intel_wait_for_register() instead of the internal version
v4
- removed virtual function to get mutex register address
- enabling the mutex back only on aux channel init
- added the aux channel name to the timeout debug message

José Roberto de Souza (1):
  drm/i915/skl+: Add and enable DP AUX CH mutex

 drivers/gpu/drm/i915/i915_reg.h |  9 
 drivers/gpu/drm/i915/intel_dp.c | 47 +
 2 files changed, 56 insertions(+)

-- 
2.16.2

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

[Intel-gfx] [PATCH v4 1/1] drm/i915/skl+: Add and enable DP AUX CH mutex

[José Roberto de Souza]

When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
self, so lets use the mutex register that is available in gen9+ to
avoid concurrent access by hardware and driver.
Older gen handling will be done separated.

Reference: 
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
Page 198 - AUX programming sequence

Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_reg.h |  9 
 drivers/gpu/drm/i915/intel_dp.c | 47 +
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index eea5b2c537d4..f36e839b4b4f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5385,6 +5385,15 @@ enum {
 #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
 #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
 
+#define _DPA_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6402C)
+#define _DPB_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6412C)
+#define _DPC_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6422C)
+#define _DPD_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6432C)
+#define _DPF_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6452C)
+#define DP_AUX_CH_MUTEX(port)  _MMIO_PORT(port, _DPA_AUX_CH_MUTEX, 
_DPB_AUX_CH_MUTEX)
+#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
+#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
+
 /*
  * Computing GMCH M and N values for the Display Port link
  *
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c3eb90b9499..7004239e4c9e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1081,6 +1081,42 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
intel_dp *intel_dp,
aux_clock_divider);
 }
 
+static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv =
+   to_i915(intel_dig_port->base.base.dev);
+
+   if (INTEL_GEN(dev_priv) < 9)
+   return true;
+
+   /* Spec says that mutex is acquired when status bit is read as unset,
+* here waiting for 2msec(+-4 aux transactions) before give up.
+*/
+   if (intel_wait_for_register(dev_priv, DP_AUX_CH_MUTEX(intel_dp->aux_ch),
+   DP_AUX_CH_MUTEX_STATUS, 0, 2)) {
+   DRM_DEBUG_KMS("aux channel %c locked for 2msec, timing out\n",
+ aux_ch_name(intel_dp->aux_ch));
+   return false;
+   }
+
+   return true;
+}
+
+static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv =
+   to_i915(intel_dig_port->base.base.dev);
+
+   if (INTEL_GEN(dev_priv) < 9)
+   return;
+
+   /* set the status bit releases the mutex + keeping mutex enabled */
+   I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
+  DP_AUX_CH_MUTEX_ENABLE | DP_AUX_CH_MUTEX_STATUS);
+}
+
 static int
 intel_dp_aux_ch(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
@@ -1119,6 +1155,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 
intel_dp_check_edp(intel_dp);
 
+   if (!intel_dp_aux_ch_trylock(intel_dp)) {
+   ret = -EBUSY;
+   goto out_locked;
+   }
+
/* Try to wait for any previous AUX channel activity */
for (try = 0; try < 3; try++) {
status = I915_READ_NOTRACE(ch_ctl);
@@ -1248,6 +1289,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 
ret = recv_bytes;
 out:
+   intel_dp_aux_ch_unlock(intel_dp);
+out_locked:
pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
 
if (vdd)
@@ -1544,6 +1587,10 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
else
intel_dp->get_aux_send_ctl = g4x_get_aux_send_ctl;
 
+   if (INTEL_GEN(dev_priv) >= 9)
+   I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
+  DP_AUX_CH_MUTEX_ENABLE);
+
drm_dp_aux_init(_dp->aux);
 
/* Failure to allocate our preferred name is not critical */
-- 
2.16.2

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

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_softpin: Only expect EINVAL for color-overlaps for user objects

[Chris Wilson]

Quoting Ville Syrjälä (2018-02-26 21:22:03)
> On Mon, Feb 26, 2018 at 08:54:47PM +, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-02-24 18:54:04)
> > > If the specified object can not fit into the GTT due to overlap with a
> > > neighbouring pinned object (not part of the execobjects[]), we expect to
> > > fail with ENOSPC (as we cannot evict, rather than EINVAL for the user
> > > error in a badly constructed execobjects[]). To prevent the tests
> > > causing overlap with other external objects expand the test hole by a
> > > page on either side.
> > > 
> > > (Setting up the system to deliberately hit ENOSPC is trickier as for
> > > example it requires pinned an object into the scanout with enough free
> > > space on either side to test.)
> > 
> > Anybody? I know it's an esoteric part of ancient HW that no one cares
> > about...
> > -Chris
> > 
> > > Signed-off-by: Chris Wilson 
> > > ---
> > >  tests/gem_softpin.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
> > > index 99388599..23f93623 100644
> > > --- a/tests/gem_softpin.c
> > > +++ b/tests/gem_softpin.c
> > > @@ -302,11 +302,11 @@ static void test_evict_snoop(int fd)
> > >  
> > > /* Find a hole */
> > > memset(object, 0, sizeof(object));
> > > -   object[0].handle = gem_create(fd, 3*4096);
> > > +   object[0].handle = gem_create(fd, 5*4096);
> > > gem_write(fd, object[0].handle, 0, , sizeof(bbe));
> > > gem_execbuf(fd, );
> > > gem_close(fd, object[0].handle);
> > > -   hole = object[0].offset;
> > > +   hole = object[0].offset + 4096;
> 
> I didn't double check the ENOSPC vs. EINVAL details, but a guard page on
> each side makes sense to me here.

It's enough to make me regret trying to discern the difference :)
EINVAL was for if the user's execobject[] conflicts with itself (a user
error), ENOSPC if we couldn't fit the object into the hole (something we
couldn't expect the user to predict).

Thanks,
-Chris
___
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/4] drm/i915: Don't propagate SAGV errnos in vain.

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Don't propagate SAGV errnos in 
vain.
URL   : https://patchwork.freedesktop.org/series/38987/
State : failure

== Summary ==

Applying: drm/i915: Don't propagate SAGV errnos in vain.
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_drv.h).
error: could not build fake ancestor
Patch failed at 0001 drm/i915: Don't propagate SAGV errnos in vain.
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] [igt-dev] [PATCH igt] igt/gem_softpin: Only expect EINVAL for color-overlaps for user objects

[Ville Syrjälä]

On Mon, Feb 26, 2018 at 08:54:47PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2018-02-24 18:54:04)
> > If the specified object can not fit into the GTT due to overlap with a
> > neighbouring pinned object (not part of the execobjects[]), we expect to
> > fail with ENOSPC (as we cannot evict, rather than EINVAL for the user
> > error in a badly constructed execobjects[]). To prevent the tests
> > causing overlap with other external objects expand the test hole by a
> > page on either side.
> > 
> > (Setting up the system to deliberately hit ENOSPC is trickier as for
> > example it requires pinned an object into the scanout with enough free
> > space on either side to test.)
> 
> Anybody? I know it's an esoteric part of ancient HW that no one cares
> about...
> -Chris
> 
> > Signed-off-by: Chris Wilson 
> > ---
> >  tests/gem_softpin.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
> > index 99388599..23f93623 100644
> > --- a/tests/gem_softpin.c
> > +++ b/tests/gem_softpin.c
> > @@ -302,11 +302,11 @@ static void test_evict_snoop(int fd)
> >  
> > /* Find a hole */
> > memset(object, 0, sizeof(object));
> > -   object[0].handle = gem_create(fd, 3*4096);
> > +   object[0].handle = gem_create(fd, 5*4096);
> > gem_write(fd, object[0].handle, 0, , sizeof(bbe));
> > gem_execbuf(fd, );
> > gem_close(fd, object[0].handle);
> > -   hole = object[0].offset;
> > +   hole = object[0].offset + 4096;

I didn't double check the ENOSPC vs. EINVAL details, but a guard page on
each side makes sense to me here.

Reviewed-by: Ville Syrjälä 

> >  
> > /* Create a snoop + uncached pair */
> > object[0].handle = gem_create(fd, 4096);
> > -- 
> > 2.16.1
> > 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

-- 
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 2/4] drm/i915: Introduce SAGV mutex.

[Chris Wilson]

Quoting Rodrigo Vivi (2018-02-26 20:53:07)
> Now that we are spreading the places we can manipulate
> sagv status let's protect it.

This needs a lot more information about the protection you need. "sagv
status" is too similar to sagv_status, so it seems like you are simply
talking about protecting access to that variable, which doesn't make
sense. So I presume you are talking about ordering enable/disable, which
opens up a heap of questions as to why, and what should be done about
the implied races in wanting to disable sagv
before/during/immediately-after enabling it. (Even accepting the race
conditions exist, you only needed to correct access to sagv; a mutex for
a single variable is massive overkill. So again, the reader is left
presuming you intend more.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Move underrun work from fbc to fifo_underrun.

[Chris Wilson]

Quoting Rodrigo Vivi (2018-02-26 20:53:08)
> -void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
> -{
> -   struct intel_fbc *fbc = _priv->fbc;
> -
> -   if (!fbc_supported(dev_priv))
> -   return;
> -
> -   /* There's no guarantee that underrun_detected won't be set to true
> -* right after this check and before the work is scheduled, but that's
> -* not a problem since we'll check it again under the work function
> -* while FBC is locked. This check here is just to prevent us from
> -* unnecessarily scheduling the work, and it relies on the fact that 
> we
> -* never switch underrun_detect back to false after it's true. */
> -   if (READ_ONCE(fbc->underrun_detected))
> -   return;
> -
> -   schedule_work(>underrun_work);
> -}

> +static void intel_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
> +{
> +   if (!HAS_FBC(dev_priv))
> +   return;
> +
> +   spin_lock(_priv->underrun.lock);
> +
> +   if (dev_priv->underrun.detected)
> +   goto out;
> +   dev_priv->underrun.detected = true;
> +
> +   schedule_work(_priv->underrun.work);
> +out:
> +   spin_unlock(_priv->underrun.lock);

This locking (or bool) isn't required by the following patch either. But
I presume the boolean is printed at some point, although that's probably
less useful than whatever FBC/SAGV would say about being disabled.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt/gem_softpin: Only expect EINVAL for color-overlaps for user objects

[Chris Wilson]

Quoting Chris Wilson (2018-02-24 18:54:04)
> If the specified object can not fit into the GTT due to overlap with a
> neighbouring pinned object (not part of the execobjects[]), we expect to
> fail with ENOSPC (as we cannot evict, rather than EINVAL for the user
> error in a badly constructed execobjects[]). To prevent the tests
> causing overlap with other external objects expand the test hole by a
> page on either side.
> 
> (Setting up the system to deliberately hit ENOSPC is trickier as for
> example it requires pinned an object into the scanout with enough free
> space on either side to test.)

Anybody? I know it's an esoteric part of ancient HW that no one cares
about...
-Chris

> Signed-off-by: Chris Wilson 
> ---
>  tests/gem_softpin.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
> index 99388599..23f93623 100644
> --- a/tests/gem_softpin.c
> +++ b/tests/gem_softpin.c
> @@ -302,11 +302,11 @@ static void test_evict_snoop(int fd)
>  
> /* Find a hole */
> memset(object, 0, sizeof(object));
> -   object[0].handle = gem_create(fd, 3*4096);
> +   object[0].handle = gem_create(fd, 5*4096);
> gem_write(fd, object[0].handle, 0, , sizeof(bbe));
> gem_execbuf(fd, );
> gem_close(fd, object[0].handle);
> -   hole = object[0].offset;
> +   hole = object[0].offset + 4096;
>  
> /* Create a snoop + uncached pair */
> object[0].handle = gem_create(fd, 4096);
> -- 
> 2.16.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm/i915: Don't propagate SAGV errnos in vain.

[Rodrigo Vivi]

We never used this information on upper level.
So let's just print the error and make the functions void.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_pm.c  | 26 +++---
 2 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0f733c5f0faf..2260aa1ecd8c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2004,8 +2004,8 @@ void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
 void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
 bool intel_can_enable_sagv(struct drm_atomic_state *state);
 u8 intel_sagv_block_time(const struct drm_i915_private *dev_priv);
-int intel_enable_sagv(struct drm_i915_private *dev_priv);
-int intel_disable_sagv(struct drm_i915_private *dev_priv);
+void intel_enable_sagv(struct drm_i915_private *dev_priv);
+void intel_disable_sagv(struct drm_i915_private *dev_priv);
 bool skl_wm_level_equals(const struct skl_wm_level *l1,
 const struct skl_wm_level *l2);
 bool skl_ddb_allocation_overlaps(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 92a14cb7e674..2b6419b7bdd1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3606,16 +3606,15 @@ intel_has_sagv(struct drm_i915_private *dev_priv)
  *  - All planes can enable watermarks for latencies >= SAGV engine block time
  *  - We're not using an interlaced display configuration
  */
-int
-intel_enable_sagv(struct drm_i915_private *dev_priv)
+void intel_enable_sagv(struct drm_i915_private *dev_priv)
 {
int ret;
 
if (!intel_has_sagv(dev_priv))
-   return 0;
+   return;
 
if (dev_priv->sagv_status == I915_SAGV_ENABLED)
-   return 0;
+   return;
 
DRM_DEBUG_KMS("Enabling the SAGV\n");
mutex_lock(_priv->pcu_lock);
@@ -3633,26 +3632,24 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
DRM_DEBUG_DRIVER("No SAGV found on system, ignoring\n");
dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
-   return 0;
+   return;
} else if (ret < 0) {
-   DRM_ERROR("Failed to enable the SAGV\n");
-   return ret;
+   DRM_ERROR("Failed to enable the SAGV (%d)\n", ret);
+   return;
}
 
dev_priv->sagv_status = I915_SAGV_ENABLED;
-   return 0;
 }
 
-int
-intel_disable_sagv(struct drm_i915_private *dev_priv)
+void intel_disable_sagv(struct drm_i915_private *dev_priv)
 {
int ret;
 
if (!intel_has_sagv(dev_priv))
-   return 0;
+   return;
 
if (dev_priv->sagv_status == I915_SAGV_DISABLED)
-   return 0;
+   return;
 
DRM_DEBUG_KMS("Disabling the SAGV\n");
mutex_lock(_priv->pcu_lock);
@@ -3671,14 +3668,13 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
DRM_DEBUG_DRIVER("No SAGV found on system, ignoring\n");
dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
-   return 0;
+   return;
} else if (ret < 0) {
DRM_ERROR("Failed to disable the SAGV (%d)\n", ret);
-   return ret;
+   return;
}
 
dev_priv->sagv_status = I915_SAGV_DISABLED;
-   return 0;
 }
 
 bool intel_can_enable_sagv(struct drm_atomic_state *state)
-- 
2.13.6

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

[Intel-gfx] [PATCH 3/4] drm/i915: Move underrun work from fbc to fifo_underrun.

[Rodrigo Vivi]

This underrun work can be useful to disable more pm
function that can cause trouble on underrun situations,
like SAGV.

Cc: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h|  7 +++-
 drivers/gpu/drm/i915/i915_irq.c|  2 ++
 drivers/gpu/drm/i915/intel_drv.h   |  3 +-
 drivers/gpu/drm/i915/intel_fbc.c   | 38 +-
 drivers/gpu/drm/i915/intel_fifo_underrun.c | 51 +-
 5 files changed, 61 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4c5174ceab96..1650dd5e5ffb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -658,7 +658,6 @@ struct intel_fbc {
bool active;
 
bool underrun_detected;
-   struct work_struct underrun_work;
 
/*
 * Due to the atomic rules we can't access some structures without the
@@ -2133,6 +2132,12 @@ struct drm_i915_private {
} sagv;
 
struct {
+   struct work_struct work;
+   spinlock_t lock;
+   bool detected;
+   } underrun;
+
+   struct {
/*
 * Raw watermark latency values:
 * in 0.1us units for WM0,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0a7ed990a8d1..ee9bd2d4ce34 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4045,6 +4045,8 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
 
intel_hpd_init_work(dev_priv);
 
+   intel_underrun_init_work(dev_priv);
+
INIT_WORK(>work, gen6_pm_rps_work);
 
INIT_WORK(_priv->l3_parity.error_work, ivybridge_parity_work);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2260aa1ecd8c..3ca27cc8700d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1317,6 +1317,7 @@ void intel_pch_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
 enum pipe pch_transcoder);
 void intel_check_cpu_fifo_underruns(struct drm_i915_private *dev_priv);
 void intel_check_pch_fifo_underruns(struct drm_i915_private *dev_priv);
+void intel_underrun_init_work(struct drm_i915_private *dev_priv);
 
 /* i915_irq.c */
 void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
@@ -1766,7 +1767,7 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
-void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv);
+void intel_fbc_underrun_detected(struct drm_i915_private *dev_priv);
 
 /* intel_hdmi.c */
 void intel_hdmi_init(struct drm_i915_private *dev_priv, i915_reg_t hdmi_reg,
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 38b036c499d9..c63568564b77 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1231,10 +1231,8 @@ void intel_fbc_global_disable(struct drm_i915_private 
*dev_priv)
cancel_work_sync(>work.work);
 }
 
-static void intel_fbc_underrun_work_fn(struct work_struct *work)
+void intel_fbc_underrun_detected(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv =
-   container_of(work, struct drm_i915_private, fbc.underrun_work);
struct intel_fbc *fbc = _priv->fbc;
 
mutex_lock(>lock);
@@ -1252,39 +1250,6 @@ static void intel_fbc_underrun_work_fn(struct 
work_struct *work)
 }
 
 /**
- * intel_fbc_handle_fifo_underrun_irq - disable FBC when we get a FIFO underrun
- * @dev_priv: i915 device instance
- *
- * Without FBC, most underruns are harmless and don't really cause too many
- * problems, except for an annoying message on dmesg. With FBC, underruns can
- * become black screens or even worse, especially when paired with bad
- * watermarks. So in order for us to be on the safe side, completely disable 
FBC
- * in case we ever detect a FIFO underrun on any pipe. An underrun on any pipe
- * already suggests that watermarks may be bad, so try to be as safe as
- * possible.
- *
- * This function is called from the IRQ handler.
- */
-void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
-{
-   struct intel_fbc *fbc = _priv->fbc;
-
-   if (!fbc_supported(dev_priv))
-   return;
-
-   /* There's no guarantee that underrun_detected won't be set to true
-* right after this check and before the work is scheduled, but that's
-* not a problem since we'll check it again under the work function
-* while FBC is locked. This check here is just to prevent us from
-* unnecessarily scheduling the work, and 

[Intel-gfx] [PATCH 4/4] drm/i915: Also disable SAGV on fifo underrun.

[Rodrigo Vivi]

On underrun situations and SAGV enabled we can face hard hangs.

So let's reuse the FBC workaround and expand that to SAGV
on the hope that it is not already too late for that.

Cc: Paulo Zanoni 
Cc: Ashar Shaikh 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_fbc.c   |  3 ++
 drivers/gpu/drm/i915/intel_fifo_underrun.c | 17 +--
 drivers/gpu/drm/i915/intel_pm.c| 45 --
 4 files changed, 50 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3ca27cc8700d..169af853f6ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2003,10 +2003,12 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
  struct skl_pipe_wm *out);
 void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
 void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
+bool intel_has_sagv(struct drm_i915_private *dev_priv);
 bool intel_can_enable_sagv(struct drm_atomic_state *state);
 u8 intel_sagv_block_time(const struct drm_i915_private *dev_priv);
 void intel_enable_sagv(struct drm_i915_private *dev_priv);
 void intel_disable_sagv(struct drm_i915_private *dev_priv);
+void intel_sagv_underrun_detected(struct drm_i915_private *dev_priv);
 bool skl_wm_level_equals(const struct skl_wm_level *l1,
 const struct skl_wm_level *l2);
 bool skl_ddb_allocation_overlaps(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index c63568564b77..a5d980227708 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1235,6 +1235,9 @@ void intel_fbc_underrun_detected(struct drm_i915_private 
*dev_priv)
 {
struct intel_fbc *fbc = _priv->fbc;
 
+   if (!fbc_supported(dev_priv))
+   return;
+
mutex_lock(>lock);
 
/* Maybe we were scheduled twice. */
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index 6a290621177b..dea189b83827 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -356,23 +356,24 @@ static void intel_underrun_work_fn(struct work_struct 
*work)
container_of(work, struct drm_i915_private, underrun.work);
 
intel_fbc_underrun_detected(dev_priv);
+   intel_sagv_underrun_detected(dev_priv);
 }
 
 /*
- * intel_handle_fifo_underrun_irq - disable FBC when we get a FIFO underrun
+ * intel_handle_fifo_underrun_irq - disable FBC and SAGV on a FIFO underrun
  *
- * Without FBC, most underruns are harmless and don't really cause too many
- * problems, except for an annoying message on dmesg. With FBC, underruns can
- * become black screens or even worse, especially when paired with bad
- * watermarks. So in order for us to be on the safe side, completely disable 
FBC
- * in case we ever detect a FIFO underrun on any pipe. An underrun on any pipe
- * already suggests that watermarks may be bad, so try to be as safe as
+ * Without FBC or SAGV, most underruns are harmless and don't really cause too
+ * many problems, except for an annoying message on dmesg. With them, underruns
+ * can become black screens or even worse, especially when paired with bad
+ * watermarks. So in order for us to be on the safe side, completely disable
+ * them in case we ever detect a FIFO underrun on any pipe. An underrun on any
+ * pipe already suggests that watermarks may be bad, so try to be as safe as
  * possible.
  *
  */
 static void intel_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_FBC(dev_priv))
+   if (!HAS_FBC(dev_priv) && !intel_has_sagv(dev_priv))
return;
 
spin_lock(_priv->underrun.lock);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e1ec9c2fd08a..84edaf161fe2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3581,8 +3581,7 @@ static bool skl_needs_memory_bw_wa(struct 
intel_atomic_state *state)
return false;
 }
 
-static bool
-intel_has_sagv(struct drm_i915_private *dev_priv)
+bool intel_has_sagv(struct drm_i915_private *dev_priv)
 {
bool ret = false;
 
@@ -3648,6 +3647,22 @@ void intel_enable_sagv(struct drm_i915_private *dev_priv)
mutex_unlock(_priv->sagv.lock);
 }
 
+static int __intel_disable_sagv(struct drm_i915_private *dev_priv)
+{
+   int ret;
+
+   mutex_lock(_priv->pcu_lock);
+
+   /* bspec says to keep retrying for at least 1 ms */
+   ret = skl_pcode_request(dev_priv, GEN9_PCODE_SAGV_CONTROL,
+   GEN9_SAGV_DISABLE,
+   GEN9_SAGV_IS_DISABLED, GEN9_SAGV_IS_DISABLED,
+   1);
+   

[Intel-gfx] [PATCH 2/4] drm/i915: Introduce SAGV mutex.

[Rodrigo Vivi]

Now that we are spreading the places we can manipulate
sagv status let's protect it.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h | 15 +--
 drivers/gpu/drm/i915/intel_pm.c | 41 ++---
 2 files changed, 35 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82a106b1bdbc..4c5174ceab96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2122,12 +2122,15 @@ struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
 
-   enum {
-   I915_SAGV_UNKNOWN = 0,
-   I915_SAGV_DISABLED,
-   I915_SAGV_ENABLED,
-   I915_SAGV_NOT_CONTROLLED
-   } sagv_status;
+   struct {
+   enum {
+   I915_SAGV_UNKNOWN = 0,
+   I915_SAGV_DISABLED,
+   I915_SAGV_ENABLED,
+   I915_SAGV_NOT_CONTROLLED
+   } status;
+   struct mutex lock;
+   } sagv;
 
struct {
/*
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2b6419b7bdd1..e1ec9c2fd08a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3584,15 +3584,19 @@ static bool skl_needs_memory_bw_wa(struct 
intel_atomic_state *state)
 static bool
 intel_has_sagv(struct drm_i915_private *dev_priv)
 {
+   bool ret = false;
+
if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
IS_CANNONLAKE(dev_priv))
return true;
 
+   mutex_lock(_priv->sagv.lock);
if (IS_SKYLAKE(dev_priv) &&
-   dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED)
-   return true;
+   dev_priv->sagv.status != I915_SAGV_NOT_CONTROLLED)
+   ret = true;
+   mutex_unlock(_priv->sagv.lock);
 
-   return false;
+   return ret;
 }
 
 /*
@@ -3613,8 +3617,9 @@ void intel_enable_sagv(struct drm_i915_private *dev_priv)
if (!intel_has_sagv(dev_priv))
return;
 
-   if (dev_priv->sagv_status == I915_SAGV_ENABLED)
-   return;
+   mutex_lock(_priv->sagv.lock);
+   if (dev_priv->sagv.status == I915_SAGV_ENABLED)
+   goto out;
 
DRM_DEBUG_KMS("Enabling the SAGV\n");
mutex_lock(_priv->pcu_lock);
@@ -3631,14 +3636,16 @@ void intel_enable_sagv(struct drm_i915_private 
*dev_priv)
 */
if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
DRM_DEBUG_DRIVER("No SAGV found on system, ignoring\n");
-   dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
-   return;
+   dev_priv->sagv.status = I915_SAGV_NOT_CONTROLLED;
+   goto out;
} else if (ret < 0) {
DRM_ERROR("Failed to enable the SAGV (%d)\n", ret);
-   return;
+   goto out;
}
 
-   dev_priv->sagv_status = I915_SAGV_ENABLED;
+   dev_priv->sagv.status = I915_SAGV_ENABLED;
+out:
+   mutex_unlock(_priv->sagv.lock);
 }
 
 void intel_disable_sagv(struct drm_i915_private *dev_priv)
@@ -3648,8 +3655,9 @@ void intel_disable_sagv(struct drm_i915_private *dev_priv)
if (!intel_has_sagv(dev_priv))
return;
 
-   if (dev_priv->sagv_status == I915_SAGV_DISABLED)
-   return;
+   mutex_lock(_priv->sagv.lock);
+   if (dev_priv->sagv.status == I915_SAGV_DISABLED)
+   goto out;
 
DRM_DEBUG_KMS("Disabling the SAGV\n");
mutex_lock(_priv->pcu_lock);
@@ -3667,14 +3675,16 @@ void intel_disable_sagv(struct drm_i915_private 
*dev_priv)
 */
if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
DRM_DEBUG_DRIVER("No SAGV found on system, ignoring\n");
-   dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
-   return;
+   dev_priv->sagv.status = I915_SAGV_NOT_CONTROLLED;
+   goto out;
} else if (ret < 0) {
DRM_ERROR("Failed to disable the SAGV (%d)\n", ret);
-   return;
+   goto out;
}
 
-   dev_priv->sagv_status = I915_SAGV_DISABLED;
+   dev_priv->sagv.status = I915_SAGV_DISABLED;
+out:
+   mutex_unlock(_priv->sagv.lock);
 }
 
 bool intel_can_enable_sagv(struct drm_atomic_state *state)
@@ -9046,6 +9056,7 @@ void intel_init_clock_gating_hooks(struct 
drm_i915_private *dev_priv)
 void intel_init_pm(struct drm_i915_private *dev_priv)
 {
intel_fbc_init(dev_priv);
+   mutex_init(_priv->sagv.lock);
 
/* For cxsr */
if (IS_PINEVIEW(dev_priv))
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-02-26 16:57:11)
> 
> 
> On 25/02/18 22:17, Sagar Arun Kamble wrote:
> > 
> > 
> > On 2/23/2018 10:31 PM, Daniele Ceraolo Spurio wrote:
> >>
> >>
> >> On 23/02/18 06:04, Michal Wajdeczko wrote:
> >>> Right after GPU reset there will be a small window of time during which
> >>> some of GuC/HuC fields will still show state before reset. Let's start
> >>> to fix that by sanitizing firmware status as we will use it shortly.
> >>>
> >>> v2: s/reset_prepare/prepare_to_reset (Michel)
> >>>  don't forget about gem_sanitize path (Daniele)
> >>>
> >>> Suggested-by: Daniele Ceraolo Spurio 
> >>> Signed-off-by: Michal Wajdeczko 
> >>> Cc: Daniele Ceraolo Spurio 
> >>> Cc: Sagar Arun Kamble 
> >>> Cc: Chris Wilson 
> >>> Cc: Michel Thierry 
> >>> ---
> >>>   drivers/gpu/drm/i915/i915_gem.c    |  5 -
> >>>   drivers/gpu/drm/i915/intel_guc.h   |  5 +
> >>>   drivers/gpu/drm/i915/intel_huc.h   |  5 +
> >>>   drivers/gpu/drm/i915/intel_uc.c    | 14 ++
> >>>   drivers/gpu/drm/i915/intel_uc.h    |  1 +
> >>>   drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
> >>>   6 files changed, 35 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >>> b/drivers/gpu/drm/i915/i915_gem.c
> >>> index 14c855b..ae2c4ba 100644
> >>> --- a/drivers/gpu/drm/i915/i915_gem.c
> >>> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >>> @@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct 
> >>> drm_i915_private *dev_priv)
> >>>   }
> >>>     i915_gem_revoke_fences(dev_priv);
> >>> +    intel_uc_prepare_to_reset(dev_priv);
> >>>     return err;
> >>>   }
> >>> @@ -4881,8 +4882,10 @@ void i915_gem_sanitize(struct drm_i915_private 
> >>> *i915)
> >>>    * it may impact the display and we are uncertain about the 
> >>> stability
> >>>    * of the reset, so this could be applied to even earlier gen.
> >>>    */
> >>> -    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
> >>> +    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
> >>> +    intel_uc_prepare_to_reset(i915);
> >>
> >> This leaves the status with an incorrect value if we boot with 
> >> i915.reset=0, 
> > It depends on whether WOPCM is locked (In case of resume from S3 I have 
> > seen it to be the case often).
> > Then we need not reload GuC also unless we are not doing full GPU reset.
> >> but I think this is still the right place to add this in. 
> > Yes
> >> There are several things with GuC that are going to break if we use 
> >> reset=0 (e.g. doorbell cleanup) 
> > Can you elaborate how it might break.
> > i915 isn't currently communicating to GuC (destroy_doorbell) during 
> > doorbell cleanup and if we start communicating then it should
> > not fail as GuC will be available with reset=0.  Also 
> > __intel_uc_reset_hw isn't gated by reset modparam.
> 
> As you said we do always reset GuC no matter the value of the modparam, 
> but that does not reset the doorbell HW. If we're coming out of S3 and 
> the state as been preserved this will cause the doorbell HW to be left 
> in an unclean state, which could cause spurious doorbell interrupts to 
> be sent to GuC, not sure how the firmware handles those. The code as 
> moved since last time I looked at this in detail and I think we're now 
> most likely going to overwrite those unclean doorbells, but there are 
> unlikely corner cases (preempt context failing to be created) where we 
> might not do so.

I'm still going "wait, we can put the device into D3 and the GuC is
still powered?" Something feels wrong if the GuC retains state after the
HW is powered down. (So I'm wondering why this isn't just part of the
normal guc init path for module load/resume.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915/skl+: Add and enable DP AUX CH mutex

[Pandiyan, Dhinakaran]

On Mon, 2018-02-26 at 18:31 +, Souza, Jose wrote:
> On Fri, 2018-02-23 at 19:12 -0800, Pandiyan, Dhinakaran wrote:
> > On Fri, 2018-02-23 at 17:51 -0800, José Roberto de Souza wrote:
> > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > > self, so lets use the mutex register that is available in gen9+ to
> > > avoid concurrent access by hardware and driver.
> > > Older gen handling will be done separated.
> > > 
> > > Reference: https://01.org/sites/default/files/documentation/intel-g
> > > fx-prm-osrc-skl-vol12-display.pdf
> > > Page 198 - AUX programming sequence
> > > 
> > > Cc: Rodrigo Vivi 
> > > Cc: Jani Nikula 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  |  9 ++
> > >  drivers/gpu/drm/i915/intel_dp.c  | 67
> > > 
> > >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> > >  3 files changed, 77 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index eea5b2c537d4..f36e839b4b4f 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5385,6 +5385,15 @@ enum {
> > >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> > >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> > >  
> > > +#define _DPA_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6402C)
> > > +#define _DPB_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6412C)
> > > +#define _DPC_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6422C)
> > > +#define _DPD_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6432C)
> > > +#define _DPF_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6452C)
> > > +#define DP_AUX_CH_MUTEX(port)_MMIO_PORT(port,
> > > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> > 
> >   ^aux_ch similar to ctl and data.
> > 
> > > +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> > > +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> > > +
> > >  /*
> > >   * Computing GMCH M and N values for the Display Port link
> > >   *
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 2c3eb90b9499..7be2fec51651 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1081,6 +1081,45 @@ static uint32_t
> > > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > >   aux_clock_divider)
> > > ;
> > >  }
> > >  
> > > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *intel_dig_port =
> > > dp_to_dig_port(intel_dp);
> > > + struct drm_i915_private *dev_priv =
> > > + to_i915(intel_dig_port->base.base.dev);
> > > + i915_reg_t ch_mutex;
> > > +
> > > + if (!intel_dp->aux_ch_mutex_reg)
> > > + return true;
> > > +
> > > + ch_mutex = intel_dp->aux_ch_mutex_reg(intel_dp);
> > > + I915_WRITE(ch_mutex, DP_AUX_CH_MUTEX_ENABLE);
> > 
> > 
> > > > > 
> > > > > You might be touching bits. We don't know if HW is using the
> > > > > reserved
> > > > > bits or not.
> > > > > So RMW |= bit 31 here is a good idea.
> > > > 
> > > > As a read in this register request the mutex lock is better avoid
> > > > any
> > > > read that is not meant to request it.
> > > 
> > > ok... I accept the fact that read that is locking
> > > so you are right here.
> > > 
> > 
> > I do not agree with the interpretation here, reading the register
> > *after* the mutex is enabled == request for locking. You can read the
> > register before enabling, and you have to read so that you don't
> > overwrite any other bit.
> > 
> > Ref: "Sticky bit set to 1 after a read to this register when Mutex is
> > enabled."
> 
> This is true but we must keep the mutex enabled all the time to
> guarantee that hardware will request lock too,

I think the status bit will still indicate busy if the HW started the
aux transaction before mutex was enabled. I think so because bspec
explicitly says to check the status bit right after enabling.


>  so any read to the
> register from our side will request the lock.
> 
> > 
> > 
> > > +
> > > + /* Spec says that mutex is acquired when status bit is
> > > read as unset,
> > > +  * here waiting for 2msec or 4 tries before give up.
> > 
> >  2 ms.^ this is not true
> > 
> > > +  */
> > > + if (intel_wait_for_register(dev_priv, ch_mutex,
> > > DP_AUX_CH_MUTEX_STATUS,
> > > + 0, 2)) {
> > > + DRM_WARN("dp_aux_ch port locked for too long");
> > 
> >  DRM_DEBUG_KMS("aux channel %c locked for 2 ms, timing
> > out\n");
> > 
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for kernel: Downgrade warning for unsafe parameters (rev2)

[Patchwork]

== Series Details ==

Series: kernel: Downgrade warning for unsafe parameters (rev2)
URL   : https://patchwork.freedesktop.org/series/38614/
State : success

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-a-query-busy:
pass   -> SKIP   (shard-snb)

 Known issues:

Test drv_hangman:
Subgroup error-state-capture-blt:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-top-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-legacy:
pass   -> FAIL   (shard-hsw) fdo#104873
Subgroup flip-vs-cursor-varying-size:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
incomplete -> PASS   (shard-snb) fdo#102365
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:7   skip:1632 
time:12178s
shard-hswtotal:3460 pass:1762 dwarn:1   dfail:0   fail:6   skip:1690 
time:11779s
shard-snbtotal:3460 pass:1358 dwarn:1   dfail:0   fail:1   skip:2100 
time:6592s
Blacklisted hosts:
shard-kbltotal:3409 pass:1913 dwarn:1   dfail:0   fail:7   skip:1487 
time:9168s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915/guc: Fill preempt context once at init time (rev2)

[Patchwork]

== Series Details ==

Series: series starting with drm/i915/guc: Fill preempt context once at init 
time (rev2)
URL   : https://patchwork.freedesktop.org/series/38975/
State : success

== Summary ==

Series 38975v2 series starting with drm/i915/guc: Fill preempt context once at 
init time
https://patchwork.freedesktop.org/api/1.0/series/38975/revisions/2/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> FAIL   (fi-skl-guc)

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1

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:413s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
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:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:395s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:420s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:504s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:484s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-guc   total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
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:400s

3a86cab5785058d50346e5a26f51dacbaab29c2e drm-tip: 2018y-02m-26d-15h-41m-02s UTC 
integration manifest
3ec4f6230b6a HAX: Enable GuC submission for CI
5c98e654cbd9 drm/i915/guc: Fill preempt context once at init time

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace (rev2)
URL   : https://patchwork.freedesktop.org/series/38981/
State : success

== Summary ==

Series 38981v2 drm/i915: expose RCS topology to userspace
https://patchwork.freedesktop.org/api/1.0/series/38981/revisions/2/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
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:412s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:478s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:474s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:394s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:442s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:444s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:494s
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:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:482s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s

3a86cab5785058d50346e5a26f51dacbaab29c2e drm-tip: 2018y-02m-26d-15h-41m-02s UTC 
integration manifest
8741fc6a687c drm/i915: expose rcs topology through query uAPI
4f183b437578 drm/i915: add query uAPI
3eb82c1d9037 drm/i915: add rcs topology to error state
93b0330bb066 drm/i915/debugfs: add rcs topology entry
3d3c3441aa4b drm/i915/debugfs: reuse max slice/subslices already stored in sseu
b8b75fafc382 drm/i915: store all subslice masks

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: expose RCS topology to userspace (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace (rev2)
URL   : https://patchwork.freedesktop.org/series/38981/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: store all subslice masks
Okay!

Commit: drm/i915/debugfs: reuse max slice/subslices already stored in sseu
-
+drivers/gpu/drm/i915/i915_debugfs.c:4341:29: warning: Variable length array is 
used.
+drivers/gpu/drm/i915/i915_debugfs.c:4342:22: warning: Variable length array is 
used.
+drivers/gpu/drm/i915/i915_debugfs.c:4396:29: warning: Variable length array is 
used.
+drivers/gpu/drm/i915/i915_debugfs.c:4397:22: warning: Variable length array is 
used.

Commit: drm/i915/debugfs: add rcs topology entry
Okay!

Commit: drm/i915: add rcs topology to error state
Okay!

Commit: drm/i915: add query uAPI
+drivers/gpu/drm/i915/i915_query.c:14:5: warning: symbol 'i915_query_ioctl' was 
not declared. Should it be static?

Commit: drm/i915: expose rcs topology through query uAPI
-O:drivers/gpu/drm/i915/i915_query.c:14:5: warning: symbol 'i915_query_ioctl' 
was not declared. Should it be static?
+drivers/gpu/drm/i915/i915_query.c:96:5: warning: symbol 'i915_query_ioctl' was 
not declared. Should it be static?

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

[Intel-gfx] [PATCH] drm/i915/guc: Fill preempt context once at init time

[Chris Wilson]

From: Michał Winiarski 

Since we're inhibiting context save of preempt context, we're no longer
tracking the position of HEAD/TAIL. With GuC, we're adding a new
breadcrumb for each preemption, which means that the HW will do more and
more breadcrumb writes. Eventually the ring is filled, and we're
submitting the preemption context with HEAD==TAIL==0, which won't result
in breadcrumb write, but will trigger hangcheck instead.
Instead of writing a new preempt breadcrumb for each preemption, let's
just fill the ring once at init time (which also saves a couple of
instructions in the tasklet).

v2: Assert that context save restore is inhibited, don't assert on ring
alignment. (Chris)
v3: Cleanup checkpatch.

Fixes: 517aaffe0c1b ("drm/i915/execlists: Inhibit context save/restore for the 
fake preempt context")
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180226163800.21745-1-michal.winiar...@intel.com
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 96 +
 1 file changed, 69 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 586dde579903..8a8ad2fe158d 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -26,8 +26,14 @@
 #include 
 
 #include "intel_guc_submission.h"
+#include "intel_lrc_reg.h"
 #include "i915_drv.h"
 
+#define GUC_PREEMPT_FINISHED   0x1
+#define GUC_PREEMPT_BREADCRUMB_DWORDS  0x8
+#define GUC_PREEMPT_BREADCRUMB_BYTES   \
+   (sizeof(u32) * GUC_PREEMPT_BREADCRUMB_DWORDS)
+
 /**
  * DOC: GuC-based command submission
  *
@@ -535,8 +541,6 @@ static void flush_ggtt_writes(struct i915_vma *vma)
POSTING_READ_FW(GUC_STATUS);
 }
 
-#define GUC_PREEMPT_FINISHED 0x1
-#define GUC_PREEMPT_BREADCRUMB_DWORDS 0x8
 static void inject_preempt_context(struct work_struct *work)
 {
struct guc_preempt_work *preempt_work =
@@ -546,37 +550,17 @@ static void inject_preempt_context(struct work_struct 
*work)
 preempt_work[engine->id]);
struct intel_guc_client *client = guc->preempt_client;
struct guc_stage_desc *stage_desc = __get_stage_desc(client);
-   struct intel_ring *ring = client->owner->engine[engine->id].ring;
u32 ctx_desc = lower_32_bits(intel_lr_context_descriptor(client->owner,
 engine));
-   u32 *cs = ring->vaddr + ring->tail;
u32 data[7];
 
-   if (engine->id == RCS) {
-   cs = gen8_emit_ggtt_write_rcs(cs, GUC_PREEMPT_FINISHED,
-   intel_hws_preempt_done_address(engine));
-   } else {
-   cs = gen8_emit_ggtt_write(cs, GUC_PREEMPT_FINISHED,
-   intel_hws_preempt_done_address(engine));
-   *cs++ = MI_NOOP;
-   *cs++ = MI_NOOP;
-   }
-   *cs++ = MI_USER_INTERRUPT;
-   *cs++ = MI_NOOP;
-
-   GEM_BUG_ON(!IS_ALIGNED(ring->size,
-  GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32)));
-   GEM_BUG_ON((void *)cs - (ring->vaddr + ring->tail) !=
-  GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32));
-
-   ring->tail += GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32);
-   ring->tail &= (ring->size - 1);
-
-   flush_ggtt_writes(ring->vma);
-
+   /*
+* The ring contains commands to write GUC_PREEMPT_FINISHED into HWSP.
+* See guc_fill_preempt_context().
+*/
spin_lock_irq(>wq_lock);
guc_wq_item_append(client, engine->guc_id, ctx_desc,
-  ring->tail / sizeof(u64), 0);
+  GUC_PREEMPT_BREADCRUMB_BYTES / sizeof(u64), 0);
spin_unlock_irq(>wq_lock);
 
/*
@@ -972,6 +956,62 @@ static void guc_client_free(struct intel_guc_client 
*client)
kfree(client);
 }
 
+static inline bool ctx_save_restore_disabled(struct intel_context *ce)
+{
+   u32 sr = ce->lrc_reg_state[CTX_CONTEXT_CONTROL + 1];
+
+#define SR_DISABLED \
+   _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT | \
+  CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT)
+
+   return (sr & SR_DISABLED) == SR_DISABLED;
+
+#undef SR_DISABLED
+}
+
+static void guc_fill_preempt_context(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct intel_guc_client *client = guc->preempt_client;
+   struct intel_engine_cs *engine;
+ 

Re: [Intel-gfx] [PATCH 1/1] drm/i915/skl+: Add and enable DP AUX CH mutex

[Ville Syrjälä]

On Fri, Feb 23, 2018 at 05:51:40PM -0800, José Roberto de Souza wrote:
> When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> self, so lets use the mutex register that is available in gen9+ to
> avoid concurrent access by hardware and driver.
> Older gen handling will be done separated.
> 
> Reference: 
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
> Page 198 - AUX programming sequence
> 
> Cc: Rodrigo Vivi 
> Cc: Jani Nikula 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  9 ++
>  drivers/gpu/drm/i915/intel_dp.c  | 67 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  3 files changed, 77 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index eea5b2c537d4..f36e839b4b4f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5385,6 +5385,15 @@ enum {
>  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
>  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
>  
> +#define _DPA_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6402C)
> +#define _DPB_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6412C)
> +#define _DPC_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6422C)
> +#define _DPD_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6432C)
> +#define _DPF_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6452C)
> +#define DP_AUX_CH_MUTEX(port)_MMIO_PORT(port, _DPA_AUX_CH_MUTEX, 
> _DPB_AUX_CH_MUTEX)
> +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> +
>  /*
>   * Computing GMCH M and N values for the Display Port link
>   *
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2c3eb90b9499..7be2fec51651 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1081,6 +1081,45 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
> intel_dp *intel_dp,
>   aux_clock_divider);
>  }
>  
> +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> + i915_reg_t ch_mutex;
> +
> + if (!intel_dp->aux_ch_mutex_reg)
> + return true;
> +
> + ch_mutex = intel_dp->aux_ch_mutex_reg(intel_dp);
> + I915_WRITE(ch_mutex, DP_AUX_CH_MUTEX_ENABLE);
> +
> + /* Spec says that mutex is acquired when status bit is read as unset,
> +  * here waiting for 2msec or 4 tries before give up.
> +  */
> + if (intel_wait_for_register(dev_priv, ch_mutex, DP_AUX_CH_MUTEX_STATUS,
> + 0, 2)) {
> + DRM_WARN("dp_aux_ch port locked for too long");
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> +
> + if (!intel_dp->aux_ch_mutex_reg)
> + return;
> +
> + /* setting the status bit releases the mutex + keep mutex enabled */
> + I915_WRITE(intel_dp->aux_ch_mutex_reg(intel_dp),
> +DP_AUX_CH_MUTEX_ENABLE | DP_AUX_CH_MUTEX_STATUS);
> +}
> +
>  static int
>  intel_dp_aux_ch(struct intel_dp *intel_dp,
>   const uint8_t *send, int send_bytes,
> @@ -1119,6 +1158,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  
>   intel_dp_check_edp(intel_dp);
>  
> + if (!intel_dp_aux_ch_trylock(intel_dp)) {
> + ret = -EBUSY;
> + goto out_locked;
> + }
> +
>   /* Try to wait for any previous AUX channel activity */
>   for (try = 0; try < 3; try++) {
>   status = I915_READ_NOTRACE(ch_ctl);
> @@ -1248,6 +1292,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  
>   ret = recv_bytes;
>  out:
> + intel_dp_aux_ch_unlock(intel_dp);
> +out_locked:
>   pm_qos_update_request(_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
>  
>   if (vdd)
> @@ -1504,6 +1550,24 @@ static i915_reg_t skl_aux_data_reg(struct intel_dp 
> *intel_dp, int index)
>   }
>  }
>  
> +static i915_reg_t skl_aux_mutex_reg(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> + enum aux_ch aux_ch = intel_dp->aux_ch;
> +
> + switch (aux_ch) {
> + case AUX_CH_A:
> + case AUX_CH_B:
> + case AUX_CH_C:
> + case 

Re: [Intel-gfx] [PATCH 1/1] drm/i915/skl+: Add and enable DP AUX CH mutex

[Souza, Jose]

On Fri, 2018-02-23 at 19:12 -0800, Pandiyan, Dhinakaran wrote:
> On Fri, 2018-02-23 at 17:51 -0800, José Roberto de Souza wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent access by hardware and driver.
> > Older gen handling will be done separated.
> > 
> > Reference: https://01.org/sites/default/files/documentation/intel-g
> > fx-prm-osrc-skl-vol12-display.pdf
> > Page 198 - AUX programming sequence
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  9 ++
> >  drivers/gpu/drm/i915/intel_dp.c  | 67
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  3 files changed, 77 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index eea5b2c537d4..f36e839b4b4f 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5385,6 +5385,15 @@ enum {
> >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> >  
> > +#define _DPA_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6402C)
> > +#define _DPB_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6412C)
> > +#define _DPC_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6422C)
> > +#define _DPD_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6432C)
> > +#define _DPF_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6452C)
> > +#define DP_AUX_CH_MUTEX(port)  _MMIO_PORT(port,
> > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> 
> ^aux_ch similar to ctl and data.
> 
> > +#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
> > +#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
> > +
> >  /*
> >   * Computing GMCH M and N values for the Display Port link
> >   *
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2c3eb90b9499..7be2fec51651 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1081,6 +1081,45 @@ static uint32_t
> > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > aux_clock_divider)
> > ;
> >  }
> >  
> > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(intel_dig_port->base.base.dev);
> > +   i915_reg_t ch_mutex;
> > +
> > +   if (!intel_dp->aux_ch_mutex_reg)
> > +   return true;
> > +
> > +   ch_mutex = intel_dp->aux_ch_mutex_reg(intel_dp);
> > +   I915_WRITE(ch_mutex, DP_AUX_CH_MUTEX_ENABLE);
> 
> 
> > > > 
> > > > You might be touching bits. We don't know if HW is using the
> > > > reserved
> > > > bits or not.
> > > > So RMW |= bit 31 here is a good idea.
> > > 
> > > As a read in this register request the mutex lock is better avoid
> > > any
> > > read that is not meant to request it.
> > 
> > ok... I accept the fact that read that is locking
> > so you are right here.
> > 
> 
> I do not agree with the interpretation here, reading the register
> *after* the mutex is enabled == request for locking. You can read the
> register before enabling, and you have to read so that you don't
> overwrite any other bit.
> 
> Ref: "Sticky bit set to 1 after a read to this register when Mutex is
> enabled."

This is true but we must keep the mutex enabled all the time to
guarantee that hardware will request lock too, so any read to the
register from our side will request the lock.

> 
> 
> > +
> > +   /* Spec says that mutex is acquired when status bit is
> > read as unset,
> > +* here waiting for 2msec or 4 tries before give up.
> 
>2 ms.^ this is not true
> 
> > +*/
> > +   if (intel_wait_for_register(dev_priv, ch_mutex,
> > DP_AUX_CH_MUTEX_STATUS,
> > +   0, 2)) {
> > +   DRM_WARN("dp_aux_ch port locked for too long");
> 
>DRM_DEBUG_KMS("aux channel %c locked for 2 ms, timing
> out\n");
> 
> 1. DRM_DEBUG_KMS is the convention in this file and most parts of the
> driver for things like this.

I'm okay in change I was just using DRM_WARN because most of the
messages in intel_dp_aux_ch() is using it.

> 2. I prefer to add details like port/channel/pipe/connector when
> printing debug messages if it doesn't cost any extra space.
> 
> 
>  
> > +   return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> > +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)

[Intel-gfx] [PATCH v16 1/6] drm/i915: store all subslice masks

[Lionel Landwerlin]

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymmetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

v2: Rework how we store total numbers in sseu_dev_info (Tvrtko)
Fix CHV eu masks, was reading disabled as enabled (Tvrtko)
Readability changes (Tvrtko)
Add EU index helper (Tvrtko)

v3: Turn ALIGN(v, 8) / 8 into DIV_ROUND_UP(v, BITS_PER_BYTE) (Tvrtko)
Reuse sseu_eu_idx() for setting eu_mask on CHV (Tvrtko)
Reformat debug prints for subslices (Tvrtko)

v4: Change eu_mask helper into sseu_set_eus() (Tvrtko)

v5: With Haswell reporting masks & counts, bump sseu_*_eus() functions
to use u16 (Lionel)

v6: Fix sseu_get_eus() for > 8 EUs per subslice (Lionel)

v7: Change debugfs enabels for number of subslices per slice, will
need a small igt/pm_sseu change (Lionel)
Drop subslice_total field from sseu_dev_info, rely on
sseu_subslice_total() to recompute the value instead (Lionel)

v8: Remove unused function compute_subslice_total() (Lionel)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  28 +++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 208 +++
 drivers/gpu/drm/i915/intel_device_info.h |  62 -
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 6 files changed, 237 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 33fbf3965309..8db6d74eb5b1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4322,7 +4322,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4369,7 +4369,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4424,8 +4424,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4435,7 +4435,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4457,9 +4457,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4478,6 +4481,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4485,10 +4489,10 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool 

[Intel-gfx] ✓ Fi.CI.IGT: success for kernel/panic: Repeat the line and caller information at the end of the OOPS (rev2)

[Patchwork]

== Series Details ==

Series: kernel/panic: Repeat the line and caller information at the end of the 
OOPS (rev2)
URL   : https://patchwork.freedesktop.org/series/38962/
State : success

== Summary ==

 Possible new issues:

Test pm_rc6_residency:
Subgroup rc6-accuracy:
skip   -> PASS   (shard-snb)

 Known issues:

Test kms_flip:
Subgroup 2x-flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Subgroup flip-vs-panning-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:8   skip:1632 
time:12115s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11779s
shard-snbtotal:3460 pass:1359 dwarn:2   dfail:0   fail:1   skip:2098 
time:6641s
Blacklisted hosts:
shard-kbltotal:3393 pass:1909 dwarn:1   dfail:0   fail:7   skip:1475 
time:9037s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/guc: Fill preempt context once at init time

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: Fill preempt context once at 
init time
URL   : https://patchwork.freedesktop.org/series/38964/
State : success

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-blt:
pass   -> FAIL   (shard-apl) fdo#101623
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3434 pass:1793 dwarn:2   dfail:0   fail:16  skip:1621 
time:12059s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11691s
shard-snbtotal:3558 pass:1392 dwarn:1   dfail:0   fail:2   skip:2163 
time:6839s
Blacklisted hosts:
shard-kbltotal:3258 pass:1808 dwarn:2   dfail:1   fail:15  skip:1429 
time:8828s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: expose RCS topology to userspace

[Patchwork]

== Series Details ==

Series: drm/i915: expose RCS topology to userspace
URL   : https://patchwork.freedesktop.org/series/38981/
State : failure

== Summary ==

CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_device_info.o
drivers/gpu/drm/i915/intel_device_info.c:162:12: error: 
‘compute_subslice_total’ defined but not used [-Werror=unused-function]
 static u16 compute_subslice_total(const struct sseu_dev_info *sseu)
^~
cc1: all warnings being treated as errors
scripts/Makefile.build:316: recipe for target 
'drivers/gpu/drm/i915/intel_device_info.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_device_info.o] Error 1
scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:575: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1048: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:39PM +0530, Ramalingam C wrote:
> DP and HDMI HDCP specifications are varying with respect to
> detecting the R0 and ksv_fifo availability.
> 
> DP will produce CP_IRQ and set a bit for indicating the R0 and
> FIFO_READY status.

I'm not sure what the benefit is? Keeping things common was a deliberate
decision on my part to keep complexity down and increase the amount of common
code.

Sean

> 
> Whereas HDMI will set a bit for FIFO_READY but there is no bit
> indication for R0 ready. And also polling of READY bit is needed for
> HDMI as ther is no CP_IRQ.
> 
> So Fielding the CP_IRQ for DP and the polling the READY bit for a
> period and blindly waiting for a fixed time for R0 incase of HDMI are
> moved into corresponding hdcp_shim.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 70 
> +++
>  drivers/gpu/drm/i915/intel_drv.h  |  6 ++--
>  drivers/gpu/drm/i915/intel_hdcp.c | 39 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 28 +++-
>  4 files changed, 98 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2c3eb90b9499..afe310a91d3c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4436,6 +4436,7 @@ static bool
>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> + struct intel_connector *connector = intel_dp->attached_connector;
>   u8 sink_irq_vector = 0;
>   u8 old_sink_count = intel_dp->sink_count;
>   bool ret;
> @@ -4470,8 +4471,11 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>  
>   if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
>   intel_dp_handle_test_request(intel_dp);
> - if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
> - DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
> + if (sink_irq_vector & DP_CP_IRQ)
> + if (connector->hdcp_shim)
> + complete_all(>cp_irq_recved);
> + if (sink_irq_vector & DP_SINK_SPECIFIC_IRQ)
> + DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
>   }
>  
>   intel_dp_check_link_status(intel_dp);
> @@ -5083,6 +5087,25 @@ void intel_dp_encoder_suspend(struct intel_encoder 
> *intel_encoder)
>   pps_unlock(intel_dp);
>  }
>  
> +static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
> +  int timeout)
> +{
> + long ret;
> +
> + if (completion_done(cp_irq_recved))
> + reinit_completion(cp_irq_recved);
> +
> + ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
> + msecs_to_jiffies(
> + timeout));
> + reinit_completion(cp_irq_recved);
> + if (ret < 0)
> + return (int)ret;
> + else if (!ret)
> + return -ETIMEDOUT;
> + return 0;
> +}
> +
>  static
>  int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
>   u8 *an)
> @@ -5188,11 +5211,38 @@ int intel_dp_hdcp_repeater_present(struct 
> intel_digital_port *intel_dig_port,
>   return 0;
>  }
>  
> +static int intel_dp_hdcp_wait_for_r0(struct intel_digital_port 
> *intel_dig_port)
> +{
> + struct intel_dp *dp = _dig_port->dp;
> + struct intel_connector *connector = dp->attached_connector;
> + int ret;
> + u8 bstatus;
> +
> + intel_dp_hdcp_wait_for_cp_irq(>cp_irq_recved, 100);
> +
> + ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
> +, 1);
> + if (ret != 1) {
> + DRM_ERROR("Read bstatus from DP/AUX failed (%d)\n", ret);
> + return ret >= 0 ? -EIO : ret;
> + }
> +
> + if (!(bstatus & DP_BSTATUS_R0_PRIME_READY))
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
>  static
>  int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
>   u8 *ri_prime)
>  {
>   ssize_t ret;
> +
> + ret = intel_dp_hdcp_wait_for_r0(intel_dig_port);
> + if (!ret)
> + return ret;
> +
>   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_RI_PRIME,
>  ri_prime, DRM_HDCP_RI_LEN);
>   if (ret != DRM_HDCP_RI_LEN) {
> @@ -5203,18 +5253,26 @@ int intel_dp_hdcp_read_ri_prime(struct 
> intel_digital_port *intel_dig_port,
>  }
>  
>  static
> -int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
> -  bool *ksv_ready)
> +int intel_dp_hdcp_ksv_ready(struct intel_digital_port *intel_dig_port)
>  {
> + struct intel_dp *dp = _dig_port->dp;
> + struct 

[Intel-gfx] [PATCH v15 5/6] drm/i915: add query uAPI

[Lionel Landwerlin]

There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

v2: Simplify dispatcher code iteration (Tvrtko)
Tweak uapi drm_i915_query_item structure (Tvrtko)

v3: Rename pad fields into flags (Chris)
Return error on flags field != 0 (Chris)
Only copy length back to userspace in drm_i915_query_item (Chris)

v4: Use array of functions instead of switch (Chris)

v5: More comments in uapi (Tvrtko)
Return query item errors in length field (All)

v6: Tweak uapi comments style to match the coding style (Lionel)

v7: Add i915_query.h (Joonas)

v8: (Lionel) Change the behavior of the item iterator to report
invalid queries into the query item rather than stopping the
iteration. This enables userspace applications to query newer
items on older kernels and only have failure on the items that are
not supported.

v9: Edit copyright headers (Joonas)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile |  1 +
 drivers/gpu/drm/i915/i915_drv.c   |  2 ++
 drivers/gpu/drm/i915/i915_query.c | 49 +++
 drivers/gpu/drm/i915/i915_query.h | 15 
 include/uapi/drm/i915_drm.h   | 40 
 5 files changed, 107 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c
 create mode 100644 drivers/gpu/drm/i915/i915_query.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 881d7124c597..fa9e7fdb9fd0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
+ i915_query.o \
  i915_request.o \
  i915_trace_points.o \
  i915_vma.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 655a072290e3..73d8c5f869e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "i915_pmu.h"
+#include "i915_query.h"
 #include "i915_vgpu.h"
 #include "intel_drv.h"
 #include "intel_uc.h"
@@ -2832,6 +2833,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
new file mode 100644
index ..c23bfc9be617
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -0,0 +1,49 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include "i915_drv.h"
+#include 
+
+static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item) 
= {
+};
+
+int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_query *args = data;
+   struct drm_i915_query_item __user *user_item_ptr =
+   u64_to_user_ptr(args->items_ptr);
+   u32 i;
+
+   if (args->flags != 0)
+   return -EINVAL;
+
+   for (i = 0; i < args->num_items; i++, user_item_ptr++) {
+   struct drm_i915_query_item item;
+   u64 func_idx;
+   int ret;
+
+   if (copy_from_user(, user_item_ptr, sizeof(item)))
+   return -EFAULT;
+
+   if 

[Intel-gfx] [PATCH v15 0/6] drm/i915: expose RCS topology to userspace

[Lionel Landwerlin]

Hi all,

Here is another update to fix a couple of bugs in the first patch :

 - HSW was reporting the eu masks incorrectly

 - debugfs was reporting incorrect subslice numbers (and failing
   igt@pm_sseu), the igt has been update to handle kernels before and
   after this series.

Cheers,

Lionel Landwerlin (6):
  drm/i915: store all subslice masks
  drm/i915/debugfs: reuse max slice/subslices already stored in sseu
  drm/i915/debugfs: add rcs topology entry
  drm/i915: add rcs topology to error state
  drm/i915: add query uAPI
  drm/i915: expose rcs topology through query uAPI

 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  66 +
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c|   1 +
 drivers/gpu/drm/i915/i915_query.c| 131 +
 drivers/gpu/drm/i915/i915_query.h|  15 ++
 drivers/gpu/drm/i915/intel_device_info.c | 243 ---
 drivers/gpu/drm/i915/intel_device_info.h |  64 +++-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 include/uapi/drm/i915_drm.h  | 102 +
 11 files changed, 548 insertions(+), 83 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c
 create mode 100644 drivers/gpu/drm/i915/i915_query.h

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

[Intel-gfx] [PATCH v15 6/6] drm/i915: expose rcs topology through query uAPI

[Lionel Landwerlin]

With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

The Mesa series making use of this API is :

https://patchwork.freedesktop.org/series/38795/

As a bonus we can draw representations of the GPU :

https://imgur.com/a/vuqpa

v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko)
Add uapi macros to read data from *_info structs (Tvrtko)

v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom shifts (Tvrtko)

v4: factorize query item writting (Tvrtko)
tweak uapi struct/define names (Tvrtko)

v5: Replace ALIGN() macro (Chris)

v6: Updated uapi comments (Tvrtko)
Moved flags != 0 checks into vfuncs (Tvrtko)

v7: Use access_ok() before copying anything, to avoid overflows (Chris)
Switch BUG_ON() to GEM_WARN_ON() (Tvrtko)

v8: Tweak uapi comments style to match the coding style (Lionel)

v9: Fix error in comment about computation of enabled subslice (Tvrtko)

v10: Fix/update comments in uAPI (Sagar)

v11: Drop drm_i915_query_(slice|subslice|eu)_info in favor of a single
 drm_i915_query_topology_info (Joonas)

v12: Add subslice_stride/eu_stride in drm_i915_query_topology_info (Joonas)

Signed-off-by: Lionel Landwerlin 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_query.c | 82 +++
 include/uapi/drm/i915_drm.h   | 62 +
 2 files changed, 144 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index c23bfc9be617..2f11fabb6aff 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -7,8 +7,90 @@
 #include "i915_drv.h"
 #include 
 
+static int query_topology_info(struct drm_i915_private *dev_priv,
+  struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_topology_info topo_info;
+   u32 slice_length, subslice_length, eu_length, total_length;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   /*
+* If we ever change the internal slice mask data type, we'll need to
+* update this function.
+*/
+   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
+
+   slice_length = sizeof(sseu->slice_mask);
+   subslice_length = sseu->max_slices *
+   DIV_ROUND_UP(sseu->max_subslices,
+sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE);
+   eu_length = sseu->max_slices * sseu->max_subslices *
+   DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE);
+
+   total_length = sizeof(topo_info) + slice_length + subslice_length + 
eu_length;
+
+   if (query_item->length == 0)
+   return total_length;
+
+   if (query_item->length < total_length)
+   return -EINVAL;
+
+   if (copy_from_user(_info, u64_to_user_ptr(query_item->data_ptr),
+  sizeof(topo_info)))
+   return -EFAULT;
+
+   if (topo_info.flags != 0)
+   return -EINVAL;
+
+   if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr),
+  total_length))
+   return -EFAULT;
+
+   memset(_info, 0, sizeof(topo_info));
+   topo_info.max_slices = sseu->max_slices;
+   topo_info.max_subslices = sseu->max_subslices;
+   topo_info.max_eus_per_subslice = sseu->max_eus_per_subslice;
+
+   topo_info.subslice_offset = slice_length;
+   topo_info.subslice_stride = DIV_ROUND_UP(sseu->max_subslices,
+BITS_PER_BYTE);
+   topo_info.eu_offset = slice_length + subslice_length;
+   topo_info.eu_stride = DIV_ROUND_UP(sseu->max_eus_per_subslice,
+  BITS_PER_BYTE);
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+  _info, sizeof(topo_info)))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+  sizeof(topo_info)),
+  >slice_mask, slice_length))
+   return -EFAULT;
+
+   if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+  sizeof(topo_info) +
+  

[Intel-gfx] [PATCH v15 4/6] drm/i915: add rcs topology to error state

[Lionel Landwerlin]

This might be useful information for developers looking at an error
state.

v2: Place topology towards the end of the error state (Chris)

v3: Reuse common printing code (Michal)

v4: Make this a one-liner (Chris)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a7933c9b5562..87ca860ac9f2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -586,6 +586,7 @@ static void err_print_capabilities(struct 
drm_i915_error_state_buf *m,
 
intel_device_info_dump_flags(info, );
intel_driver_caps_print(caps, );
+   intel_device_info_dump_topology(>sseu, );
 }
 
 static void err_print_params(struct drm_i915_error_state_buf *m,
-- 
2.16.1

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

[Intel-gfx] [PATCH v15 1/6] drm/i915: store all subslice masks

[Lionel Landwerlin]

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymmetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

v2: Rework how we store total numbers in sseu_dev_info (Tvrtko)
Fix CHV eu masks, was reading disabled as enabled (Tvrtko)
Readability changes (Tvrtko)
Add EU index helper (Tvrtko)

v3: Turn ALIGN(v, 8) / 8 into DIV_ROUND_UP(v, BITS_PER_BYTE) (Tvrtko)
Reuse sseu_eu_idx() for setting eu_mask on CHV (Tvrtko)
Reformat debug prints for subslices (Tvrtko)

v4: Change eu_mask helper into sseu_set_eus() (Tvrtko)

v5: With Haswell reporting masks & counts, bump sseu_*_eus() functions
to use u16 (Lionel)

v6: Fix sseu_get_eus() for > 8 EUs per subslice (Lionel)

v7: Change debugfs enabels for number of subslices per slice, will
need a small igt/pm_sseu change (Lionel)
Drop subslice_total field from sseu_dev_info, rely on
sseu_subslice_total() to recompute the value instead (Lionel)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  28 ++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 218 +++
 drivers/gpu/drm/i915/intel_device_info.h |  62 -
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 6 files changed, 247 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 33fbf3965309..8db6d74eb5b1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4322,7 +4322,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4369,7 +4369,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4424,8 +4424,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4435,7 +4435,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4457,9 +4457,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4478,6 +4481,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4485,10 +4489,10 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));

[Intel-gfx] [PATCH v15 3/6] drm/i915/debugfs: add rcs topology entry

[Lionel Landwerlin]

While the end goal is to make this information available to userspace
through a new ioctl, there is no reason we can't display it in a human
readable fashion through debugfs.

slice0: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice1: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice2: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)

v2: Reformat debugfs printing (Tvrtko)
Use the new EU mask helper (Tvrtko)

v3: Move printing code to intel_device_info.c to be shared with error
state (Michal)

v4: Bump u8 to u16 when using sseu_get_eus() (Lionel)

Suggested-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 11 +++
 drivers/gpu/drm/i915/intel_device_info.c | 25 +
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f232a396eb49..bc25f4a337c3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3201,6 +3201,16 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_rcs_topology(struct seq_file *m, void *unused)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct drm_printer p = drm_seq_file_printer(m);
+
+   intel_device_info_dump_topology(_INFO(dev_priv)->sseu, );
+
+   return 0;
+}
+
 static int i915_shrinker_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *i915 = node_to_i915(m->private);
@@ -4732,6 +4742,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_dmc_info", i915_dmc_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_engine_info", i915_engine_info, 0},
+   {"i915_rcs_topology", i915_rcs_topology, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index e9ea421f..0841dab2a810 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -124,6 +124,31 @@ void intel_device_info_dump(const struct intel_device_info 
*info,
intel_device_info_dump_flags(info, p);
 }
 
+void intel_device_info_dump_topology(const struct sseu_dev_info *sseu,
+struct drm_printer *p)
+{
+   int s, ss;
+
+   if (sseu->max_slices == 0) {
+   drm_printf(p, "Unavailable\n");
+   return;
+   }
+
+   for (s = 0; s < sseu->max_slices; s++) {
+   drm_printf(p, "slice%d: %u subslice(s) (0x%hhx):\n",
+  s, hweight8(sseu->subslice_mask[s]),
+  sseu->subslice_mask[s]);
+
+   for (ss = 0; ss < sseu->max_subslices; ss++) {
+   u16 enabled_eus = sseu_get_eus(sseu, s, ss);
+
+   drm_printf(p, "\tsubslice%d: %u EUs (0x%hx)\n",
+  ss, hweight16(enabled_eus), enabled_eus);
+   }
+   }
+}
+
+
 static u16 compute_eu_total(const struct sseu_dev_info *sseu)
 {
u16 i, total = 0;
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 6f65d8f0ac89..9542e3b64443 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -241,6 +241,8 @@ void intel_device_info_dump_flags(const struct 
intel_device_info *info,
  struct drm_printer *p);
 void intel_device_info_dump_runtime(const struct intel_device_info *info,
struct drm_printer *p);
+void intel_device_info_dump_topology(const struct sseu_dev_info *sseu,
+struct drm_printer *p);
 
 void intel_driver_caps_print(const struct intel_driver_caps *caps,
 struct drm_printer *p);
-- 
2.16.1

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

[Intel-gfx] [PATCH v15 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

Now that we have that information in topology fields, let's just reuse it.

v2: Style tweaks (Tvrtko)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 27 +++
 drivers/gpu/drm/i915/intel_device_info.c |  2 +-
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8db6d74eb5b1..f232a396eb49 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4337,11 +4337,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4363,7 +4363,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4371,7 +4371,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4391,17 +4391,12 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4416,7 +4411,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4427,7 +4422,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslice_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 7a5de8f302fd..e9ea421f 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -318,7 +318,7 @@ static void gen9_sseu_info_init(struct drm_i915_private 
*dev_priv)
/* skip disabled subslice */
continue;
 
-   eu_disabled_mask = (eu_disable >> (ss*8)) & eu_mask;
+   eu_disabled_mask = (eu_disable >> (ss * 8)) & eu_mask;
 
sseu_set_eus(sseu, s, ss, ~eu_disabled_mask);
 
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:38PM +0530, Ramalingam C wrote:
> In a connected state, If a HDMI HDCP sink is responded with NACK for
> HDCP I2C register access, then HDMI HDCP spec mandates the polling
> of any HDCP space registers for accessibility, minimum once in 2Secs
> atleast for 4Secs.
> 

I'm not convinced this is the right place to do this. 

The reason is that this is more complex than how you have it below. You can't
access state outside of check/commit, so polling state->content_protection is
not permissable from check_link. If the check fails, the driver will change the
current value of content_protection, so userspace will be able to retry.

In the case of enable, since it's synchronous, the error will be propagated to
userspace and it can retry if that's the right thing to do.

Sean

> Just to make it simple, this is generically implemented for both HDMI
> and DP. But we dont expect that this scanario will occur for DP.
> 
> HDMI HDCP CTS Tests: 1A-04 and 1A-07A.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 74 
> +++
>  1 file changed, 67 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 95081aaa832a..14be14a45e5a 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -16,6 +16,47 @@
>  
>  #define KEY_LOAD_TRIES   5
>  
> +static
> +struct intel_digital_port *conn_to_dig_port(struct intel_connector 
> *connector)
> +{
> + return enc_to_dig_port(_attached_encoder(>base)->base);
> +}
> +
> +static inline bool hdcp_port_accessible(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + int ret = -ENXIO;
> + u8 bksv[DRM_HDCP_KSV_LEN];
> +
> + ret = connector->hdcp_shim->read_bksv(intel_dig_port, bksv);
> + if (!ret)
> + return true;
> + return false;
> +}
> +
> +static bool wait_for_hdcp_port(struct intel_connector *connector)
> +{
> + int i, tries = 10;
> +
> + for (i = 0; i < tries; i++) {
> + if (connector->base.status != connector_status_connected ||
> + connector->base.state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
> + connector->hdcp_value ==
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + return false;
> +
> + if (hdcp_port_accessible(connector))
> + break;
> +
> + msleep_interruptible(500);
> + }
> +
> + if (i == tries)
> + return false;
> + return true;
> +}
> +
>  static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port 
> *intel_dig_port,
>   const struct intel_hdcp_shim *shim)
>  {
> @@ -584,12 +625,6 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   return 0;
>  }
>  
> -static
> -struct intel_digital_port *conn_to_dig_port(struct intel_connector 
> *connector)
> -{
> - return enc_to_dig_port(_attached_encoder(>base)->base);
> -}
> -
>  static int _intel_hdcp_disable(struct intel_connector *connector)
>  {
>   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
> @@ -719,14 +754,26 @@ int intel_hdcp_init(struct intel_connector *connector,
>  
>  int intel_hdcp_enable(struct intel_connector *connector)
>  {
> - int ret;
> + int ret, tries = 2;
>  
>   if (!connector->hdcp_shim)
>   return -ENOENT;
>  
>   mutex_lock(>hdcp_mutex);
>  
> +enable_hdcp:
>   ret = _intel_hdcp_enable(connector);
> +
> + /*
> +  * Suddenly if sink is NACK-ed for the access of HDCP
> +  * registers, but display is still connected, poll for hdcp
> +  * port accessibility. One of the HDCP spec requirement.
> +  */
> + if ((ret == -EIO || ret == -ENXIO) &&
> + connector->base.status == connector_status_connected &&
> + !hdcp_port_accessible(connector))
> + if (wait_for_hdcp_port(connector) && --tries)
> + goto enable_hdcp;
>   if (ret)
>   goto out;
>  
> @@ -838,6 +885,19 @@ int intel_hdcp_check_link(struct intel_connector 
> *connector)
>   goto out;
>   }
>  
> + /*
> +  * Suddenly if sink is NACK-ed for the access of HDCP
> +  * registers, but display is still connected, poll for hdcp
> +  * port accessibility. One of the HDCP spec requirement.
> +  */
> + if (connector->base.status == connector_status_connected &&
> + !hdcp_port_accessible(connector)) {
> + mutex_unlock(>hdcp_mutex);
> + if (!wait_for_hdcp_port(connector))
> + return ret;
> + mutex_lock(>hdcp_mutex);
> + }
> +
>   ret = _intel_hdcp_enable(connector);
>   if (ret) {
>   DRM_ERROR("Failed 

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Check hdcp key loadability

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:37PM +0530, Ramalingam C wrote:
> HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
> is enabled. Using the I915 power well infrastruture, above requirement
> is verified.
> 
> This patch enables the hdcp initialization for HSW, BDW, and BXT.
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 7ea55fa46f41..95081aaa832a 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -37,6 +37,33 @@ static int intel_hdcp_poll_ksv_fifo(struct 
> intel_digital_port *intel_dig_port,
>   return 0;
>  }
>  
> +static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
> +{
> + struct i915_power_domains *power_domains = _priv->power_domains;
> + struct i915_power_well *power_well;
> + bool enabled = false;
> +
> + mutex_lock(_domains->lock);
> +
> + /* PG1 (power well #1) needs to be enabled */
> + for_each_power_well(dev_priv, power_well) {
> + if (power_well->id == SKL_DISP_PW_1) {
> + enabled = power_well->ops->is_enabled(dev_priv,
> +   power_well);
> + break;
> + }
> + }
> + mutex_unlock(_domains->lock);
> +
> + /*
> +  * Another req for hdcp key loadability is enabled state of pll for
> +  * cdclk. Without active crtc we wont land here. So we are assuming that
> +  * cdclk is already on.
> +  */
> +
> + return enabled;
> +}
> +
>  static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
>  {
>   I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
> @@ -598,8 +625,8 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
>   DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
> connector->base.name, connector->base.base.id);
>  
> - if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
> - DRM_ERROR("PG1 is disabled, cannot load keys\n");
> + if (!hdcp_key_loadable(dev_priv)) {
> + DRM_ERROR("HDCP key Load is not possible\n");
>   return -ENXIO;
>   }
>  
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP1.4 fixes

[Patchwork]

== Series Details ==

Series: HDCP1.4 fixes
URL   : https://patchwork.freedesktop.org/series/38978/
State : success

== Summary ==

Series 38978v1 HDCP1.4 fixes
https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
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:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:119  pass:107  dwarn:0   dfail:0   fail:0   skip:12 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:388s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:410s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:502s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:594s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s

3a86cab5785058d50346e5a26f51dacbaab29c2e drm-tip: 2018y-02m-26d-15h-41m-02s UTC 
integration manifest
b398f39b1428 drm/i915: Move hdcp msg detection into shim
e107fd3bb4fb drm/i915: Poll hdcp register on sudden NACK
39fc6362ea03 drm/i915: Check hdcp key loadability
58a427113d28 drm/i915: read Vprime thrice incase of mismatch
17d5b4718d50 drm/i915: Read HDCP R0 thrice in case of mismatch

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: read Vprime thrice incase of mismatch

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:36PM +0530, Ramalingam C wrote:
> In case of V prime mismatch, DP HDCP spec mandates the re-read of
> Vprime atleast twice.
> 
> DP HDCP CTS Test: 1B-05
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 730681d2dbfb..7ea55fa46f41 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -150,7 +150,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   struct drm_i915_private *dev_priv;
>   u32 vprime, sha_text, sha_leftovers, rep_ctl;
>   u8 bstatus[2], num_downstream, *ksv_fifo;
> - int ret, i, j, sha_idx;
> + int ret, i, j, sha_idx, tries = 3;
>  
>   dev_priv = intel_dig_port->base.base.dev->dev_private;
>  
> @@ -189,6 +189,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   if (ret)
>   return ret;
>  
> +read_v_prime:

Instead of using the label for retry, please break it out into a function that's
enclosed in a retry loop.

Sean

>   /* Process V' values from the receiver */
>   for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
>   ret = shim->read_v_prime_part(intel_dig_port, i, );
> @@ -385,6 +386,13 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   return -ETIMEDOUT;
>   }
>   if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
> +
> + /*
> +  * When V prime mismatches, DP Spec mandates re-read of
> +  * V prime atleast twice.
> +  */
> + if (--tries)
> + goto read_v_prime;
>   DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
>   return -ENXIO;
>   }
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:35PM +0530, Ramalingam C wrote:
> As per DP spec when R0 mismatch is detected, HDCP source supported
> re-read the R0 atleast twice.
> 
> And For HDMI and DP minimum wait required for the R0 availability is
> 100mSec. So this patch changes the wait time to 100mSec but retries
> twice with the time interval of 100mSec for each attempt.

"R0' must be available for the HDCP Transmitter to read within 100
milliseconds from the time that the HDCP Transmitter finishes writing Aksv to
the video receiver."

100ms is a minimum, waiting for 300ms is quite generous.

The retry is to account for link errors, so there's no need to include the wait
in the retry loop.

Sean

> 
> DP CTS Test: 1A-06.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 14ca5d3057a7..730681d2dbfb 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -496,25 +496,35 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   }
>  
>   /*
> -  * Wait for R0' to become available. The spec says 100ms from Aksv, but
> -  * some monitors can take longer than this. We'll set the timeout at
> -  * 300ms just to be sure.
> +  * Wait for R0' to become available. The spec says minimum 100ms from
> +  * Aksv, but some monitors can take longer than this. So we are
> +  * combinely waiting for 300mSec just to be sure in case of HDMI.
> +  * DP HDCP Spec mandates the two more reattempt to read R0, incase
> +  * of R0 mismatch.
>*
>* On DP, there's an R0_READY bit available but no such bit
>* exists on HDMI. Since the upper-bound is the same, we'll just do
>* the stupid thing instead of polling on one and not the other.
>*/
> - wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
>  
> - ri.reg = 0;
> - ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> - if (ret)
> - return ret;
> - I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
> + tries = 3;
> + for (i = 0; i < tries; i++) {
> + wait_remaining_ms_from_jiffies(r0_prime_gen_start,
> +100 * (i + 1));
>  
> - /* Wait for Ri prime match */
> - if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> -  (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
> + ri.reg = 0;
> + ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> + if (ret)
> + return ret;
> + I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
> +
> + /* Wait for Ri prime match */
> + if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> + (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
> + break;
> + }
> +
> + if (i == tries) {
>   DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
> I915_READ(PORT_HDCP_STATUS(port)));
>   return -ETIMEDOUT;
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/guc: Fill preempt context once at init time

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/guc: Fill preempt context once 
at init time
URL   : https://patchwork.freedesktop.org/series/38975/
State : success

== Summary ==

Series 38975v1 series starting with [v2,1/2] drm/i915/guc: Fill preempt context 
once at init time
https://patchwork.freedesktop.org/api/1.0/series/38975/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
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:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
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:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:410s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:384s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:515s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:401s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:519s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:389s

3a86cab5785058d50346e5a26f51dacbaab29c2e drm-tip: 2018y-02m-26d-15h-41m-02s UTC 
integration manifest
95e97fb11f9f HAX: Enable GuC submission for CI
9580b714e474 drm/i915/guc: Fill preempt context once at init time

== Logs ==

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

[Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Ramalingam C]

DP and HDMI HDCP specifications are varying with respect to
detecting the R0 and ksv_fifo availability.

DP will produce CP_IRQ and set a bit for indicating the R0 and
FIFO_READY status.

Whereas HDMI will set a bit for FIFO_READY but there is no bit
indication for R0 ready. And also polling of READY bit is needed for
HDMI as ther is no CP_IRQ.

So Fielding the CP_IRQ for DP and the polling the READY bit for a
period and blindly waiting for a fixed time for R0 incase of HDMI are
moved into corresponding hdcp_shim.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_dp.c   | 70 +++
 drivers/gpu/drm/i915/intel_drv.h  |  6 ++--
 drivers/gpu/drm/i915/intel_hdcp.c | 39 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 28 +++-
 4 files changed, 98 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c3eb90b9499..afe310a91d3c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4436,6 +4436,7 @@ static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
+   struct intel_connector *connector = intel_dp->attached_connector;
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
bool ret;
@@ -4470,8 +4471,11 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 
if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
intel_dp_handle_test_request(intel_dp);
-   if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
-   DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
+   if (sink_irq_vector & DP_CP_IRQ)
+   if (connector->hdcp_shim)
+   complete_all(>cp_irq_recved);
+   if (sink_irq_vector & DP_SINK_SPECIFIC_IRQ)
+   DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
}
 
intel_dp_check_link_status(intel_dp);
@@ -5083,6 +5087,25 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
 }
 
+static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
+int timeout)
+{
+   long ret;
+
+   if (completion_done(cp_irq_recved))
+   reinit_completion(cp_irq_recved);
+
+   ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
+   msecs_to_jiffies(
+   timeout));
+   reinit_completion(cp_irq_recved);
+   if (ret < 0)
+   return (int)ret;
+   else if (!ret)
+   return -ETIMEDOUT;
+   return 0;
+}
+
 static
 int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5188,11 +5211,38 @@ int intel_dp_hdcp_repeater_present(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
+static int intel_dp_hdcp_wait_for_r0(struct intel_digital_port *intel_dig_port)
+{
+   struct intel_dp *dp = _dig_port->dp;
+   struct intel_connector *connector = dp->attached_connector;
+   int ret;
+   u8 bstatus;
+
+   intel_dp_hdcp_wait_for_cp_irq(>cp_irq_recved, 100);
+
+   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
+  , 1);
+   if (ret != 1) {
+   DRM_ERROR("Read bstatus from DP/AUX failed (%d)\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+
+   if (!(bstatus & DP_BSTATUS_R0_PRIME_READY))
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
 static
 int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
u8 *ri_prime)
 {
ssize_t ret;
+
+   ret = intel_dp_hdcp_wait_for_r0(intel_dig_port);
+   if (!ret)
+   return ret;
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_RI_PRIME,
   ri_prime, DRM_HDCP_RI_LEN);
if (ret != DRM_HDCP_RI_LEN) {
@@ -5203,18 +5253,26 @@ int intel_dp_hdcp_read_ri_prime(struct 
intel_digital_port *intel_dig_port,
 }
 
 static
-int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
-bool *ksv_ready)
+int intel_dp_hdcp_ksv_ready(struct intel_digital_port *intel_dig_port)
 {
+   struct intel_dp *dp = _dig_port->dp;
+   struct intel_connector *connector = dp->attached_connector;
ssize_t ret;
u8 bstatus;
+
+   intel_dp_hdcp_wait_for_cp_irq(>cp_irq_recved,
+ 5 * 1000 * 1000);
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
   , 1);
if (ret != 1) {
DRM_ERROR("Read bstatus 

[Intel-gfx] [PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK

[Ramalingam C]

In a connected state, If a HDMI HDCP sink is responded with NACK for
HDCP I2C register access, then HDMI HDCP spec mandates the polling
of any HDCP space registers for accessibility, minimum once in 2Secs
atleast for 4Secs.

Just to make it simple, this is generically implemented for both HDMI
and DP. But we dont expect that this scanario will occur for DP.

HDMI HDCP CTS Tests: 1A-04 and 1A-07A.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 74 +++
 1 file changed, 67 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 95081aaa832a..14be14a45e5a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -16,6 +16,47 @@
 
 #define KEY_LOAD_TRIES 5
 
+static
+struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector)
+{
+   return enc_to_dig_port(_attached_encoder(>base)->base);
+}
+
+static inline bool hdcp_port_accessible(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   int ret = -ENXIO;
+   u8 bksv[DRM_HDCP_KSV_LEN];
+
+   ret = connector->hdcp_shim->read_bksv(intel_dig_port, bksv);
+   if (!ret)
+   return true;
+   return false;
+}
+
+static bool wait_for_hdcp_port(struct intel_connector *connector)
+{
+   int i, tries = 10;
+
+   for (i = 0; i < tries; i++) {
+   if (connector->base.status != connector_status_connected ||
+   connector->base.state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+   connector->hdcp_value ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   return false;
+
+   if (hdcp_port_accessible(connector))
+   break;
+
+   msleep_interruptible(500);
+   }
+
+   if (i == tries)
+   return false;
+   return true;
+}
+
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
 {
@@ -584,12 +625,6 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static
-struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector)
-{
-   return enc_to_dig_port(_attached_encoder(>base)->base);
-}
-
 static int _intel_hdcp_disable(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
@@ -719,14 +754,26 @@ int intel_hdcp_init(struct intel_connector *connector,
 
 int intel_hdcp_enable(struct intel_connector *connector)
 {
-   int ret;
+   int ret, tries = 2;
 
if (!connector->hdcp_shim)
return -ENOENT;
 
mutex_lock(>hdcp_mutex);
 
+enable_hdcp:
ret = _intel_hdcp_enable(connector);
+
+   /*
+* Suddenly if sink is NACK-ed for the access of HDCP
+* registers, but display is still connected, poll for hdcp
+* port accessibility. One of the HDCP spec requirement.
+*/
+   if ((ret == -EIO || ret == -ENXIO) &&
+   connector->base.status == connector_status_connected &&
+   !hdcp_port_accessible(connector))
+   if (wait_for_hdcp_port(connector) && --tries)
+   goto enable_hdcp;
if (ret)
goto out;
 
@@ -838,6 +885,19 @@ int intel_hdcp_check_link(struct intel_connector 
*connector)
goto out;
}
 
+   /*
+* Suddenly if sink is NACK-ed for the access of HDCP
+* registers, but display is still connected, poll for hdcp
+* port accessibility. One of the HDCP spec requirement.
+*/
+   if (connector->base.status == connector_status_connected &&
+   !hdcp_port_accessible(connector)) {
+   mutex_unlock(>hdcp_mutex);
+   if (!wait_for_hdcp_port(connector))
+   return ret;
+   mutex_lock(>hdcp_mutex);
+   }
+
ret = _intel_hdcp_enable(connector);
if (ret) {
DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch

[Ramalingam C]

As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.

And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.

DP CTS Test: 1A-06.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..730681d2dbfb 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -496,25 +496,35 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
}
 
/*
-* Wait for R0' to become available. The spec says 100ms from Aksv, but
-* some monitors can take longer than this. We'll set the timeout at
-* 300ms just to be sure.
+* Wait for R0' to become available. The spec says minimum 100ms from
+* Aksv, but some monitors can take longer than this. So we are
+* combinely waiting for 300mSec just to be sure in case of HDMI.
+* DP HDCP Spec mandates the two more reattempt to read R0, incase
+* of R0 mismatch.
 *
 * On DP, there's an R0_READY bit available but no such bit
 * exists on HDMI. Since the upper-bound is the same, we'll just do
 * the stupid thing instead of polling on one and not the other.
 */
-   wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
 
-   ri.reg = 0;
-   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
-   if (ret)
-   return ret;
-   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+   tries = 3;
+   for (i = 0; i < tries; i++) {
+   wait_remaining_ms_from_jiffies(r0_prime_gen_start,
+  100 * (i + 1));
 
-   /* Wait for Ri prime match */
-   if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
-(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
+   ri.reg = 0;
+   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
+   if (ret)
+   return ret;
+   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+
+   /* Wait for Ri prime match */
+   if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
+   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+   break;
+   }
+
+   if (i == tries) {
DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
  I915_READ(PORT_HDCP_STATUS(port)));
return -ETIMEDOUT;
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/5] drm/i915: read Vprime thrice incase of mismatch

[Ramalingam C]

In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.

DP HDCP CTS Test: 1B-05

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 730681d2dbfb..7ea55fa46f41 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -150,7 +150,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
struct drm_i915_private *dev_priv;
u32 vprime, sha_text, sha_leftovers, rep_ctl;
u8 bstatus[2], num_downstream, *ksv_fifo;
-   int ret, i, j, sha_idx;
+   int ret, i, j, sha_idx, tries = 3;
 
dev_priv = intel_dig_port->base.base.dev->dev_private;
 
@@ -189,6 +189,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
if (ret)
return ret;
 
+read_v_prime:
/* Process V' values from the receiver */
for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
ret = shim->read_v_prime_part(intel_dig_port, i, );
@@ -385,6 +386,13 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
return -ETIMEDOUT;
}
if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
+
+   /*
+* When V prime mismatches, DP Spec mandates re-read of
+* V prime atleast twice.
+*/
+   if (--tries)
+   goto read_v_prime;
DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
return -ENXIO;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/5] drm/i915: Check hdcp key loadability

[Ramalingam C]

HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.

This patch enables the hdcp initialization for HSW, BDW, and BXT.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 7ea55fa46f41..95081aaa832a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -37,6 +37,33 @@ static int intel_hdcp_poll_ksv_fifo(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
+static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
+{
+   struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *power_well;
+   bool enabled = false;
+
+   mutex_lock(_domains->lock);
+
+   /* PG1 (power well #1) needs to be enabled */
+   for_each_power_well(dev_priv, power_well) {
+   if (power_well->id == SKL_DISP_PW_1) {
+   enabled = power_well->ops->is_enabled(dev_priv,
+ power_well);
+   break;
+   }
+   }
+   mutex_unlock(_domains->lock);
+
+   /*
+* Another req for hdcp key loadability is enabled state of pll for
+* cdclk. Without active crtc we wont land here. So we are assuming that
+* cdclk is already on.
+*/
+
+   return enabled;
+}
+
 static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
 {
I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
@@ -598,8 +625,8 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
  connector->base.name, connector->base.base.id);
 
-   if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
-   DRM_ERROR("PG1 is disabled, cannot load keys\n");
+   if (!hdcp_key_loadable(dev_priv)) {
+   DRM_ERROR("HDCP key Load is not possible\n");
return -ENXIO;
}
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 0/5] HDCP1.4 fixes

[Ramalingam C]

This series addresses the requriement of below HDCP compliance tests
DP: 1A-06 and 1B-05
HDMI: 1A-04 and 1A-07a

One of the patch uses the I915 power infra-structure for checking
the power state of PW#1. Which enables the init path for all legacy
platforms.

And encoder specific msg availability detection is moved into hdcp_shim.
This will help to sync with DP hdcp data availability in the best
possible way by fielding the CP_IRQ.


Ramalingam C (5):
  drm/i915: Read HDCP R0 thrice in case of mismatch
  drm/i915: read Vprime thrice incase of mismatch
  drm/i915: Check hdcp key loadability
  drm/i915: Poll hdcp register on sudden NACK
  drm/i915: Move hdcp msg detection into shim

 drivers/gpu/drm/i915/intel_dp.c   |  70 ++--
 drivers/gpu/drm/i915/intel_drv.h  |   6 +-
 drivers/gpu/drm/i915/intel_hdcp.c | 166 +++---
 drivers/gpu/drm/i915/intel_hdmi.c |  28 ++-
 4 files changed, 214 insertions(+), 56 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

[Daniele Ceraolo Spurio]

On 25/02/18 22:17, Sagar Arun Kamble wrote:



On 2/23/2018 10:31 PM, Daniele Ceraolo Spurio wrote:



On 23/02/18 06:04, Michal Wajdeczko wrote:

Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.

v2: s/reset_prepare/prepare_to_reset (Michel)
 don't forget about gem_sanitize path (Daniele)

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem.c    |  5 -
  drivers/gpu/drm/i915/intel_guc.h   |  5 +
  drivers/gpu/drm/i915/intel_huc.h   |  5 +
  drivers/gpu/drm/i915/intel_uc.c    | 14 ++
  drivers/gpu/drm/i915/intel_uc.h    |  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 14c855b..ae2c4ba 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct 
drm_i915_private *dev_priv)

  }
    i915_gem_revoke_fences(dev_priv);
+    intel_uc_prepare_to_reset(dev_priv);
    return err;
  }
@@ -4881,8 +4882,10 @@ void i915_gem_sanitize(struct drm_i915_private 
*i915)
   * it may impact the display and we are uncertain about the 
stability

   * of the reset, so this could be applied to even earlier gen.
   */
-    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
+    if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
+    intel_uc_prepare_to_reset(i915);


This leaves the status with an incorrect value if we boot with 
i915.reset=0, 
It depends on whether WOPCM is locked (In case of resume from S3 I have 
seen it to be the case often).

Then we need not reload GuC also unless we are not doing full GPU reset.
but I think this is still the right place to add this in. 

Yes
There are several things with GuC that are going to break if we use 
reset=0 (e.g. doorbell cleanup) 

Can you elaborate how it might break.
i915 isn't currently communicating to GuC (destroy_doorbell) during 
doorbell cleanup and if we start communicating then it should
not fail as GuC will be available with reset=0.  Also 
__intel_uc_reset_hw isn't gated by reset modparam.


As you said we do always reset GuC no matter the value of the modparam, 
but that does not reset the doorbell HW. If we're coming out of S3 and 
the state as been preserved this will cause the doorbell HW to be left 
in an unclean state, which could cause spurious doorbell interrupts to 
be sent to GuC, not sure how the firmware handles those. The code as 
moved since last time I looked at this in detail and I think we're now 
most likely going to overwrite those unclean doorbells, but there are 
unlikely corner cases (preempt context failing to be created) where we 
might not do so.
More generally, my concern was that in the code flow we assume GuC and 
related HW to be reset and in need of a re-init when we come out of 
suspend when actually as you reported that might not be the case if we 
have reset=0. Even if we have no major concerns now, issues might arise 
in the future after code reworks or new feature additions if we start 
from a wrong assumption. Instead of changing the flow to consider the 
reset=0 (which isn't really a supported scenario) I think it'd be more 
useful to just enforce the fact that we don't support that use-case with 
GuC, hence my suggestion. And yes, I'm probably just being uber-paranoid :P


Daniele

so I wouldn't consider this a regression, but we might want to start 
sanitizing the modparams to not allow reset=0 with GuC.


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


  WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+    }
  }
    int i915_gem_suspend(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 52856a9..0f6adb1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,9 @@ static inline u32 guc_ggtt_offset(struct i915_vma 
*vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 
size);

  u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  +static inline void intel_guc_prepare_to_reset(struct intel_guc *guc)
+{
+    intel_uc_fw_prepare_to_reset(>fw);
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h 
b/drivers/gpu/drm/i915/intel_huc.h

index 40039db..96e24f9 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,9 @@ struct intel_huc {
  int 

[Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Fill preempt context once at init time

[Michał Winiarski]

Since we're inhibiting context save of preempt context, we're no longer
tracking the position of HEAD/TAIL. With GuC, we're adding a new
breadcrumb for each preemption, which means that the HW will do more and
more breadcrumb writes. Eventually the ring is filled, and we're
submitting the preemption context with HEAD==TAIL==0, which won't result
in breadcrumb write, but will trigger hangcheck instead.
Instead of writing a new preempt breadcrumb for each preemption, let's
just fill the ring once at init time (which also saves a couple of
instructions in the tasklet).

v2: Assert that context save restore is inhibited, don't assert on ring
alignment. (Chris)

Fixes: 517aaffe0c1b ("drm/i915/execlists: Inhibit context save/restore for the 
fake preempt context")
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 86 -
 1 file changed, 59 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 586dde579903..3805839f567b 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -26,8 +26,13 @@
 #include 
 
 #include "intel_guc_submission.h"
+#include "intel_lrc_reg.h"
 #include "i915_drv.h"
 
+#define GUC_PREEMPT_FINISHED   0x1
+#define GUC_PREEMPT_BREADCRUMB_DWORDS  0x8
+#define GUC_PREEMPT_BREADCRUMB_BYTES   (sizeof(u32) * 
GUC_PREEMPT_BREADCRUMB_DWORDS)
+
 /**
  * DOC: GuC-based command submission
  *
@@ -535,8 +540,6 @@ static void flush_ggtt_writes(struct i915_vma *vma)
POSTING_READ_FW(GUC_STATUS);
 }
 
-#define GUC_PREEMPT_FINISHED 0x1
-#define GUC_PREEMPT_BREADCRUMB_DWORDS 0x8
 static void inject_preempt_context(struct work_struct *work)
 {
struct guc_preempt_work *preempt_work =
@@ -546,37 +549,17 @@ static void inject_preempt_context(struct work_struct 
*work)
 preempt_work[engine->id]);
struct intel_guc_client *client = guc->preempt_client;
struct guc_stage_desc *stage_desc = __get_stage_desc(client);
-   struct intel_ring *ring = client->owner->engine[engine->id].ring;
u32 ctx_desc = lower_32_bits(intel_lr_context_descriptor(client->owner,
 engine));
-   u32 *cs = ring->vaddr + ring->tail;
u32 data[7];
 
-   if (engine->id == RCS) {
-   cs = gen8_emit_ggtt_write_rcs(cs, GUC_PREEMPT_FINISHED,
-   intel_hws_preempt_done_address(engine));
-   } else {
-   cs = gen8_emit_ggtt_write(cs, GUC_PREEMPT_FINISHED,
-   intel_hws_preempt_done_address(engine));
-   *cs++ = MI_NOOP;
-   *cs++ = MI_NOOP;
-   }
-   *cs++ = MI_USER_INTERRUPT;
-   *cs++ = MI_NOOP;
-
-   GEM_BUG_ON(!IS_ALIGNED(ring->size,
-  GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32)));
-   GEM_BUG_ON((void *)cs - (ring->vaddr + ring->tail) !=
-  GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32));
-
-   ring->tail += GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32);
-   ring->tail &= (ring->size - 1);
-
-   flush_ggtt_writes(ring->vma);
-
+   /*
+* The ring should containt commands writing GUC_PREEMPT_FINISHED to
+* HWSP at client initialization time.
+*/
spin_lock_irq(>wq_lock);
guc_wq_item_append(client, engine->guc_id, ctx_desc,
-  ring->tail / sizeof(u64), 0);
+  GUC_PREEMPT_BREADCRUMB_BYTES / sizeof(u64), 0);
spin_unlock_irq(>wq_lock);
 
/*
@@ -972,6 +955,53 @@ static void guc_client_free(struct intel_guc_client 
*client)
kfree(client);
 }
 
+static void guc_fill_preempt_context(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct intel_guc_client *client = guc->preempt_client;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   u32 *cs;
+
+   for_each_engine(engine, dev_priv, id) {
+   struct intel_context *ce = >owner->engine[id];
+
+   GEM_BUG_ON(!ce->pin_count);
+
+   /*
+* We rely on this context image *not* being saved after
+* preemption. This ensures that the RING_HEAD / RING_TAIL
+* remaing pointing at initial values forever.
+*/
+   GEM_BUG_ON((ce->lrc_reg_state[CTX_CONTEXT_CONTROL + 1] &
+   _MASKED_BIT_ENABLE(
+   CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
+

[Intel-gfx] [PATCH 2/2] HAX: Enable GuC submission for CI

[Michał Winiarski]

---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9f1bac6398fb..b48056fb769d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
2.14.3

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

Re: [Intel-gfx] [RFC v3] drm/i915: Eliminate devid sprinkle

[Jani Nikula]

On Mon, 26 Feb 2018, Chris Wilson  wrote:
> Quoting Jani Nikula (2018-02-26 14:00:37)
>> On Thu, 22 Feb 2018, Tvrtko Ursulin  wrote:
>> > From: Tvrtko Ursulin 
>> >
>> > Introduce subplatform mask to eliminate throughout the code devid checking
>> > sprinkle, mostly courtesy of IS_*_UL[TX] macros.
>> >
>> > Subplatform mask initialization is moved either to static tables (Ironlake
>> > M) or runtime device info init (Pineview, Haswell, Broadwell, Skylake,
>> > Kabylake, Coffeelake and Cannonlake).
>> 
>> I thought Chris had the goal of separating runtime and static init, and
>> I very much agreed with that idea. Throw away the mkwrite stuff. This
>> patch seems to be at odds with that goal by tying a runtime init into
>> the same mask with statically initialized platform mask.
>
> Yes.
>
> In the extreme version of single platform LTO, we would bake one
> device-info stanza for every subplatform. That may be a little overkill
> (or rather too complicated for the user to know and too fine-grained to
> be useful). So the middle ground is that we have subplatform in the
> runtime_info, and the compiler has to do two loads. We can still benefit
> from using BIT() though.

Well, let's not conflate platform and subplatform into the same mask in
the same info for the short-term benefit, then?

And with that, I think we could go towards:

#define IS_BWD_ULT(dev_priv) (IS_BROADWELL(dev_priv) && IS_ULT(dev_priv))

where the IS_ULT would just check the subplatform mask.

I am not convinced it's worth overloading the subplatform bits.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Tell vga_switcheroo whether runtime PM is used

[Lukas Wunner]

On Mon, Feb 26, 2018 at 04:41:09PM +0200, Imre Deak wrote:
> On Sun, Feb 25, 2018 at 12:42:30AM +0100, Lukas Wunner wrote:
> > DRM drivers need to tell vga_switcheroo whether they use runtime PM.
> > If they do use it, vga_switcheroo lets them autosuspend at their own
> > discretion.  If on the other hand they do not use it, vga_switcheroo
> > allows the user to suspend and resume the GPU manually via the
> > ->set_gpu_state hook.
> > 
> > i915 currently tells vga_switcheroo that it never uses runtime PM, even
> > though it does use it on HSW and newer.  The result is that users may
> > interfere with the driver's runtime PM on those platforms.  Avoid by
> > reporting runtime PM support correctly to vga_switcheroo.
> > 
> > Cc: Imre Deak 
> > Signed-off-by: Lukas Wunner 
> 
> AFAICS this also needs calling vga_switcheroo_set_dynamic_switch() from
> the i915 runtime suspend/resume handlers.

I've posted a series a week ago which removes that call and haven't seen
any major objections.  Assuming that series goes into 4.17, there's no
point in adding calls to vga_switcheroo_set_dynamic_switch() now:
https://lists.freedesktop.org/archives/nouveau/2018-February/029851.html

If you have an Optimus/ATPX machine handy, please consider testing the
series.


> Also after this we can remove i915_switcheroo_set_state() ?

Not yet.  That's still needed for manual power control on chips
where you're not supporting runtime PM yet and which are known to
be built into hybrid graphics laptops.  (On the MacBook Pro, that's
ILK, SNB, IVB, can't speak for non-Macs.)

Manual power control was a stopgap according to Dave Airlie that
he implemented before he got runtime PM up and running:
http://lkml.iu.edu/hypermail/linux/kernel/1603.1/01935.html

It will be removed eventually, but right now it can't because runtime PM
on i915 doesn't yet cover all platforms and isn't yet working on muxed
laptops such as the MacBook Pro.  (I'm working on fixing the latter,
the series I've linked above gets us one step closer.)


> It's probably worth mentioning in the commit message that this changes
> the semantics of the switching: while atm you can't open the the DRM
> file for an inactive device (switched off from with IGD/DIS/DIGD/DDIS)
> after this change you can. I suppose that's not a problem, it just means
> display probing will fail on inactive devices (the same way it's with
> MIGD/MDIS currently).

Sorry, I don't understand the last sentence in that paragraph at all.

Thanks,

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

Re: [Intel-gfx] [RFC v3] drm/i915: Eliminate devid sprinkle

[Chris Wilson]

Quoting Jani Nikula (2018-02-26 14:00:37)
> On Thu, 22 Feb 2018, Tvrtko Ursulin  wrote:
> > From: Tvrtko Ursulin 
> >
> > Introduce subplatform mask to eliminate throughout the code devid checking
> > sprinkle, mostly courtesy of IS_*_UL[TX] macros.
> >
> > Subplatform mask initialization is moved either to static tables (Ironlake
> > M) or runtime device info init (Pineview, Haswell, Broadwell, Skylake,
> > Kabylake, Coffeelake and Cannonlake).
> 
> I thought Chris had the goal of separating runtime and static init, and
> I very much agreed with that idea. Throw away the mkwrite stuff. This
> patch seems to be at odds with that goal by tying a runtime init into
> the same mask with statically initialized platform mask.

Yes.

In the extreme version of single platform LTO, we would bake one
device-info stanza for every subplatform. That may be a little overkill
(or rather too complicated for the user to know and too fine-grained to
be useful). So the middle ground is that we have subplatform in the
runtime_info, and the compiler has to do two loads. We can still benefit
from using BIT() though.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for kernel: Downgrade warning for unsafe parameters (rev2)

[Patchwork]

== Series Details ==

Series: kernel: Downgrade warning for unsafe parameters (rev2)
URL   : https://patchwork.freedesktop.org/series/38614/
State : success

== Summary ==

Series 38614v2 kernel: Downgrade warning for unsafe parameters
https://patchwork.freedesktop.org/api/1.0/series/38614/revisions/2/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927
fail   -> PASS   (fi-skl-6700k2) fdo#104108

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:287s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:398s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s

081d3ec1dff7c099be680022724e3736e96a5eea drm-tip: 2018y-02m-26d-14h-42m-25s UTC 
integration manifest
bf89adc45086 kernel: Downgrade warning for unsafe parameters

== Logs ==

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

Re: [Intel-gfx] [PATCH] kernel: Downgrade warning for unsafe parameters

[Jani Nikula]

On Mon, 26 Feb 2018, Chris Wilson  wrote:
> As using an unsafe module parameter is, by its very definition, an
> expected user action, emitting a warning is overkill. Nothing has yet
> gone wrong, and we add a taint flag for any future oops should
> something actually go wrong. So instead of having a user controllable
> pr_warn, downgrade it to a pr_notice for "a normal, but significant
> condition".
>
> We make use of unsafe kernel parameters in igt (we have not yet
> succeeded in removing all such debugging options), which generates a
> warning and taints the kernel. The warning is unhelpful as we then need
> to filter it out again as we check that every test themselves do not
> provoke any kernel warnings.

IGT being https://cgit.freedesktop.org/drm/igt-gpu-tools/ for those not
in the DRM/KMS circles.

> References: 91f9d330cc14 ("module: make it possible to have unsafe, tainting 
> module params")
> Signed-off-by: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Rusty Russell 
> Cc: Jean Delvare 
> Cc: Andrew Morton 
> Cc: Li Zhong 
> Cc: Petri Latvala 
> Cc: Daniel Vetter 

Acked-by: Jani Nikula 

When I added the unsafe module params, I erred on the side of making
more noise about tainting, but there was really no discussion about
it. FWIW, I don't mind the change, as long as it's not debug level.

BR,
Jani.

> ---
>  kernel/params.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index cc9108c2a1fd..ce89f757e6da 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -111,8 +111,8 @@ bool parameq(const char *a, const char *b)
>  static void param_check_unsafe(const struct kernel_param *kp)
>  {
>   if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
> - pr_warn("Setting dangerous option %s - tainting kernel\n",
> - kp->name);
> + pr_notice("Setting dangerous option %s - tainting kernel\n",
> +   kp->name);
>   add_taint(TAINT_USER, LOCKDEP_STILL_OK);
>   }
>  }

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt v2] igt/gem_exec_schedule: Exercise "deep" preemption

[Chris Wilson]

In investigating the issue with having to force preemption within the
executing ELSP[], we want to trigger preemption between all elements of
that array. To that end, we issue a series of requests with different
priorities to fill the in-flight ELSP[] and then demand preemption into
the middle of that series. One can think of even more complicated
reordering requirements of ELSP[], trying to switch between every
possible combination of permutations. Rather than check all 2 billion
combinations, be content with a few.

v2: Add a different pattern for queued requests. Not only do we need to
inject a request into the middle of a single context with a queue of
different priority contexts, but we also want a queue of different
contexts, as they have different patterns of ELSP[] behaviour.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michał Winiarski 
---
 tests/gem_exec_schedule.c | 188 +-
 1 file changed, 169 insertions(+), 19 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 8a69ab5c..7f1bda42 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -373,13 +373,78 @@ static void preempt(int fd, unsigned ring, unsigned flags)
gem_close(fd, result);
 }
 
-static void preempt_other(int fd, unsigned ring)
+#define CHAIN 0x1
+#define CONTEXTS 0x2
+
+static igt_spin_t *__noise(int fd, uint32_t ctx, int prio, igt_spin_t *spin)
+{
+   unsigned other;
+
+   gem_context_set_priority(fd, ctx, prio);
+
+   for_each_physical_engine(fd, other) {
+   if (spin == NULL) {
+   spin = __igt_spin_batch_new(fd, ctx, other, 0);
+   } else {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .rsvd1 = ctx,
+   .flags = other,
+   };
+   gem_execbuf(fd, );
+   }
+   }
+
+   return spin;
+}
+
+static void __preempt_other(int fd,
+   uint32_t *ctx,
+   unsigned int target, unsigned int primary,
+   unsigned flags)
 {
uint32_t result = gem_create(fd, 4096);
uint32_t *ptr = gem_mmap__gtt(fd, result, 4096, PROT_READ);
-   igt_spin_t *spin[MAX_ENGINES];
-   unsigned int other;
-   unsigned int n, i;
+   unsigned int n, i, other;
+
+   n = 0;
+   store_dword(fd, ctx[LO], primary,
+   result, (n + 1)*sizeof(uint32_t), n + 1,
+   0, I915_GEM_DOMAIN_RENDER);
+   n++;
+
+   if (flags & CHAIN) {
+   for_each_physical_engine(fd, other) {
+   store_dword(fd, ctx[LO], other,
+   result, (n + 1)*sizeof(uint32_t), n + 1,
+   0, I915_GEM_DOMAIN_RENDER);
+   n++;
+   }
+   }
+
+   store_dword(fd, ctx[HI], target,
+   result, (n + 1)*sizeof(uint32_t), n + 1,
+   0, I915_GEM_DOMAIN_RENDER);
+
+   igt_debugfs_dump(fd, "i915_engine_info");
+   gem_set_domain(fd, result, I915_GEM_DOMAIN_GTT, 0);
+
+   n++;
+   for (i = 0; i <= n; i++)
+   igt_assert_eq_u32(ptr[i], i);
+
+   munmap(ptr, 4096);
+   gem_close(fd, result);
+}
+
+static void preempt_other(int fd, unsigned ring, unsigned int flags)
+{
+   unsigned int primary;
+   igt_spin_t *spin = NULL;
uint32_t ctx[3];
 
/* On each engine, insert
@@ -396,36 +461,97 @@ static void preempt_other(int fd, unsigned ring)
gem_context_set_priority(fd, ctx[LO], MIN_PRIO);
 
ctx[NOISE] = gem_context_create(fd);
+   spin = __noise(fd, ctx[NOISE], 0, NULL);
 
ctx[HI] = gem_context_create(fd);
gem_context_set_priority(fd, ctx[HI], MAX_PRIO);
 
+   for_each_physical_engine(fd, primary) {
+   igt_debug("Primary engine: %s\n", e__->name);
+   __preempt_other(fd, ctx, ring, primary, flags);
+
+   }
+
+   igt_assert(gem_bo_busy(fd, spin->handle));
+   igt_spin_batch_free(fd, spin);
+
+   gem_context_destroy(fd, ctx[LO]);
+   gem_context_destroy(fd, ctx[NOISE]);
+   gem_context_destroy(fd, ctx[HI]);
+}
+
+static void __preempt_queue(int fd,
+   unsigned target, unsigned primary,
+   unsigned depth, unsigned flags)
+{
+   uint32_t result = gem_create(fd, 4096);
+   uint32_t *ptr = gem_mmap__gtt(fd, result, 4096, PROT_READ);
+   igt_spin_t *above = NULL, *below = NULL;
+