date:20180419

Re: [Intel-gfx] [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

2018-04-19 Thread Ian W MORRISON

On 18 April 2018 at 00:14, Joonas Lahtinen
 wrote:
> Quoting Jani Nikula (2018-04-17 12:02:52)
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W MORRISON 
>> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
>> >>; Wajdeczko, Michal
>> >>; Greg KH ;
>> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
>> >>linux-ker...@vger.kernel.org;
>> >>sta...@vger.kernel.org; intel-gfx@lists.freedesktop.org; dri-
>> >>de...@lists.freedesktop.org
>> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
>> >>Geminilake

In summary so far:

Jani:
> NAK on indiscriminate Cc: stable. There are zero guarantees that
> older kernels will work with whatever firmware you throw at them.
> Who tested the firmware with v4.12 and later? We only have the CI
> results against *current* drm-tip. We don't even know about v4.16.
> I'm not going to ack and take responsibility for the stable backports
> unless someone actually comes forward with credible Tested-bys.

Anusha:
> The stable kernel version is 4.12 and beyond.
> It is appropriate to add the CC: stable in my opinion

Joonas:
> And even then, some distros will be surprised of the new MODULE_FIRMWARE
> and will need to update the linux-firmware package, too.

I've performed backport testing and some additional analysis as follows:

The DMC firmware for GLK was initially included in 4.11
  (commit: dbb28b5c3d3cb945a63030fab8d3894cf335ce19).
Then the firmware version was upgraded to 1.03 in 4.12
  (commit: f4a791819ed00a749a90387aa139706a507aa690).
However MODULE_FIRMWARE for the GLK DMC firmware
was also removed in 4.12
  (commit: d9321a03efcda867b3a8c6327e01808516f0acd7)
together with the firmware version being bumped to 1.04
  (commit: aebfd1d37194e00d4c417e7be97efeb736cd9c04).

The patch below effectively reverts commit d9321a03 because the GLK
firmware is now available in the linux-firmware repository.

To test stable backports I've used Ubuntu 18.04 (Beta 2) userspace with
both Ubuntu (generic) and self-compiled mainline (patched) kernels.
The conclusion was that the patch works across 4.12 to 4.17-rc1 kernels
additionally displaying a 'Possible missing firmware' message when
installing a kernel with the expected firmware missing.

The following are abridged backport test results:

Scenario: No DMC (glk_dmc_ver1_04.bin) firmware installed in
'/lib/firmware/i915'
  Test:Kernel installation ('grep -i dmc' output from 'apt install'):
4.12-generic and 4.15-generic:
  No output # as expected
4.12 to 4.17-rc1-patched:
  W: Possible missing firmware
/lib/firmware/i915/glk_dmc_ver1_04.bin for module i915
  Result: The effect of the patch is to add a 'Possible missing
firmware' message.
  Test: Booting ('grep -i dmc' output from 'dmesg'):
4.12-generic:
  No output # as expected
4.15-generic:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
4.12-patched:
  No output # as expected
4.13 to 4.14-patched:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
[https://01.org/linuxgraphics/downloads/firmware], disabling runtime
power management.
4.15 to 4.17-rc1-patched:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
  Result: The effect of the patch does not change existing
(non-patched kernel) messages.

Scenario: DMC (glk_dmc_ver1_04.bin) firmware installed in '/lib/firmware/i915'
  Test:Kernel installation ('grep -i dmc' output from 'apt install')
All kernels:
  No messages # as expected
  Result: The effect of the patch does not change existing messages.
  Test" Booting ('grep -i dmc' output from 'dmesg'):
4.12-generic:
  No output # as expected
4.15-generic:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
4.12-patched:
  No output # as expected
4.13 to 4.17-rc1-patched:
  [drm] Finished loading DMC

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log (rev2)
URL   : https://patchwork.freedesktop.org/series/34125/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4070_full -> Patchwork_8757_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8757_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8757_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/34125/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8757_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd1:
  shard-kbl:  PASS -> SKIP +3

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  SKIP -> PASS +2

igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled:
  shard-glk:  SKIP -> PASS +90

igt@kms_flip@flip-vs-panning-vs-hang-interruptible:
  shard-glk:  PASS -> SKIP +60


== Known issues ==

  Here are the changes found in Patchwork_8757_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_flush@basic-wb-set-default:
  shard-glk:  PASS -> FAIL (fdo#105900)

igt@kms_cursor_legacy@flip-vs-cursor-atomic:
  shard-hsw:  PASS -> FAIL (fdo#102670)

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060) +1

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#106087)

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-glk:  SKIP -> FAIL (fdo#100368) +1

igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
  shard-glk:  PASS -> DMESG-WARN (fdo#103774)

igt@kms_setmode@basic:
  shard-kbl:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_frontbuffer_tracking@basic:
  shard-glk:  FAIL (fdo#103167) -> SKIP

igt@kms_setmode@basic:
  shard-glk:  FAIL (fdo#99912) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


 Warnings 

igt@kms_sysfs_edid_timing:
  shard-glk:  FAIL (fdo#100047) -> WARN (fdo#100047)


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103774 https://bugs.freedesktop.org/show_bug.cgi?id=103774
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4070 -> Patchwork_8757

  CI_DRM_4070: 47f407780a2b330f097892203401986838eb9795 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8757: a10cd605896d1202fb6fae524200e2fd8b4e9bef @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8757/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 display WA#1183 from its correct spot

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915: Enable display WA#1183 from its correct spot
URL   : https://patchwork.freedesktop.org/series/41983/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4070_full -> Patchwork_8756_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8756_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8756_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41983/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8756_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP +2

igt@gem_mmap_wc@set-cache-level:
  shard-glk:  PASS -> SKIP +92

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  SKIP -> PASS +2

igt@kms_vblank@pipe-b-wait-forked-busy-hang:
  shard-glk:  SKIP -> PASS +58


== Known issues ==

  Here are the changes found in Patchwork_8756_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@cursor-vs-flip-toggle:
  shard-hsw:  PASS -> FAIL (fdo#103355)

igt@kms_cursor_legacy@flip-vs-cursor-toggle:
  shard-hsw:  PASS -> FAIL (fdo#102670)

igt@kms_flip@2x-plain-flip-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#106087)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#105707)

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt:
  shard-apl:  PASS -> FAIL (fdo#103167)

igt@kms_setmode@basic:
  shard-kbl:  PASS -> FAIL (fdo#99912)

igt@kms_universal_plane@universal-plane-pipe-b-sanity:
  shard-hsw:  PASS -> DMESG-WARN (fdo#102614)


 Possible fixes 

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#103665, fdo#106023) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_frontbuffer_tracking@basic:
  shard-glk:  FAIL (fdo#103167) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4070 -> Patchwork_8756

  CI_DRM_4070: 47f407780a2b330f097892203401986838eb9795 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8756: 38a485385f9326dc10d8927c4d0647e0f3a6e1ad @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8756/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/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

2018-04-19 Thread Yaodong Li


On 04/19/2018 08:45 AM, Michal Wajdeczko wrote:
On Wed, 18 Apr 2018 19:01:31 +0200, Jackie Li  
wrote:



After enabled the WOPCM write-once registers locking status checking,
reloading of the i915 module will fail with modparam enable_guc set to 3
(enable GuC and HuC firmware loading) if the module was originally 
loaded

with enable_guc set to 1 (only enable GuC firmware loading). This is
because WOPCM registers were updated and locked without considering 
the HuC

FW size. Since we need both GuC and HuC FW sizes to determine the final
layout of WOPCM, we should always calculate the WOPCM layout based on 
the
actual sizes of the GuC and HuC firmware available for a specific 
platform

if we need continue to support enable/disable HuC FW loading dynamically
with enable_guc modparam.

This patch splits uC firmware fetching into two stages. First stage 
is to
fetch the firmware image and verify the firmware header. uC firmware 
will

be marked as verified and this will make FW info available for following
WOPCM layout calculation. The second stage is to create a GEM object and
copy the FW data into the created GEM object which will only be 
available
when GuC/HuC loading is enabled by enable_guc modparam. This will 
guarantee
that the WOPCM layout will be always be calculated correctly without 
making

any assumptions to the GuC and HuC firmware sizes.

v3:
 - Rebase

v4:
 - Renamed the new parameter add to intel_uc_fw_fetch (Michal)

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
Reviewed-by: John Spotswood 
---
 drivers/gpu/drm/i915/intel_uc.c    | 14 --
 drivers/gpu/drm/i915/intel_uc_fw.c | 31 ---
 drivers/gpu/drm/i915/intel_uc_fw.h |  7 +--
 3 files changed, 29 insertions(+), 23 deletions(-)

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

index 1cffaf7..73b8f6c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -172,11 +172,8 @@ void intel_uc_init_early(struct drm_i915_private 
*i915)

sanitize_options_early(i915);
-    if (USES_GUC(i915))
-    intel_uc_fw_fetch(i915, >fw);
-
-    if (USES_HUC(i915))
-    intel_uc_fw_fetch(i915, >fw);
+    intel_uc_fw_fetch(i915, >fw, USES_GUC(i915));
+    intel_uc_fw_fetch(i915, >fw, USES_HUC(i915));


Again: I'm don't think that unconditional fetch of HuC fw is a right 
choice.
We should look for other options how to support enable_guc 1-->3 
scenario.


This is the real fix I can think of to support such a scenario. I think 
the performance
impact here is minimal since it's only one time operation. I will think 
about the

use case of HAS_HUC = 1 and only enable guc submission.

But first I suggest we need to define the expected use case (like I 
mentioned in my last reply):
how to define "support enable_guc 1->3" (whether we should expect some 
system reboot, or
we need guarantee 100% work with no system reboot required)? whether a 
system reboot for

FW changes should be treated as code defects, etc.

 }
void intel_uc_cleanup_early(struct drm_i915_private *i915)
@@ -184,11 +181,8 @@ void intel_uc_cleanup_early(struct 
drm_i915_private *i915)

 struct intel_guc *guc = >guc;
 struct intel_huc *huc = >huc;
-    if (USES_HUC(i915))
-    intel_uc_fw_fini(>fw);
-
-    if (USES_GUC(i915))
-    intel_uc_fw_fini(>fw);
+    intel_uc_fw_fini(>fw);
+    intel_uc_fw_fini(>fw);
guc_free_load_err_log(guc);
 }
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c 
b/drivers/gpu/drm/i915/intel_uc_fw.c

index 6e8e0b5..c1fed06 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -33,11 +33,13 @@
  *
  * @dev_priv: device private
  * @uc_fw: uC firmware
+ * @fetch: whether fetch uC firmware into GEM object or not
  *
- * Fetch uC firmware into GEM obj.
+ * Fetch and verify uC firmware and copy firmware data into GEM 
object if

+ * @fetch is true.
  */
 void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
-   struct intel_uc_fw *uc_fw)
+   struct intel_uc_fw *uc_fw, bool fetch)
 {
 struct pci_dev *pdev = dev_priv->drm.pdev;
 struct drm_i915_gem_object *obj;
@@ -154,17 +156,24 @@ void intel_uc_fw_fetch(struct drm_i915_private 
*dev_priv,

 goto fail;
 }
-    obj = i915_gem_object_create_from_data(dev_priv, fw->data, 
fw->size);

-    if (IS_ERR(obj)) {
-    err = PTR_ERR(obj);
-    DRM_DEBUG_DRIVER("%s fw object_create err=%d\n",
- intel_uc_fw_type_repr(uc_fw->type), err);
-    goto fail;
+    uc_fw->size = fw->size;
+    uc_fw->fetch_status = INTEL_UC_FIRMWARE_VERIFIED;


btw, I'm not sure that this new state is needed at all, as you

Re: [Intel-gfx] [PATCH v2] drm/i915/gen11: Preempt-to-idle support in execlists.

2018-04-19 Thread Daniele Ceraolo Spurio




  
@@ -1010,7 +1033,15 @@ static void execlists_submission_tasklet(unsigned long data)

   GEN8_CTX_STATUS_PREEMPTED))
 execlists_set_active(execlists,
  EXECLISTS_ACTIVE_HWACK);
-   if (status & GEN8_CTX_STATUS_ACTIVE_IDLE)
+
+   /*
+* Check if switched to idle or preempted to idle.
+* The STATUS_IDLE_ACTIVE flag is really used to mark
+* preemtion from idle to idle, this is not a mistake.
+*/
+   if ((status & GEN8_CTX_STATUS_ACTIVE_IDLE) ||
+   ((status & GEN8_CTX_STATUS_IDLE_ACTIVE) &&
+(status & GEN11_CTX_STATUS_PREEMPT_IDLE)))
 execlists_clear_active(execlists,
EXECLISTS_ACTIVE_HWACK);


But still pointless, no?



Just to understand, is it pointless because we have a preemption in 
flight and we're thus going to call execlists_dequeue below, which will 
eventually clear the flag in execlists_submit_ports? Or do we just don't 
care if this gets cleared here because we always clear it before a write 
to the elsp and we're only interested in it being clear between the 
write and the subsequent csb event?


Also, now that I think about it, with the current flow it doesn't look 
like we would clear EXECLISTS_ACTIVE_PREEMPT if a preempt-to-idle 
happens on idle HW, so we still need a condition for that even if we 
drop the one for EXECLISTS_ACTIVE_HWACK.


Daniele


@@ -1020,8 +1051,13 @@ static void execlists_submission_tasklet(unsigned long 
data)
 /* We should never get a COMPLETED | IDLE_ACTIVE! */
 GEM_BUG_ON(status & GEN8_CTX_STATUS_IDLE_ACTIVE);
  
-   if (status & GEN8_CTX_STATUS_COMPLETE &&

-   buf[2*head + 1] == 
execlists->preempt_complete_status) {
+   /*
+* Check if preempted to real idle, either directly or
+* the preemptive context already finished executing
+*/
+   if ((status & GEN11_CTX_STATUS_PREEMPT_IDLE) ||
+   (status & GEN8_CTX_STATUS_COMPLETE &&
+   buf[2*head + 1] == 
execlists->preempt_complete_status)) {
 GEM_TRACE("%s preempt-idle\n", engine->name);
  
 execlists_cancel_port_requests(execlists);

@@ -2157,7 +2193,8 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
 engine->unpark = NULL;
  
 engine->flags |= I915_ENGINE_SUPPORTS_STATS;

-   if (engine->i915->preempt_context)
+   if (engine->i915->preempt_context ||
+   HAS_HW_PREEMPT_TO_IDLE(engine->i915))
 engine->flags |= I915_ENGINE_HAS_PREEMPTION;


-Chris


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

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Add code to accept valid locked WOPCM register values

2018-04-19 Thread Yaodong Li


On 04/19/2018 09:37 AM, Michal Wajdeczko wrote:
On Mon, 16 Apr 2018 20:43:39 +0200, Yaodong Li  
wrote:



On 04/13/2018 09:20 PM, Michal Wajdeczko wrote:
On Tue, 10 Apr 2018 02:42:19 +0200, Jackie Li  
wrote:


In current code, we only compare the locked WOPCM register values 
with the
calculated values. However, we can continue loading GuC/HuC 
firmware if the
locked (or partially locked) values were valid for current GuC/HuC 
firmware

sizes.

This patch added a new code path to verify whether the locked register
values can be used for GuC/HuC firmware loading, it will 
recalculate the
verify the new values if these registers were partially locked, so 
that we
won't fail the GuC/HuC firmware loading even if the locked register 
values

are different from the calculated ones.

v2:
 - Update WOPCM register only if it's not locked

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 217 
+++--

 1 file changed, 185 insertions(+), 32 deletions(-)

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

index b1c08ca..fa8d2be 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -140,6 +140,53 @@ static inline int check_hw_restriction(struct 
drm_i915_private *i915,

 return err;
 }
+static inline u32 calculate_min_guc_wopcm_base(u32 huc_fw_size)
+{
+    return ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
+ GUC_WOPCM_OFFSET_ALIGNMENT);
+}
+
+static inline u32 calculate_min_guc_wopcm_size(u32 guc_fw_size)
+{
+    return guc_fw_size + GUC_WOPCM_RESERVED + 
GUC_WOPCM_STACK_RESERVED;

+}
+
+static inline int calculate_max_guc_wopcm_size(struct intel_wopcm 
*wopcm,

+   u32 guc_wopcm_base,
+   u32 *guc_wopcm_size)


Can't we just return this size as positive value?
I guess wopcm size will never be larger than MAX_INT.
We can add GEM_BUG_ON to be sure.


+{
+    struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+    u32 ctx_rsvd = context_reserved_size(i915);
+
+    if (guc_wopcm_base >= wopcm->size ||
+    (guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
+    DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
+  guc_wopcm_base / 1024);
+    return -E2BIG;


You are mixing calculations with verifications here.
Focus on calculations as you have separate function that verifies 
values.



+    }
+
+    *guc_wopcm_size =
+    (wopcm->size - guc_wopcm_base - ctx_rsvd) & 
GUC_WOPCM_SIZE_MASK;

+
+    return 0;
+}
+
+static inline int verify_calculated_values(struct drm_i915_private


hmm, maybe we can unify somehow this verification to be able to work 
with

both calculated and locked values?
I actually thought about that. However, since the verification based 
on the assumption
that the unlocked reg value could be any numbers so it puts more 
checks on these values

which are unnecessary during the calculation.


maybe some checks would be "unnecessary" but they still should be valid.
and code reuse is nice benefit that sacrifice that few extra checks.
Hmm, actually there's no duplicated code here. But I agree that it will 
be clearer to
have single place for the verification - it makes sense too:). So will 
choose to

sacrifice a little bit time here for unnecessary checks.



I've made the responding check common
enough to be reused by this verification code and the calculation code.



*i915,
+   u32 guc_fw_size, u32 huc_fw_size,
+   u32 guc_wopcm_base,
+   u32 guc_wopcm_size)
+{
+    if (guc_wopcm_size < calculate_min_guc_wopcm_size(guc_fw_size)) {
+    DRM_ERROR("Need %uKiB WOPCM for GuC FW, %uKiB available.\n",
+  calculate_min_guc_wopcm_size(guc_fw_size),


you are calling calculate_min_guc_wopcm_size() twice

Will update it.



+  guc_wopcm_size / 1024);
+    return -E2BIG;
+    }
+
+    return check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+    huc_fw_size);
+}
+
 /**
  * intel_wopcm_init() - Initialize the WOPCM structure.
  * @wopcm: pointer to intel_wopcm.
@@ -157,10 +204,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
 struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
 u32 guc_fw_size = intel_uc_fw_get_upload_size(>guc.fw);
 u32 huc_fw_size = intel_uc_fw_get_upload_size(>huc.fw);
-    u32 ctx_rsvd = context_reserved_size(i915);
 u32 guc_wopcm_base;
 u32 guc_wopcm_size;
-    u32 guc_wopcm_rsvd;
 int err;
    GEM_BUG_ON(!wopcm->size);
@@ -177,35 +222,121 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
 return -E2BIG;
 }
-

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register

2018-04-19 Thread Yaodong Li


On 04/19/2018 08:52 AM, Michal Wajdeczko wrote:
On Mon, 16 Apr 2018 19:43:52 +0200, Yaodong Li  
wrote:



On 04/13/2018 07:26 PM, Michal Wajdeczko wrote:
On Tue, 10 Apr 2018 02:42:18 +0200, Jackie Li  
wrote:



The enable_guc modparam is used to enable/disable GuC/HuC FW uploading
dynamcially during i915 module loading. If WOPCM offset register was

  
typo


D'oh! I really need a tool for this! Thanks, will fix it.

locked
without having HUC_LOADING_AGENT_GUC bit set to 1, the module 
reloading
with both GuC and HuC FW will fail since we need to set this bit to 
1 for

HuC FW uploading.

Since HUC_LOADING_AGENT_GUC bit has no impact on GuC FW uploading, 
this

patch updates the register updating code to make sure the WOPCM offset
register is always locked with HUC_LOADING_AGENT_GUC bit set to 1 
which
will guarantee successful uploading of both GuC and HuC FW. We will 
further

take care of the locked values in the following enhancement patch.

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

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

index 74bf76f..b1c08ca 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -238,8 +238,6 @@ static inline int write_and_verify(struct 
drm_i915_private *dev_priv,

 int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
 {
 struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
-    u32 huc_agent;
-    u32 mask;
 int err;
    if (!USES_GUC(dev_priv))
@@ -255,10 +253,10 @@ int intel_wopcm_init_hw(struct intel_wopcm 
*wopcm)

 if (err)
 goto err_out;
-    huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
-    mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | 
huc_agent;

 err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
-   wopcm->guc.base | huc_agent, mask,
+   wopcm->guc.base | HUC_LOADING_AGENT_GUC,
+   GUC_WOPCM_OFFSET_MASK | HUC_LOADING_AGENT_GUC |
+   GUC_WOPCM_OFFSET_VALID,


while we can unconditionally set HUC_AGENT bit, there is no need to 
verify

it unless we are using HuC, so we can consider leaving old mask intact.
The idea is to verify the written values are exactly we want, so I 
think it better

to keep doing it in this way.


Hmm, but then instead of being more flexible, you're unnecessary 
restricting

yourself to require HUC_AGENT bit, even if you don't need it - recall the
theoretical scenario with bad bios that already locked that register.


Hmm. Actually my thought is pretty simple here. we want to always set this
bit so we always keep checking it. For the fault bios handling, my 
thought is

if this reg was locked without HUC_AGENT bit when USES_HUC is true. we will
return error - the 3/3 patch is taking care of this.


This seems to be little inconsistent with earlier patch where you try to
support much more different scenario (from no HuC fw to use HuC fw)

My 1/3 patch is trying to support enable_guc=1->3->1 without any FW changes
on the FS while work as an enhancement patch to handle more complicated
cases for the theoretical scenario - faulty bios.

Regards,
-Jackie

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

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

2018-04-19 Thread Yaodong Li


On 04/19/2018 08:31 AM, Michal Wajdeczko wrote:
On Mon, 16 Apr 2018 19:28:04 +0200, Yaodong Li  
wrote:



On 04/13/2018 07:15 PM, Michal Wajdeczko wrote:
On Tue, 10 Apr 2018 02:42:17 +0200, Jackie Li  
wrote:



After enabled the WOPCM write-once registers locking status checking,
reloading of the i915 module will fail with modparam enable_guc set 
to 3
(enable GuC and HuC firmware loading) if the module was originally 
loaded

with enable_guc set to 1 (only enable GuC firmware loading).


Is this frequent and required scenario ? or just for 
debug/development ?


My understanding is this should be a nice to have feature and mainly 
for debugging.

This is
because WOPCM registers were updated and locked without considering 
the HuC
FW size. Since we need both GuC and HuC FW sizes to determine the 
final
layout of WOPCM, we should always calculate the WOPCM layout based 
on the
actual sizes of the GuC and HuC firmware available for a specific 
platform
if we need continue to support enable/disable HuC FW loading 
dynamically

with enable_guc modparam.

This patch splits uC firmware fetching into two stages. First stage 
is to
fetch the firmware image and verify the firmware header. uC 
firmware will
be marked as verified and this will make FW info available for 
following
WOPCM layout calculation. The second stage is to create a GEM 
object and
copy the FW data into the created GEM object which will only be 
available
when GuC/HuC loading is enabled by enable_guc modparam. This will 
guarantee
that the WOPCM layout will be always be calculated correctly 
without making

any assumptions to the GuC and HuC firmware sizes.


You are also assuming that on reload exactly the same GuC/HuC firmwares
will bee used as in initial run. This will make this useless for debug/
development scenarios, where custom fw are likely to be specified.

This patch is mainly for providing a real fix to support 
enable_guc=1->3->1 use case.
It based on the fact that it is inevitable that sometimes we need to 
reboot the system

if the status of the fw was changed on the file system.


What do you mean by "status of the fw was changed on the file system" ?
* change of the fw binary/version/size, or
* change from not-present to present ?

I think it should include all of the presence changes, file updates.


I am not sure how often we switch between different HuC FW with 
different sizes?


Just above you said that you need this "mainly for debugging" so
I would expect that then different fw sizes are expected.


If we want to support enable_guc=1->3->1 scenarios for debug/dev then
maybe more flexible will be other approach that makes allocations from
the other end as proposed in [1]

[1] https://patchwork.freedesktop.org/patch/212471/
Actually, I do think this might be one of the options, and I've also 
put some comments on this
series. The main concern I have is it still make assumption on the 
GuC FW size and may


But in enable_guc=1-->3 scenario, I would assume that the only difference
will be HuC fw (as with enable=1 we already loaded GuC)
Hmm, my main concern to the current "from the end" solution is it makes 
assumption on

the GuC FW size in order to meet the HW restriction.


If you want just to test different GuC fws, then it is different scenario
as then enable_guc will always be = 1.

what I mean is the "from the end" approach will lead to the same issue 
for different GuC FW sizes - we
may have to reboot the system for GuC FW debugging (different GuC FW 
sizes) even if enable_guc is always
set to 1. However, with the current "from the beginning" way we won't 
run into such problems
for GuC FW debugging (since it's already used the max available space). 
Thus I think we should

define the enable_guc = 1->3->1 as following:
we would support use of enable_guc=1->3->1 correctly without system 
reboot for the present FWs. A system
reboot will be expected (but not necessarily happen if we found current 
partition works for the new FWs)

for any FW changes (including add/remove/update).

if we decide to drop the support for enable_guc=1->3->1 since it's only 
for debugging purpose then we should
expect a system reboot for either "from the end" or "from the beginning" 
solutions since we cannot 100% have
this issue (changing FW without a system boot) solved. Therefore, the 
require of system reboot should not be

a bug when it comes to FW updating.


run into the same issue if the GuC FW failed to meet the requirement.
and for debugging purpose it would have the same possible for 
different GuC FW debugging.




v3:
 - Rebase

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.c    | 14 --

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Show number of objects without client

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915: Show number of objects without client
URL   : https://patchwork.freedesktop.org/series/41977/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4069_full -> Patchwork_8755_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8755_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8755_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41977/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8755_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-bsd2:
  shard-kbl:  PASS -> SKIP

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +1

igt@kms_mmap_write_crc:
  shard-glk:  SKIP -> PASS +32

igt@kms_vblank@pipe-b-wait-forked:
  shard-glk:  PASS -> SKIP +36


== Known issues ==

  Here are the changes found in Patchwork_8755_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-apl:  PASS -> INCOMPLETE (fdo#103927)

igt@drv_suspend@forcewake:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_hdmi_inject@inject-audio:
  shard-glk:  PASS -> FAIL (fdo#102370)

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)

igt@prime_vgem@basic-fence-flip:
  shard-glk:  PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@kms_cursor_legacy@flip-vs-cursor-atomic:
  shard-hsw:  FAIL (fdo#102670) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106134) -> PASS

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#100368) -> SKIP

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  FAIL (fdo#103933) -> SKIP

igt@kms_setmode@basic:
  shard-glk:  FAIL (fdo#99912) -> PASS

igt@kms_vblank@pipe-a-accuracy-idle:
  shard-hsw:  FAIL (fdo#102583) -> PASS


 Warnings 

igt@kms_sysfs_edid_timing:
  shard-glk:  WARN (fdo#100047) -> FAIL (fdo#100047)


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102370 https://bugs.freedesktop.org/show_bug.cgi?id=102370
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#103933 https://bugs.freedesktop.org/show_bug.cgi?id=103933
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106134 https://bugs.freedesktop.org/show_bug.cgi?id=106134
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4069 -> Patchwork_8755

  CI_DRM_4069: 8136363fe770a1a51688172d5ba46a5017f76677 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8755: d1e9cd01619a872f2642503e1490c2184042f048 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/fbdev: Enable late fbdev initial configuration

2018-04-19 Thread Souza, Jose

On Thu, 2018-04-19 at 15:50 +0300, Jani Nikula wrote:
> On Wed, 18 Apr 2018, José Roberto de Souza 
> wrote:
> > If the initial fbdev configuration(intel_fbdev_initial_config())
> > runs and
> > there still no sink connected it will cause
> > drm_fb_helper_initial_config() to return 0 as no error happened(but
> > internally the return is -EAGAIN).
> > Because no framebuffer was allocated, when a sink is connected
> > intel_fbdev_output_poll_changed() will not execute
> > drm_fb_helper_hotplug_event() that would trigger another try to do
> > the
> > initial fbdev configuration.
> > 
> > So here allowing drm_fb_helper_hotplug_event() to be executed when
> > there
> > is not frambebuffer allocated and fbdev was not setup yet.
> > 
> > This issue also happens when a MST DP sink is connected since boot,
> > as
> > the MST topology is discovered in parallel if
> > intel_fbdev_initial_config()
> > is executed before the first sink MST is discovered it will cause
> > this
> > same issue.
> > 
> > This is a follow up patch of
> > https://patchwork.freedesktop.org/patch/196089/
> 
> What does this mean? Is that patch a required dependency? What?

No requirement, this is just a follow up patch of that one, that patch
was not accepted and Chris did a suggestion that was implemented in the
first version.

> 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
> 
> People responded to v1, please ask them to test v2.

Okay, I just asked people to test the version 2 but I'm also able to
reproduce the issue and it was already tested.

> 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Chris Wilson 
> > Signed-off-by: José Roberto de Souza 
> > ---
> > 
> > Changes from v1:
> > - not creating a dump framebuffer anymore, instead just allowing
> > drm_fb_helper_hotplug_event() to execute when fbdev is not setup
> > yet.
> 
> Please look at git log in drm, and observe how we include the
> changelog
> in the commit message itself.

Okay, I will do that from now on.

> 
> BR,
> Jani.
> 
> > 
> >  drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index 7d41d139341b..e9e02b58b7be 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct
> > drm_device *dev)
> > return;
> >  
> > intel_fbdev_sync(ifbdev);
> > -   if (ifbdev->vma)
> > +   if (ifbdev->vma || ifbdev->helper.deferred_setup)
> > drm_fb_helper_hotplug_event(>helper);
> >  }
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for Enabling content-type setting for HDMI displays. (rev4)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev4)
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4069_full -> Patchwork_8753_full =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/4/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8753_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_flush@basic-wb-set-default:
  shard-glk:  PASS -> FAIL (fdo#105900)

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)


 Possible fixes 

igt@kms_cursor_legacy@flip-vs-cursor-atomic:
  shard-hsw:  FAIL (fdo#102670) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106134) -> PASS

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  FAIL (fdo#103933) -> PASS

igt@kms_vblank@pipe-a-accuracy-idle:
  shard-hsw:  FAIL (fdo#102583) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103933 https://bugs.freedesktop.org/show_bug.cgi?id=103933
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900
  fdo#106134 https://bugs.freedesktop.org/show_bug.cgi?id=106134


== Participating hosts (6 -> 4) ==

  Missing(2): shard-glkb shard-kbl 


== Build changes ==

* Linux: CI_DRM_4069 -> Patchwork_8753

  CI_DRM_4069: 8136363fe770a1a51688172d5ba46a5017f76677 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8753: 674d7cb399e989924e8fcc0dfafb1af895f7171e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm/i915: Move request->ctx aside

2018-04-19 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Move request->ctx aside
URL   : https://patchwork.freedesktop.org/series/41964/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4068_full -> Patchwork_8752_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8752_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8752_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41964/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8752_full:

  === IGT changes ===

 Possible regressions 

igt@gem_eio@wait-1us:
  shard-glk:  PASS -> FAIL


 Warnings 

igt@gem_mmap_wc@set-cache-level:
  shard-glk:  PASS -> SKIP +95

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +2

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +2

igt@kms_mmap_write_crc:
  shard-glk:  SKIP -> PASS +94


== Known issues ==

  Here are the changes found in Patchwork_8752_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@flip-vs-cursor-legacy:
  shard-hsw:  PASS -> FAIL (fdo#102670)

igt@kms_flip@flip-vs-modeset-vs-hang-interruptible:
  shard-kbl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558, 
fdo#103313) +1

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt:
  shard-kbl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558) +20


 Possible fixes 

igt@drv_suspend@forcewake:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106087) -> PASS

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#100368) -> SKIP

igt@kms_hdmi_inject@inject-audio:
  shard-glk:  FAIL (fdo#102370) -> PASS

igt@kms_setmode@basic:
  shard-glk:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102370 https://bugs.freedesktop.org/show_bug.cgi?id=102370
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8752

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8752: 85da0887e43c97fe443c440052e124aecbcb704a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8752/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: Fix drm:intel_enable_lvds ERROR message in kernel log (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log (rev2)
URL   : https://patchwork.freedesktop.org/series/34125/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4070 -> Patchwork_8757 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/34125/revisions/2/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8757 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (35 -> 32) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4070 -> Patchwork_8757

  CI_DRM_4070: 47f407780a2b330f097892203401986838eb9795 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8757: a10cd605896d1202fb6fae524200e2fd8b4e9bef @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

a10cd605896d drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Add code to accept valid locked WOPCM register values

2018-04-19 Thread Michal Wajdeczko

On Mon, 16 Apr 2018 20:43:39 +0200, Yaodong Li   
wrote:



On 04/13/2018 09:20 PM, Michal Wajdeczko wrote:
On Tue, 10 Apr 2018 02:42:19 +0200, Jackie Li   
wrote:


In current code, we only compare the locked WOPCM register values with  
the
calculated values. However, we can continue loading GuC/HuC firmware  
if the
locked (or partially locked) values were valid for current GuC/HuC  
firmware

sizes.

This patch added a new code path to verify whether the locked register
values can be used for GuC/HuC firmware loading, it will recalculate  
the
verify the new values if these registers were partially locked, so  
that we
won't fail the GuC/HuC firmware loading even if the locked register  
values

are different from the calculated ones.

v2:
 - Update WOPCM register only if it's not locked

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 217  
+++--

 1 file changed, 185 insertions(+), 32 deletions(-)

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

index b1c08ca..fa8d2be 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -140,6 +140,53 @@ static inline int check_hw_restriction(struct  
drm_i915_private *i915,

 return err;
 }
+static inline u32 calculate_min_guc_wopcm_base(u32 huc_fw_size)
+{
+return ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
+ GUC_WOPCM_OFFSET_ALIGNMENT);
+}
+
+static inline u32 calculate_min_guc_wopcm_size(u32 guc_fw_size)
+{
+return guc_fw_size + GUC_WOPCM_RESERVED +  
GUC_WOPCM_STACK_RESERVED;

+}
+
+static inline int calculate_max_guc_wopcm_size(struct intel_wopcm  
*wopcm,

+   u32 guc_wopcm_base,
+   u32 *guc_wopcm_size)


Can't we just return this size as positive value?
I guess wopcm size will never be larger than MAX_INT.
We can add GEM_BUG_ON to be sure.


+{
+struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+u32 ctx_rsvd = context_reserved_size(i915);
+
+if (guc_wopcm_base >= wopcm->size ||
+(guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
+DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
+  guc_wopcm_base / 1024);
+return -E2BIG;


You are mixing calculations with verifications here.
Focus on calculations as you have separate function that verifies  
values.



+}
+
+*guc_wopcm_size =
+(wopcm->size - guc_wopcm_base - ctx_rsvd) &  
GUC_WOPCM_SIZE_MASK;

+
+return 0;
+}
+
+static inline int verify_calculated_values(struct drm_i915_private


hmm, maybe we can unify somehow this verification to be able to work  
with

both calculated and locked values?
I actually thought about that. However, since the verification based on  
the assumption
that the unlocked reg value could be any numbers so it puts more checks  
on these values

which are unnecessary during the calculation.


maybe some checks would be "unnecessary" but they still should be valid.
and code reuse is nice benefit that sacrifice that few extra checks.


I've made the responding check common
enough to be reused by this verification code and the calculation code.



*i915,
+   u32 guc_fw_size, u32 huc_fw_size,
+   u32 guc_wopcm_base,
+   u32 guc_wopcm_size)
+{
+if (guc_wopcm_size < calculate_min_guc_wopcm_size(guc_fw_size)) {
+DRM_ERROR("Need %uKiB WOPCM for GuC FW, %uKiB available.\n",
+  calculate_min_guc_wopcm_size(guc_fw_size),


you are calling calculate_min_guc_wopcm_size() twice

Will update it.



+  guc_wopcm_size / 1024);
+return -E2BIG;
+}
+
+return check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+huc_fw_size);
+}
+
 /**
  * intel_wopcm_init() - Initialize the WOPCM structure.
  * @wopcm: pointer to intel_wopcm.
@@ -157,10 +204,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
 struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
 u32 guc_fw_size = intel_uc_fw_get_upload_size(>guc.fw);
 u32 huc_fw_size = intel_uc_fw_get_upload_size(>huc.fw);
-u32 ctx_rsvd = context_reserved_size(i915);
 u32 guc_wopcm_base;
 u32 guc_wopcm_size;
-u32 guc_wopcm_rsvd;
 int err;
GEM_BUG_ON(!wopcm->size);
@@ -177,35 +222,121 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
 return -E2BIG;
 }
-guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
-   GUC_WOPCM_OFFSET_ALIGNMENT);
-if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
-DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
-  guc_wopcm_base / 1024);
+

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable display WA#1183 from its correct spot

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915: Enable display WA#1183 from its correct spot
URL   : https://patchwork.freedesktop.org/series/41983/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4070 -> Patchwork_8756 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41983/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8756 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-cfl-s3:  PASS -> FAIL (fdo#100368, fdo#103928)

igt@prime_busy@basic-wait-after-default:
  fi-glk-1:   PASS -> INCOMPLETE (k.org#198133, fdo#103359)


 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128) -> PASS

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (35 -> 32) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4070 -> Patchwork_8756

  CI_DRM_4070: 47f407780a2b330f097892203401986838eb9795 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8756: 38a485385f9326dc10d8927c4d0647e0f3a6e1ad @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

38a485385f93 drm/i915: Enable display WA#1183 from its correct spot

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Enable display WA#1183 from its correct spot

2018-04-19 Thread Ville Syrjälä

On Thu, Apr 19, 2018 at 06:51:09PM +0300, Imre Deak wrote:
> The DMC FW specific part of display WA#1183 is supposed to be enabled
> whenever enabling DC5 or DC6, so move it to the DC6 enable function
> from the DC6 disable function.

That does make more sense :)

Reviewed-by: Ville Syrjälä 

> 
> I noticed this after Daniel's patch to remove the unused
> skl_disable_dc6() function.
> 
> Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
> Cc: Lucas De Marchi 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 53ea564f971e..66de4b2dc8b7 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -641,19 +641,18 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv)
>  
>   DRM_DEBUG_KMS("Enabling DC6\n");
>  
> - gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
> + /* Wa Display #1183: skl,kbl,cfl */
> + if (IS_GEN9_BC(dev_priv))
> + I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
> +SKL_SELECT_ALTERNATE_DC_EXIT);
>  
> + gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
>  }
>  
>  void skl_disable_dc6(struct drm_i915_private *dev_priv)
>  {
>   DRM_DEBUG_KMS("Disabling DC6\n");
>  
> - /* Wa Display #1183: skl,kbl,cfl */
> - if (IS_GEN9_BC(dev_priv))
> - I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
> -SKL_SELECT_ALTERNATE_DC_EXIT);
> -
>   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>  }
>  
> -- 
> 2.13.2

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

[Intel-gfx] [PATCH v2] drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

2018-04-19 Thread Ville Syrjala

From: Florent Flament 

Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
power on` in kernel log at boot time.

Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
on its screen during Intel i915 DRM initialization. This currently
results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
panel to power on` message appearing in the kernel log during boot
time and when stopping the machine.

This change increases the timeout of the `intel_enable_lvds` function
from 1 to 2 seconds, letting enough time for the Satellite 930 LCD
screen to power on, and suppressing the error message from the kernel
log.

This patch has been successfully tested on Linux 4.14 running on a
Toshiba Satellite Z930.

Signed-off-by: Florent Flament 
[vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
 code and properly cover the max hw timeout of ~4 seconds, and
 drop the comment about the specific machine since this is not
 a particulary surprising issue, nor specific to that one machine]
Cc: Pavel Petrovic 
Cc: Sérgio M. Basto 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
References: https://bugzilla.kernel.org/show_bug.cgi?id=57591
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_lvds.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index d35d2d50f595..8691c86f579c 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -326,7 +326,8 @@ static void intel_enable_lvds(struct intel_encoder *encoder,
 
I915_WRITE(PP_CONTROL(0), I915_READ(PP_CONTROL(0)) | PANEL_POWER_ON);
POSTING_READ(lvds_encoder->reg);
-   if (intel_wait_for_register(dev_priv, PP_STATUS(0), PP_ON, PP_ON, 1000))
+
+   if (intel_wait_for_register(dev_priv, PP_STATUS(0), PP_ON, PP_ON, 5000))
DRM_ERROR("timed out waiting for panel to power on\n");
 
intel_panel_enable_backlight(pipe_config, conn_state);
-- 
2.16.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)
URL   : https://patchwork.freedesktop.org/series/40747/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4068_full -> Patchwork_8751_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8751_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8751_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/40747/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8751_full:

  === IGT changes ===

 Warnings 

igt@gem_mmap_wc@set-cache-level:
  shard-glk:  PASS -> SKIP +71

igt@gem_mocs_settings@mocs-rc6-bsd1:
  shard-kbl:  SKIP -> PASS

igt@kms_mmap_write_crc:
  shard-glk:  SKIP -> PASS +93

igt@perf_pmu@rc6:
  shard-kbl:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_8751_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@flip-vs-cursor-toggle:
  shard-hsw:  PASS -> FAIL (fdo#102670) +1

igt@kms_flip@2x-flip-vs-dpms-interruptible:
  shard-hsw:  PASS -> DMESG-WARN (fdo#102614)

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-glk:  SKIP -> FAIL (fdo#100368)

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-apl:  PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#106023, fdo#103665) -> PASS

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS +2

igt@kms_hdmi_inject@inject-audio:
  shard-glk:  FAIL (fdo#102370) -> PASS

igt@kms_setmode@basic:
  shard-glk:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102370 https://bugs.freedesktop.org/show_bug.cgi?id=102370
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8751

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8751: 8e4bae99c5587cb819b3ebb7a22dd8d75883be1b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8751/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: Show number of objects without client

2018-04-19 Thread Chris Wilson

Quoting Mika Kuoppala (2018-04-19 16:34:27)
> Chris Wilson  writes:
> 
> > Quoting Mika Kuoppala (2018-04-19 15:16:16)
> >> Output the number of objects not tied to a client
> >> or to a vma. This amount should be quite small and
> >> on oom issues we can rule out significant bo leaks
> >> quickly by inspecting these values. Note that we are not
> >> fully accurate due to how we take and release the locks
> >> during transversal of related lists.
> >> 
> >> Cc: Chris Wilson 
> >> Cc: Eero Tamminen 
> >> Signed-off-by: Mika Kuoppala 
> >> ---
> >>  drivers/gpu/drm/i915/i915_debugfs.c | 24 +---
> >>  1 file changed, 17 insertions(+), 7 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> >> b/drivers/gpu/drm/i915/i915_debugfs.c
> >> index e0274f41bc76..b1cbecfca716 100644
> >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -354,8 +354,8 @@ static int per_file_stats(int id, void *ptr, void 
> >> *data)
> >>stats.unbound); \
> >>  } while (0)
> >>  
> >> -static void print_batch_pool_stats(struct seq_file *m,
> >> -  struct drm_i915_private *dev_priv)
> >> +static unsigned int print_batch_pool_stats(struct seq_file *m,
> >> +  struct drm_i915_private 
> >> *dev_priv)
> >>  {
> >> struct drm_i915_gem_object *obj;
> >> struct file_stats stats;
> >> @@ -375,6 +375,7 @@ static void print_batch_pool_stats(struct seq_file *m,
> >> }
> >>  
> >> print_file_stats(m, "[k]batch pool", stats);
> >> +   return stats.count;
> >>  }
> >>  
> >>  static int per_file_ctx_stats(int id, void *ptr, void *data)
> >> @@ -392,8 +393,8 @@ static int per_file_ctx_stats(int id, void *ptr, void 
> >> *data)
> >> return 0;
> >>  }
> >>  
> >> -static void print_context_stats(struct seq_file *m,
> >> -   struct drm_i915_private *dev_priv)
> >> +static unsigned int print_context_stats(struct seq_file *m,
> >> +   struct drm_i915_private *dev_priv)
> >>  {
> >> struct drm_device *dev = _priv->drm;
> >> struct file_stats stats;
> >> @@ -412,6 +413,7 @@ static void print_context_stats(struct seq_file *m,
> >> mutex_unlock(>struct_mutex);
> >>  
> >> print_file_stats(m, "[k]contexts", stats);
> >> +   return stats.count;
> >>  }
> >>  
> >>  static int i915_gem_object_info(struct seq_file *m, void *data)
> >> @@ -422,7 +424,7 @@ static int i915_gem_object_info(struct seq_file *m, 
> >> void *data)
> >> u32 count, mapped_count, purgeable_count, dpy_count, huge_count;
> >> u64 size, mapped_size, purgeable_size, dpy_size, huge_size;
> >> struct drm_i915_gem_object *obj;
> >> -   unsigned int page_sizes = 0;
> >> +   unsigned int page_sizes = 0, client_count = 0, vma_count = 0;
> >> struct drm_file *file;
> >> char buf[80];
> >> int ret;
> >> @@ -462,6 +464,7 @@ static int i915_gem_object_info(struct seq_file *m, 
> >> void *data)
> >> }
> >> }
> >> seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
> >> +   vma_count += count;
> >>  
> >> size = count = dpy_size = dpy_count = 0;
> >> list_for_each_entry(obj, _priv->mm.bound_list, mm.link) {
> >> @@ -490,6 +493,7 @@ static int i915_gem_object_info(struct seq_file *m, 
> >> void *data)
> >> }
> >> }
> >> spin_unlock(_priv->mm.obj_lock);
> >> +   vma_count += count;
> >>  
> >> seq_printf(m, "%u bound objects, %llu bytes\n",
> >>count, size);
> >> @@ -511,11 +515,11 @@ static int i915_gem_object_info(struct seq_file *m, 
> >> void *data)
> >> buf, sizeof(buf)));
> >>  
> >> seq_putc(m, '\n');
> >> -   print_batch_pool_stats(m, dev_priv);
> >> +   client_count += print_batch_pool_stats(m, dev_priv);
> >> mutex_unlock(>struct_mutex);
> >>  
> >> mutex_lock(>filelist_mutex);
> >> -   print_context_stats(m, dev_priv);
> >> +   client_count += print_context_stats(m, dev_priv);
> >> list_for_each_entry_reverse(file, >filelist, lhead) {
> >> struct file_stats stats;
> >> struct drm_i915_file_private *file_priv = 
> >> file->driver_priv;
> >> @@ -543,12 +547,18 @@ static int i915_gem_object_info(struct seq_file *m, 
> >> void *data)
> >> request->ctx->pid : file->pid,
> >> PIDTYPE_PID);
> >> print_file_stats(m, task ? task->comm : "", 
> >> stats);
> >> +   client_count += stats.count;
> >> rcu_read_unlock();
> >>  
> >>

Re: [Intel-gfx] [PATCH] drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance

2018-04-19 Thread Bloomfield, Jon

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Joonas Lahtinen
> Sent: Wednesday, April 18, 2018 3:43 AM
> To: Intel-gfx@lists.freedesktop.org; Tvrtko Ursulin 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Adjust BSD2 semantics to mean
> any second VCS instance
> 
> Quoting Tvrtko Ursulin (2018-04-18 12:33:42)
> > From: Tvrtko Ursulin 
> >
> > Currently our driver assumes BSD2 means hardware engine instance
> number
> > two. This does not work for Icelake parts with two VCS engines, but which
> > are hardware instances 0 and 2, and not 0 and 1 as with previous parts.
> >
> > This makes the second engine not discoverable via HAS_BSD2 get param,
> nor
> > it can be targetted by execbuf.
> >
> > While we are working on the next generation execbuf put in a hack which
> > allows discovery and access to this second VCS engine using legacy ABI.
> >
> > Signed-off-by: Tvrtko Ursulin 
> > Cc: Chris Wilson 
> > Cc: Jon Bloomfield 
> > Cc: Tony Ye 
> > ---
> > Compile tested only.
> >
> > Also, one could argue if this is just a temporary hack or could actually
> > make sense to have this permanently in. It feels like the ABI semantics of
> > BSD2 are blurry, or at least could be re-blurred for Gen11.
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c|  8 +++-
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +-
> >  2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> > index b7dbeba72dec..a185366d9beb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -331,7 +331,13 @@ static int i915_getparam_ioctl(struct drm_device
> *dev, void *data,
> > value = !!dev_priv->engine[VECS];
> > break;
> > case I915_PARAM_HAS_BSD2:
> > -   value = !!dev_priv->engine[VCS2];
> > +   /*
> > +* FIXME: Temporary hack for Icelake.
> > +*
> > +* Make semantics of HAS_BSD2 "has second", or "has two"
> VDBOXes
> > +* instead of "has VDBOX 2nd hardware instance".
> > +*/
> > +   value = dev_priv->engine[VCS2] || dev_priv->engine[VCS3];
> 
> There can be no temporary hacks for the uAPI... You either sign yourself
> up to keep it working indefinitely or don't :)
> 
> Regards, Joonas
This doesn't really change the API does it? In fact I'd argue this is simply 
fixing
a breakage in the API wrt to previous devices. It makes no sense to expose holes
in the engine map to userspace. If a device has two useable VCS engines, 
HAS_BSD2
should reflect that, and the second engine (wherever it sits physically), 
should be
addressable through the legacy BSD2 execbuf interface.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register

2018-04-19 Thread Michal Wajdeczko

On Mon, 16 Apr 2018 19:43:52 +0200, Yaodong Li   
wrote:



On 04/13/2018 07:26 PM, Michal Wajdeczko wrote:
On Tue, 10 Apr 2018 02:42:18 +0200, Jackie Li   
wrote:



The enable_guc modparam is used to enable/disable GuC/HuC FW uploading
dynamcially during i915 module loading. If WOPCM offset register was

  
typo


D'oh! I really need a tool for this! Thanks, will fix it.

locked
without having HUC_LOADING_AGENT_GUC bit set to 1, the module reloading
with both GuC and HuC FW will fail since we need to set this bit to 1  
for

HuC FW uploading.

Since HUC_LOADING_AGENT_GUC bit has no impact on GuC FW uploading, this
patch updates the register updating code to make sure the WOPCM offset
register is always locked with HUC_LOADING_AGENT_GUC bit set to 1 which
will guarantee successful uploading of both GuC and HuC FW. We will  
further

take care of the locked values in the following enhancement patch.

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

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

index 74bf76f..b1c08ca 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -238,8 +238,6 @@ static inline int write_and_verify(struct  
drm_i915_private *dev_priv,

 int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
 {
 struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
-u32 huc_agent;
-u32 mask;
 int err;
if (!USES_GUC(dev_priv))
@@ -255,10 +253,10 @@ int intel_wopcm_init_hw(struct intel_wopcm  
*wopcm)

 if (err)
 goto err_out;
-huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
-mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
 err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
-   wopcm->guc.base | huc_agent, mask,
+   wopcm->guc.base | HUC_LOADING_AGENT_GUC,
+   GUC_WOPCM_OFFSET_MASK | HUC_LOADING_AGENT_GUC |
+   GUC_WOPCM_OFFSET_VALID,


while we can unconditionally set HUC_AGENT bit, there is no need to  
verify

it unless we are using HuC, so we can consider leaving old mask intact.
The idea is to verify the written values are exactly we want, so I think  
it better

to keep doing it in this way.


Hmm, but then instead of being more flexible, you're unnecessary  
restricting

yourself to require HUC_AGENT bit, even if you don't need it - recall the
theoretical scenario with bad bios that already locked that register.

This seems to be little inconsistent with earlier patch where you try to
support much more different scenario (from no HuC fw to use HuC fw)

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

[Intel-gfx] [PATCH] drm/i915: Enable display WA#1183 from its correct spot

2018-04-19 Thread Imre Deak

The DMC FW specific part of display WA#1183 is supposed to be enabled
whenever enabling DC5 or DC6, so move it to the DC6 enable function
from the DC6 disable function.

I noticed this after Daniel's patch to remove the unused
skl_disable_dc6() function.

Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi 
Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 53ea564f971e..66de4b2dc8b7 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -641,19 +641,18 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv)
 
DRM_DEBUG_KMS("Enabling DC6\n");
 
-   gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
+   /* Wa Display #1183: skl,kbl,cfl */
+   if (IS_GEN9_BC(dev_priv))
+   I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
+  SKL_SELECT_ALTERNATE_DC_EXIT);
 
+   gen9_set_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
 }
 
 void skl_disable_dc6(struct drm_i915_private *dev_priv)
 {
DRM_DEBUG_KMS("Disabling DC6\n");
 
-   /* Wa Display #1183: skl,kbl,cfl */
-   if (IS_GEN9_BC(dev_priv))
-   I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
-  SKL_SELECT_ALTERNATE_DC_EXIT);
-
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
 }
 
-- 
2.13.2

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

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

2018-04-19 Thread Michal Wajdeczko


On Wed, 18 Apr 2018 19:01:31 +0200, Jackie Li  wrote:


After enabled the WOPCM write-once registers locking status checking,
reloading of the i915 module will fail with modparam enable_guc set to 3
(enable GuC and HuC firmware loading) if the module was originally loaded
with enable_guc set to 1 (only enable GuC firmware loading). This is
because WOPCM registers were updated and locked without considering the  
HuC

FW size. Since we need both GuC and HuC FW sizes to determine the final
layout of WOPCM, we should always calculate the WOPCM layout based on the
actual sizes of the GuC and HuC firmware available for a specific  
platform

if we need continue to support enable/disable HuC FW loading dynamically
with enable_guc modparam.

This patch splits uC firmware fetching into two stages. First stage is to
fetch the firmware image and verify the firmware header. uC firmware will
be marked as verified and this will make FW info available for following
WOPCM layout calculation. The second stage is to create a GEM object and
copy the FW data into the created GEM object which will only be available
when GuC/HuC loading is enabled by enable_guc modparam. This will  
guarantee
that the WOPCM layout will be always be calculated correctly without  
making

any assumptions to the GuC and HuC firmware sizes.

v3:
 - Rebase

v4:
 - Renamed the new parameter add to intel_uc_fw_fetch (Michal)

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
Reviewed-by: John Spotswood 
---
 drivers/gpu/drm/i915/intel_uc.c| 14 --
 drivers/gpu/drm/i915/intel_uc_fw.c | 31 ---
 drivers/gpu/drm/i915/intel_uc_fw.h |  7 +--
 3 files changed, 29 insertions(+), 23 deletions(-)

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

index 1cffaf7..73b8f6c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -172,11 +172,8 @@ void intel_uc_init_early(struct drm_i915_private  
*i915)

sanitize_options_early(i915);
-   if (USES_GUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
-
-   if (USES_HUC(i915))
-   intel_uc_fw_fetch(i915, >fw);
+   intel_uc_fw_fetch(i915, >fw, USES_GUC(i915));
+   intel_uc_fw_fetch(i915, >fw, USES_HUC(i915));


Again: I'm don't think that unconditional fetch of HuC fw is a right  
choice.

We should look for other options how to support enable_guc 1-->3 scenario.


 }
void intel_uc_cleanup_early(struct drm_i915_private *i915)
@@ -184,11 +181,8 @@ void intel_uc_cleanup_early(struct drm_i915_private  
*i915)

struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
-   if (USES_HUC(i915))
-   intel_uc_fw_fini(>fw);
-
-   if (USES_GUC(i915))
-   intel_uc_fw_fini(>fw);
+   intel_uc_fw_fini(>fw);
+   intel_uc_fw_fini(>fw);
guc_free_load_err_log(guc);
 }
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c  
b/drivers/gpu/drm/i915/intel_uc_fw.c

index 6e8e0b5..c1fed06 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -33,11 +33,13 @@
  *
  * @dev_priv: device private
  * @uc_fw: uC firmware
+ * @fetch: whether fetch uC firmware into GEM object or not
  *
- * Fetch uC firmware into GEM obj.
+ * Fetch and verify uC firmware and copy firmware data into GEM object  
if

+ * @fetch is true.
  */
 void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
-  struct intel_uc_fw *uc_fw)
+  struct intel_uc_fw *uc_fw, bool fetch)
 {
struct pci_dev *pdev = dev_priv->drm.pdev;
struct drm_i915_gem_object *obj;
@@ -154,17 +156,24 @@ void intel_uc_fw_fetch(struct drm_i915_private  
*dev_priv,

goto fail;
}
-   obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size);
-   if (IS_ERR(obj)) {
-   err = PTR_ERR(obj);
-   DRM_DEBUG_DRIVER("%s fw object_create err=%d\n",
-intel_uc_fw_type_repr(uc_fw->type), err);
-   goto fail;
+   uc_fw->size = fw->size;
+   uc_fw->fetch_status = INTEL_UC_FIRMWARE_VERIFIED;


btw, I'm not sure that this new state is needed at all, as you don't
plan to use that fw obj if you only loaded fw blob to read header...


+
+   if (fetch) {
+   obj = i915_gem_object_create_from_data(dev_priv, fw->data,
+  fw->size);
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
+   DRM_DEBUG_DRIVER("%s fw object_create err=%d\n",
+

Re: [Intel-gfx] [PATCH] drm/i915: Show number of objects without client

2018-04-19 Thread Mika Kuoppala

Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-04-19 15:16:16)
>> Output the number of objects not tied to a client
>> or to a vma. This amount should be quite small and
>> on oom issues we can rule out significant bo leaks
>> quickly by inspecting these values. Note that we are not
>> fully accurate due to how we take and release the locks
>> during transversal of related lists.
>> 
>> Cc: Chris Wilson 
>> Cc: Eero Tamminen 
>> Signed-off-by: Mika Kuoppala 
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c | 24 +---
>>  1 file changed, 17 insertions(+), 7 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index e0274f41bc76..b1cbecfca716 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -354,8 +354,8 @@ static int per_file_stats(int id, void *ptr, void *data)
>>stats.unbound); \
>>  } while (0)
>>  
>> -static void print_batch_pool_stats(struct seq_file *m,
>> -  struct drm_i915_private *dev_priv)
>> +static unsigned int print_batch_pool_stats(struct seq_file *m,
>> +  struct drm_i915_private *dev_priv)
>>  {
>> struct drm_i915_gem_object *obj;
>> struct file_stats stats;
>> @@ -375,6 +375,7 @@ static void print_batch_pool_stats(struct seq_file *m,
>> }
>>  
>> print_file_stats(m, "[k]batch pool", stats);
>> +   return stats.count;
>>  }
>>  
>>  static int per_file_ctx_stats(int id, void *ptr, void *data)
>> @@ -392,8 +393,8 @@ static int per_file_ctx_stats(int id, void *ptr, void 
>> *data)
>> return 0;
>>  }
>>  
>> -static void print_context_stats(struct seq_file *m,
>> -   struct drm_i915_private *dev_priv)
>> +static unsigned int print_context_stats(struct seq_file *m,
>> +   struct drm_i915_private *dev_priv)
>>  {
>> struct drm_device *dev = _priv->drm;
>> struct file_stats stats;
>> @@ -412,6 +413,7 @@ static void print_context_stats(struct seq_file *m,
>> mutex_unlock(>struct_mutex);
>>  
>> print_file_stats(m, "[k]contexts", stats);
>> +   return stats.count;
>>  }
>>  
>>  static int i915_gem_object_info(struct seq_file *m, void *data)
>> @@ -422,7 +424,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
>> *data)
>> u32 count, mapped_count, purgeable_count, dpy_count, huge_count;
>> u64 size, mapped_size, purgeable_size, dpy_size, huge_size;
>> struct drm_i915_gem_object *obj;
>> -   unsigned int page_sizes = 0;
>> +   unsigned int page_sizes = 0, client_count = 0, vma_count = 0;
>> struct drm_file *file;
>> char buf[80];
>> int ret;
>> @@ -462,6 +464,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
>> *data)
>> }
>> }
>> seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
>> +   vma_count += count;
>>  
>> size = count = dpy_size = dpy_count = 0;
>> list_for_each_entry(obj, _priv->mm.bound_list, mm.link) {
>> @@ -490,6 +493,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
>> *data)
>> }
>> }
>> spin_unlock(_priv->mm.obj_lock);
>> +   vma_count += count;
>>  
>> seq_printf(m, "%u bound objects, %llu bytes\n",
>>count, size);
>> @@ -511,11 +515,11 @@ static int i915_gem_object_info(struct seq_file *m, 
>> void *data)
>> buf, sizeof(buf)));
>>  
>> seq_putc(m, '\n');
>> -   print_batch_pool_stats(m, dev_priv);
>> +   client_count += print_batch_pool_stats(m, dev_priv);
>> mutex_unlock(>struct_mutex);
>>  
>> mutex_lock(>filelist_mutex);
>> -   print_context_stats(m, dev_priv);
>> +   client_count += print_context_stats(m, dev_priv);
>> list_for_each_entry_reverse(file, >filelist, lhead) {
>> struct file_stats stats;
>> struct drm_i915_file_private *file_priv = file->driver_priv;
>> @@ -543,12 +547,18 @@ static int i915_gem_object_info(struct seq_file *m, 
>> void *data)
>> request->ctx->pid : file->pid,
>> PIDTYPE_PID);
>> print_file_stats(m, task ? task->comm : "", stats);
>> +   client_count += stats.count;
>> rcu_read_unlock();
>>  
>> mutex_unlock(>struct_mutex);
>> }
>> mutex_unlock(>filelist_mutex);
>>  
>> +   seq_printf(m, "\n%d objects without vma\n",
>> +  dev_priv->mm.object_count - vma_count);
>
> What does "without vma" mean? Instantiated but never used on the gpu, a
> very small subset of unbound. I'm

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

2018-04-19 Thread Michal Wajdeczko

On Mon, 16 Apr 2018 19:28:04 +0200, Yaodong Li   
wrote:



On 04/13/2018 07:15 PM, Michal Wajdeczko wrote:
On Tue, 10 Apr 2018 02:42:17 +0200, Jackie Li   
wrote:



After enabled the WOPCM write-once registers locking status checking,
reloading of the i915 module will fail with modparam enable_guc set to  
3
(enable GuC and HuC firmware loading) if the module was originally  
loaded

with enable_guc set to 1 (only enable GuC firmware loading).


Is this frequent and required scenario ? or just for debug/development ?

My understanding is this should be a nice to have feature and mainly for  
debugging.

This is
because WOPCM registers were updated and locked without considering  
the HuC

FW size. Since we need both GuC and HuC FW sizes to determine the final
layout of WOPCM, we should always calculate the WOPCM layout based on  
the
actual sizes of the GuC and HuC firmware available for a specific  
platform
if we need continue to support enable/disable HuC FW loading  
dynamically

with enable_guc modparam.

This patch splits uC firmware fetching into two stages. First stage is  
to
fetch the firmware image and verify the firmware header. uC firmware  
will
be marked as verified and this will make FW info available for  
following
WOPCM layout calculation. The second stage is to create a GEM object  
and
copy the FW data into the created GEM object which will only be  
available
when GuC/HuC loading is enabled by enable_guc modparam. This will  
guarantee
that the WOPCM layout will be always be calculated correctly without  
making

any assumptions to the GuC and HuC firmware sizes.


You are also assuming that on reload exactly the same GuC/HuC firmwares
will bee used as in initial run. This will make this useless for debug/
development scenarios, where custom fw are likely to be specified.

This patch is mainly for providing a real fix to support  
enable_guc=1->3->1 use case.
It based on the fact that it is inevitable that sometimes we need to  
reboot the system

if the status of the fw was changed on the file system.


What do you mean by "status of the fw was changed on the file system" ?
* change of the fw binary/version/size, or
* change from not-present to present ?

I am not sure how often we switch between different HuC FW with  
different sizes?


Just above you said that you need this "mainly for debugging" so
I would expect that then different fw sizes are expected.


If we want to support enable_guc=1->3->1 scenarios for debug/dev then
maybe more flexible will be other approach that makes allocations from
the other end as proposed in [1]

[1] https://patchwork.freedesktop.org/patch/212471/
Actually, I do think this might be one of the options, and I've also put  
some comments on this
series. The main concern I have is it still make assumption on the GuC  
FW size and may


But in enable_guc=1-->3 scenario, I would assume that the only difference
will be HuC fw (as with enable=1 we already loaded GuC)

If you want just to test different GuC fws, then it is different scenario
as then enable_guc will always be = 1.


run into the same issue if the GuC FW failed to meet the requirement.
and for debugging purpose it would have the same possible for different  
GuC FW debugging.




v3:
 - Rebase

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: John Spotswood 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.c| 14 --
 drivers/gpu/drm/i915/intel_uc_fw.c | 31  
---

 drivers/gpu/drm/i915/intel_uc_fw.h |  7 +--
 3 files changed, 29 insertions(+), 23 deletions(-)

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

index 1cffaf7..73b8f6c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -172,11 +172,8 @@ void intel_uc_init_early(struct drm_i915_private  
*i915)

sanitize_options_early(i915);
-if (USES_GUC(i915))
-intel_uc_fw_fetch(i915, >fw);
-
-if (USES_HUC(i915))
-intel_uc_fw_fetch(i915, >fw);
+intel_uc_fw_fetch(i915, >fw, USES_GUC(i915));
+intel_uc_fw_fetch(i915, >fw, USES_HUC(i915));


Hmm, side effect of those unconditional fetches might be unwanted  
warnings
about missing firmwares (on configs with disabled guc) as well as  
extended

driver load time.
Hmm, if HAS_GUC is false then fw path would be NULL. The fetch will  
return directly.


I was referring to scenario when on platform with HAS_HUC and with
enable_guc=1 (just submission, no HuC) we will try to fetch HuC fw
(that may not be present at all) and then drop it as don't need it.



Do we really need to support this corner case enable_guc=1->3 at all  
costs?
I think this is the real solution for this issue (with no

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show number of objects without client

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915: Show number of objects without client
URL   : https://patchwork.freedesktop.org/series/41977/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4069 -> Patchwork_8755 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41977/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8755 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@basic-flip-vs-modeset:
  fi-cnl-y3:  PASS -> INCOMPLETE (fdo#105086)

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)
  fi-glk-1:   SKIP -> INCOMPLETE (k.org#198133, fdo#103359)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS


  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (35 -> 32) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4069 -> Patchwork_8755

  CI_DRM_4069: 8136363fe770a1a51688172d5ba46a5017f76677 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8755: d1e9cd01619a872f2642503e1490c2184042f048 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

d1e9cd01619a drm/i915: Show number of objects without client

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8755/issues.html
___
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_ppgtt: Flush the driver to idle before counting leaks

2018-04-19 Thread Tvrtko Ursulin



On 19/04/2018 06:48, Chris Wilson wrote:

I have a cunning plan to make the vma open/close lazy to cache frequent
reallocations (as buffers are passed between applications, e.g. DRI).
However, this will mean that we will not be immediately closing vma and
so need to tell the kernel to process the idle handlers before checking
for leaks.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tests/gem_ppgtt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/gem_ppgtt.c b/tests/gem_ppgtt.c
index bed95db83..575b0e9d3 100644
--- a/tests/gem_ppgtt.c
+++ b/tests/gem_ppgtt.c
@@ -236,7 +236,7 @@ static void flink_and_close(void)
gem_sync(fd2, flinked_bo);
gem_close(fd2, flinked_bo);
  
-	igt_drop_caches_set(fd, DROP_RETIRE);

+   igt_drop_caches_set(fd, DROP_RETIRE | DROP_IDLE);
  
  	/* the flinked bo VMA should have been cleared now, so a new bo of the

 * same size should get the same offset
@@ -286,7 +286,7 @@ static void flink_and_exit(void)
exec_and_get_offset(fd3, gem_create(fd3, 4096));
close(fd3);
  
-	igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE);

+   igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE | DROP_IDLE);
igt_assert(!igt_debugfs_search(fd, "i915_gem_gtt", match));
  
  	close(fd);




It's not interfering with test intentions so:

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Show number of objects without client

2018-04-19 Thread Chris Wilson

Quoting Mika Kuoppala (2018-04-19 15:16:16)
> Output the number of objects not tied to a client
> or to a vma. This amount should be quite small and
> on oom issues we can rule out significant bo leaks
> quickly by inspecting these values. Note that we are not
> fully accurate due to how we take and release the locks
> during transversal of related lists.
> 
> Cc: Chris Wilson 
> Cc: Eero Tamminen 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e0274f41bc76..b1cbecfca716 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -354,8 +354,8 @@ static int per_file_stats(int id, void *ptr, void *data)
>stats.unbound); \
>  } while (0)
>  
> -static void print_batch_pool_stats(struct seq_file *m,
> -  struct drm_i915_private *dev_priv)
> +static unsigned int print_batch_pool_stats(struct seq_file *m,
> +  struct drm_i915_private *dev_priv)
>  {
> struct drm_i915_gem_object *obj;
> struct file_stats stats;
> @@ -375,6 +375,7 @@ static void print_batch_pool_stats(struct seq_file *m,
> }
>  
> print_file_stats(m, "[k]batch pool", stats);
> +   return stats.count;
>  }
>  
>  static int per_file_ctx_stats(int id, void *ptr, void *data)
> @@ -392,8 +393,8 @@ static int per_file_ctx_stats(int id, void *ptr, void 
> *data)
> return 0;
>  }
>  
> -static void print_context_stats(struct seq_file *m,
> -   struct drm_i915_private *dev_priv)
> +static unsigned int print_context_stats(struct seq_file *m,
> +   struct drm_i915_private *dev_priv)
>  {
> struct drm_device *dev = _priv->drm;
> struct file_stats stats;
> @@ -412,6 +413,7 @@ static void print_context_stats(struct seq_file *m,
> mutex_unlock(>struct_mutex);
>  
> print_file_stats(m, "[k]contexts", stats);
> +   return stats.count;
>  }
>  
>  static int i915_gem_object_info(struct seq_file *m, void *data)
> @@ -422,7 +424,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
> *data)
> u32 count, mapped_count, purgeable_count, dpy_count, huge_count;
> u64 size, mapped_size, purgeable_size, dpy_size, huge_size;
> struct drm_i915_gem_object *obj;
> -   unsigned int page_sizes = 0;
> +   unsigned int page_sizes = 0, client_count = 0, vma_count = 0;
> struct drm_file *file;
> char buf[80];
> int ret;
> @@ -462,6 +464,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
> *data)
> }
> }
> seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
> +   vma_count += count;
>  
> size = count = dpy_size = dpy_count = 0;
> list_for_each_entry(obj, _priv->mm.bound_list, mm.link) {
> @@ -490,6 +493,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
> *data)
> }
> }
> spin_unlock(_priv->mm.obj_lock);
> +   vma_count += count;
>  
> seq_printf(m, "%u bound objects, %llu bytes\n",
>count, size);
> @@ -511,11 +515,11 @@ static int i915_gem_object_info(struct seq_file *m, 
> void *data)
> buf, sizeof(buf)));
>  
> seq_putc(m, '\n');
> -   print_batch_pool_stats(m, dev_priv);
> +   client_count += print_batch_pool_stats(m, dev_priv);
> mutex_unlock(>struct_mutex);
>  
> mutex_lock(>filelist_mutex);
> -   print_context_stats(m, dev_priv);
> +   client_count += print_context_stats(m, dev_priv);
> list_for_each_entry_reverse(file, >filelist, lhead) {
> struct file_stats stats;
> struct drm_i915_file_private *file_priv = file->driver_priv;
> @@ -543,12 +547,18 @@ static int i915_gem_object_info(struct seq_file *m, 
> void *data)
> request->ctx->pid : file->pid,
> PIDTYPE_PID);
> print_file_stats(m, task ? task->comm : "", stats);
> +   client_count += stats.count;
> rcu_read_unlock();
>  
> mutex_unlock(>struct_mutex);
> }
> mutex_unlock(>filelist_mutex);
>  
> +   seq_printf(m, "\n%d objects without vma\n",
> +  dev_priv->mm.object_count - vma_count);

What does "without vma" mean? Instantiated but never used on the gpu, a
very small subset of unbound. I'm not sure if it has value and worry
that "without vma" is unclear internal language.

"%d unused objects (without any attached vma)" I think works better.

> +

Re: [Intel-gfx] [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

2018-04-19 Thread Maarten Lankhorst

Op 19-04-18 om 13:05 schreef Fengguang Wu:
> Hi Maarten,
>
>> What extra dmesg output do you get when you boot with drm.debug=0x1f ?
>
> Attached is the dmesg with drm.debug=0x1f.
>
> Thanks,
> Fengguang

Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768:

kern  :debug : [   74.880444] [drm:i9xx_get_initial_plane_config [i915]] pipe 
A/primary A with fb: size=1366x768@32, offset=61000, pitch 5504, size 0x408000
kern  :debug : [   74.881187] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x00408000
kern  :debug : [   74.882197] [drm:intel_alloc_initial_plane_obj.isra.126 
[i915]] initial plane fb obj 5efa24f9

kern  :debug : [   74.883532] [drm:i9xx_get_initial_plane_config [i915]] pipe 
B/primary B with fb: size=1280x1024@32, offset=61000, pitch 5504, size 0x56
kern  :debug : [   74.884260] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x0056
kern  :debug : [   74.885295] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] failed to allocate 
stolen space

Which of course fails, but should be an interesting case to handle right. :)

~Maarten

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

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Maarten Lankhorst

Op 19-04-18 om 13:50 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 01:30:32PM +0200, Maarten Lankhorst wrote:
>> Op 19-04-18 om 13:22 schreef Ville Syrjälä:
>>> On Thu, Apr 19, 2018 at 02:36:42AM +, Srinivas, Vidya wrote:


> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, April 19, 2018 12:06 AM
> To: Maarten Lankhorst 
> Cc: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> skl_check_nv12_surface for NV12
> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
 From: Maarten Lankhorst 
 >
 We skip src trunction/adjustments for
 NV12 case and handle the sizes directly.
 Without this, pipe fifo underruns are seen on APL/KBL.
 v2: For NV12, making the src coordinates multiplier of 4
 v3: Moving all the src coords handling code for NV12 to
 skl_check_nv12_surface
 Signed-off-by: Maarten Lankhorst
 >
 Signed-off-by: Vidya Srinivas 
 >
 ---
  drivers/gpu/drm/i915/intel_display.c | 39
 
  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
  2 files changed, 50 insertions(+), 4 deletions(-)
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index 925402e..b8dbaca 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
> struct intel_crtc_state *crtc_state,
  return 0;
  }
 +static int
 +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
 +   struct intel_plane_state 
 *plane_state) {
 +int crtc_x2 = plane_state->base.crtc_x + 
 plane_state->base.crtc_w;
 +int crtc_y2 = plane_state->base.crtc_y +
 +plane_state->base.crtc_h;
 +
 +if (((plane_state->base.src_x >> 16) % 4) != 0 ||
 +((plane_state->base.src_y >> 16) % 4) != 0 ||
 +((plane_state->base.src_w >> 16) % 4) != 0 ||
 +((plane_state->base.src_h >> 16) % 4) != 0) {
 +DRM_DEBUG_KMS("src coords must be 
 multiple of 4 for
> NV12\n");
 +return -EINVAL;
 +}
>>> I don't really see why we should check these. The clipped
>>> coordinates are what matters.
>> To propagate our limits to the userspace. I think we should do it for
>> all formats, but NV12 is the first YUV format we have tests for. If we
>> could we should do something similar for the other YUV formats, but they
> have different requirements.
>> In case of NV12 we don't have existing userspace, there will be
>> nothing that breaks if we enforce limits from the start.
> But what about sub-pixel coordinates? You're totally ignoring them here.
> We need to come up with some proper rules for this stuff.
 +
 +/* Clipping would cause a 1-3 pixel gap at the edge 
 of the screen? */
 +if ((crtc_x2 > crtc_state->pipe_src_w && 
 crtc_state->pipe_src_w %
> 4) ||
 +(crtc_y2 > crtc_state->pipe_src_h && 
 crtc_state->pipe_src_h % 4))
> {
 +DRM_DEBUG_KMS("It's not possible to 
 clip %u,%u to
> %u,%u\n",
 +  crtc_x2, 
 crtc_y2,
 +  
 crtc_state->pipe_src_w, crtc_state->pipe_src_h);
 +return -EINVAL;
 +}
>>> Why should we care? The current code already plays it fast and loose
>>> and allows the dst rectangle to shrink to accomodate the hw limits.
>>> If we want to change that we should change it universally.
>> Unfortunately for the other formats we already have an existing
>> userspace
>> (X.org) that doesn't perform any validation. We can't change it for
>> that, but we can prevent future mistakes.
> We should do it uniformly. Not per-format. That will make the code

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable NV12 support (rev3)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enable NV12 support (rev3)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4068_full -> Patchwork_8750_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8750_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8750_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/3/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8750_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-bsd1:
  shard-kbl:  SKIP -> PASS +1

igt@kms_mmap_write_crc:
  shard-glk:  SKIP -> PASS +93

igt@kms_plane@plane-panning-bottom-right-pipe-a-planes:
  shard-glk:  PASS -> SKIP +103

igt@perf_pmu@rc6:
  shard-kbl:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_8750_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_crc@cursor-128x128-suspend:
  shard-snb:  PASS -> DMESG-WARN (fdo#102365)

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-apl:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  SKIP -> FAIL (fdo#102887)

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_vblank@pipe-a-ts-continuation-modeset:
  shard-hsw:  PASS -> DMESG-WARN (fdo#102614) +1


 Possible fixes 

igt@drv_suspend@forcewake:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106087) -> SKIP

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS +1

igt@kms_hdmi_inject@inject-audio:
  shard-glk:  FAIL (fdo#102370) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
  fdo#102370 https://bugs.freedesktop.org/show_bug.cgi?id=102370
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8750

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8750: 81fc20b459963794dc35ce57ecf8a5761488ea97 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Show number of objects without client

2018-04-19 Thread Mika Kuoppala

Output the number of objects not tied to a client
or to a vma. This amount should be quite small and
on oom issues we can rule out significant bo leaks
quickly by inspecting these values. Note that we are not
fully accurate due to how we take and release the locks
during transversal of related lists.

Cc: Chris Wilson 
Cc: Eero Tamminen 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e0274f41bc76..b1cbecfca716 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -354,8 +354,8 @@ static int per_file_stats(int id, void *ptr, void *data)
   stats.unbound); \
 } while (0)
 
-static void print_batch_pool_stats(struct seq_file *m,
-  struct drm_i915_private *dev_priv)
+static unsigned int print_batch_pool_stats(struct seq_file *m,
+  struct drm_i915_private *dev_priv)
 {
struct drm_i915_gem_object *obj;
struct file_stats stats;
@@ -375,6 +375,7 @@ static void print_batch_pool_stats(struct seq_file *m,
}
 
print_file_stats(m, "[k]batch pool", stats);
+   return stats.count;
 }
 
 static int per_file_ctx_stats(int id, void *ptr, void *data)
@@ -392,8 +393,8 @@ static int per_file_ctx_stats(int id, void *ptr, void *data)
return 0;
 }
 
-static void print_context_stats(struct seq_file *m,
-   struct drm_i915_private *dev_priv)
+static unsigned int print_context_stats(struct seq_file *m,
+   struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = _priv->drm;
struct file_stats stats;
@@ -412,6 +413,7 @@ static void print_context_stats(struct seq_file *m,
mutex_unlock(>struct_mutex);
 
print_file_stats(m, "[k]contexts", stats);
+   return stats.count;
 }
 
 static int i915_gem_object_info(struct seq_file *m, void *data)
@@ -422,7 +424,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
u32 count, mapped_count, purgeable_count, dpy_count, huge_count;
u64 size, mapped_size, purgeable_size, dpy_size, huge_size;
struct drm_i915_gem_object *obj;
-   unsigned int page_sizes = 0;
+   unsigned int page_sizes = 0, client_count = 0, vma_count = 0;
struct drm_file *file;
char buf[80];
int ret;
@@ -462,6 +464,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
}
}
seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
+   vma_count += count;
 
size = count = dpy_size = dpy_count = 0;
list_for_each_entry(obj, _priv->mm.bound_list, mm.link) {
@@ -490,6 +493,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
}
}
spin_unlock(_priv->mm.obj_lock);
+   vma_count += count;
 
seq_printf(m, "%u bound objects, %llu bytes\n",
   count, size);
@@ -511,11 +515,11 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
buf, sizeof(buf)));
 
seq_putc(m, '\n');
-   print_batch_pool_stats(m, dev_priv);
+   client_count += print_batch_pool_stats(m, dev_priv);
mutex_unlock(>struct_mutex);
 
mutex_lock(>filelist_mutex);
-   print_context_stats(m, dev_priv);
+   client_count += print_context_stats(m, dev_priv);
list_for_each_entry_reverse(file, >filelist, lhead) {
struct file_stats stats;
struct drm_i915_file_private *file_priv = file->driver_priv;
@@ -543,12 +547,18 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
request->ctx->pid : file->pid,
PIDTYPE_PID);
print_file_stats(m, task ? task->comm : "", stats);
+   client_count += stats.count;
rcu_read_unlock();
 
mutex_unlock(>struct_mutex);
}
mutex_unlock(>filelist_mutex);
 
+   seq_printf(m, "\n%d objects without vma\n",
+  dev_priv->mm.object_count - vma_count);
+   seq_printf(m, "%d objects without client\n",
+  dev_priv->mm.object_count - client_count);
+
return 0;
 }
 
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

2018-04-19 Thread Jani Nikula

On Wed, 18 Apr 2018, Mika Kahola  wrote:
> When reading out CRC's we  wait for a vblank on intel_dp_sink_crc_start()
> function. When we start reading out CRC's in intel_dp_sink_crc() loop we
> first wait for a vblank yielding that all in all we end up waiting two
> vblanks on the first iteration round. Therefore, let's move the
> intel_wait_for_vblank() as the last routine that we do in an iteration loop
> in intel_dp_sink_crc().
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103166

Umm, do the CI failures in the bug really use sink crc, or are they
rather about pipe crc?

BR,
Jani.


> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4..6eb97fa 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3972,13 +3972,14 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, 
> struct intel_crtc_state *crtc_s
>   return ret;
>  
>   do {
> - intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
> -
>   if (drm_dp_dpcd_readb(_dp->aux,
> DP_TEST_SINK_MISC, ) < 0) {
>   ret = -EIO;
>   goto stop;
>   }
> +
> + intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
> +
>   count = buf & DP_TEST_COUNT_MASK;
>  
>   } while (--attempts && count == 0);

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated 
buffers (rev2)
URL   : https://patchwork.freedesktop.org/series/40929/
State : failure

== Summary ==

Applying: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated 
buffers
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/i915_gem_stolen.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915: Do NOT skip the first 4k of stolen memory for 
pre-allocated buffers
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsi: fix dphy param field widths and range checks for chv+

2018-04-19 Thread Jani Nikula

On Thu, 19 Apr 2018, Jani Nikula  wrote:
> On Thu, 19 Apr 2018, Ville Syrjälä  wrote:
>> On Thu, Apr 19, 2018 at 11:59:40AM +0300, Jani Nikula wrote:
>>> Current CHV and BXT bspec says the dphy param register has four 8-bit
>>> fields instead of the smaller VLV field widths. CHV bspec mentions the
>>> register has changed since K0, but there's no indication of what exactly
>>> changed. Lacking further details, change the field widths for all CHV
>>> and later.
>>
>> K0 didn't happen, and looks like the linked HSD specifically says that
>> this change was meant for K0. So I suspect this patch is wrong.
>
> Oh well. The referenced bug indicated overflow in the logs, so I figured
> this might be it.
>
> I pushed patch 1 for now.
>
>> The BXT HSD says planned for B0, but not sure if that actually happened
>> either.
>>
>> On my VLV the reserved bits can't be set:
>> intel_reg write 0x18:0xb080 0x
>> intel_reg write 0x18:0xb880 0x
>> intel_reg read 0x18:0xb080 0x18:0xb880
>>  (0x0018:0xb080): 0x3f1fff3f
>>  (0x0018:0xb880): 0x3f1fff3f
>>
>> So presumably the same rmw trick could be used to check what
>> how many bits we have on CHV/BXT.
>
> Asked on the bug, let's see if we get a response.

Confirms what you said:

(0x0018:0xb080): 0x3f1fff3f
(0x0018:0xb880): 0x3f1fff3f

BR,
Jani.

>
> BR,
> Jani.
>
>>
>> Also looks like the CHV spec was forked from VLV before someone fixed
>> the prepare count to be 6 bits, which seems to be what my VLV actually
>> has as well. Not the first time the VLV docs are more up to date than
>> the CHV ones unfortunately.
>>
>>> 
>>> Define the max values based on the platform. Also define them based on
>>> the register definitions instead of duplicating information.
>>> 
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106130
>>> Cc: sta...@vger.kernel.org
>>> Cc: Ville Syrjälä 
>>> Signed-off-by: Jani Nikula 
>>> ---
>>>  drivers/gpu/drm/i915/i915_reg.h  | 11 +++
>>>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 31 +++
>>>  2 files changed, 26 insertions(+), 16 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index fb106026a1f4..f4435a13b757 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -9547,14 +9547,17 @@ enum skl_power_gate {
>>>  #define _MIPIA_DPHY_PARAM  (dev_priv->mipi_mmio_base + 0xb080)
>>>  #define _MIPIC_DPHY_PARAM  (dev_priv->mipi_mmio_base + 0xb880)
>>>  #define MIPI_DPHY_PARAM(port)  _MMIO_MIPI(port, 
>>> _MIPIA_DPHY_PARAM, _MIPIC_DPHY_PARAM)
>>> -#define  EXIT_ZERO_COUNT_SHIFT 24
>>>  #define  EXIT_ZERO_COUNT_MASK  (0x3f << 24)
>>> -#define  TRAIL_COUNT_SHIFT 16
>>> +#define  EXIT_ZERO_COUNT_MASK_CHV  (0xff << 24)
>>> +#define  EXIT_ZERO_COUNT_SHIFT 24
>>>  #define  TRAIL_COUNT_MASK  (0x1f << 16)
>>> -#define  CLK_ZERO_COUNT_SHIFT  8
>>> +#define  TRAIL_COUNT_MASK_CHV  (0xff << 16)
>>> +#define  TRAIL_COUNT_SHIFT 16
>>>  #define  CLK_ZERO_COUNT_MASK   (0xff << 8)
>>> -#define  PREPARE_COUNT_SHIFT   0
>>> +#define  CLK_ZERO_COUNT_SHIFT  8
>>>  #define  PREPARE_COUNT_MASK(0x3f << 0)
>>> +#define  PREPARE_COUNT_MASK_CHV(0xff << 0)
>>> +#define  PREPARE_COUNT_SHIFT   0
>>>  
>>>  /* bits 31:0 */
>>>  #define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
>>> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
>>> index 4d6ffa7b3e7b..8d3dea693840 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
>>> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
>>> @@ -41,10 +41,17 @@
>>>  #define MIPI_VIRTUAL_CHANNEL_SHIFT 1
>>>  #define MIPI_PORT_SHIFT3
>>>  
>>> -#define PREPARE_CNT_MAX0x3F
>>> -#define EXIT_ZERO_CNT_MAX  0x3F
>>> -#define CLK_ZERO_CNT_MAX   0xFF
>>> -#define TRAIL_CNT_MAX  0x1F
>>> +#define EXIT_ZERO_CNT_MAX(dev_priv) \
>>> +   ((IS_VALLEYVIEW(dev_priv) ? EXIT_ZERO_COUNT_MASK : 
>>> EXIT_ZERO_COUNT_MASK_CHV) >> EXIT_ZERO_COUNT_SHIFT)
>>> +
>>> +#define TRAIL_CNT_MAX(dev_priv) \
>>> +   ((IS_VALLEYVIEW(dev_priv) ? TRAIL_COUNT_MASK : TRAIL_COUNT_MASK_CHV) >> 
>>> TRAIL_COUNT_SHIFT)
>>> +
>>> +#define CLK_ZERO_CNT_MAX(dev_priv) \
>>> +   (CLK_ZERO_COUNT_MASK >> CLK_ZERO_COUNT_SHIFT)
>>> +
>>> +#define PREPARE_CNT_MAX(dev_priv)  \
>>> +   ((IS_VALLEYVIEW(dev_priv) ? PREPARE_COUNT_MASK : 
>>>

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

2018-04-19 Thread Hans de Goede


Hi,

On 05-04-18 15:26, Daniel Vetter wrote:

On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede  wrote:

Hi,


On 05-04-18 09:14, Daniel Vetter wrote:


On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote:


Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range
passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try
and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to
fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).

Signed-off-by: Hans de Goede 



I think this is worth a shot. The only explanation I can think of why the
GOP could get away with this and still follow the w/a is if it doesn't
have a 1:1 mapping between GGTT and stolen.



My guess is that the GOP does not care about the w/a because the w/a
states that the command-streamers sometimes do a spurious flush (write)
to the first page, and the command-streamers are not used until much
later, so the GOP is probably ignoring the w/a all together.

At least that is my theory.


Atm we do not know whether the GOP actually implements the wa or not.
That it doesn't care is just a conjecture, but we have no proof. On
previous platforms the 1:1 mapping did hold, but there's no
fundamental reason why it sitll does.


Right.


Atm we hardcode that
assumption in intel_alloc_initial_plane_obj by passing the base_aligned as
both the stolen_offset and the gtt_offset (but it's only the gtt_offset
really). And since we're not re-writing the ptes it's not noticeable.

I think to decide whether this is the right approach we should
double-check whether that 1:1 assumption really holds true: Either read
back the ggtt ptes and check their addresses (but iirc on some platforms
their write-only, readback doesn't work), or we also rewrite the ptes
again for preallocated stuff, like when binding a normal object into the
gtt. If either of these approaches confirms that those affected gen8+
machines still use the 1:1 mapping, then I'm happy to put my r-b on this
patch. If not, well then we at least know what to fix: We need to read out
the real stolen_offset, instead of making assumptions.



I'm happy to give this a try on one or more affected machines, I can e.g.
try this on both a skylake desktop and a cherry-trail based tablet.

But I'm clueless about the whole PTE stuff, so I'm going to need someone
to provide me with a patch following either approach. If readback of the
PTEs works on skylake / cherrytrail I guess that would be the best way.

Note to test this I'm currently booting the kernel with the machine's
UEFI vendor logo still being displayed when efifb kicks in. I've added:
"fbcon=vc:2-62" to the kernel commandline to make fbcon not bind to
VC0 / VC1, so that the framebuffer contents stays intact, combined with
the patch we are discussing now, this makes the vendor logo stay on
the screen all the way till GDM loads, which looks rather nice actually :)

And on shutdown we fall back to the original framebuffer and the vendor
logo is back again. I cannot see any corruption in the display at either
boot or shutdown time.


It shouldn't matter whether efifb takes over or not, it's still the
GOP's framebuffer we're taking over. Different content for sure, logo
is gone, but we only care about which pages we're using.

Wrt the code:
- (Re)binding happens by calling i915_vma_bind, if you put a call to
that at the end of the stolen_preallocated functions you should get
that. Ofc needs the logo still there so you can see it jump/get
mangled.
- GGTT PTEs for gen8+ are written through e.g. gen8_ggttt_insert_page
or gen8_ggtt_insert_entries (which takes the vma). Since we only care
about

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

2018-04-19 Thread Jani Nikula

On Thu, 19 Apr 2018, vathsala nagaraju  wrote:
> From: Vathsala Nagaraju 
>
> For psr block #9, the vbt description has moved to options [0-3] for
> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
> structure. Since spec does not  mention from which VBT version this
> change was added to vbt.bsf file, we cannot depend on bdb->version check
> to change for all the platforms.
>
> There is RCR inplace for GOP team to  provide the version number
> to make generic change. Since Kabylake with bdb version 209 is having this
> change, limiting this change to kbl and version 209+ to unblock google.

This is an incredible mess.

> Tested on skl(bdb version 203,without options) and
> kabylake(bdb version 209,212) having new options.
>
> bspec 20131
>
> v2: (Jani and Rodrigo)
> move the 165 version check to intel_bios.c
> v3: Jani
> move the abstraction to intel_bios
>
> Cc: Rodrigo Vivi 
> CC: Puthikorn Voravootivat 
>
> Signed-off-by: Maulik V Vaghela 
> Signed-off-by: Vathsala Nagaraju 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 40 
> ---
>  drivers/gpu/drm/i915/intel_psr.c  | 26 -
>  2 files changed, 50 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 702d3fa..8913dc8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -646,6 +646,15 @@ static int intel_bios_ssc_frequency(struct 
> drm_i915_private *dev_priv,
>   }
>  }
>  
> +static bool
> +is_psr_options(struct drm_i915_private *dev_priv, const struct bdb_header 
> *bdb)
> +{
> + if (bdb->version >= 209 && IS_KABYLAKE(dev_priv))
> + return true;
> + else
> + return false;
> +}
> +
>  static void
>  parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
>  {
> @@ -658,7 +667,6 @@ static int intel_bios_ssc_frequency(struct 
> drm_i915_private *dev_priv,
>   DRM_DEBUG_KMS("No PSR BDB found.\n");
>   return;
>   }
> -
>   psr_table = >psr_table[panel_type];
>  
>   dev_priv->vbt.psr.full_link = psr_table->full_link;
> @@ -687,8 +695,34 @@ static int intel_bios_ssc_frequency(struct 
> drm_i915_private *dev_priv,
>   break;
>   }
>  
> - dev_priv->vbt.psr.tp1_wakeup_time = psr_table->tp1_wakeup_time;
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table->tp2_tp3_wakeup_time;
> + /*  new psr optionsold decimal value interpretation
> +  *  0 [500 us] > 1 [500 us ]
> +  *  1 [100 us] > 0 [100 us ]
> +  *  2 [2.5 ms] > 5 [2.5 ms ]
> +  *  3 [0   us] = 0 [0   us ]

The old decimal value stuff was wake up time in multiples of 100 us.

> +  */
> + if (!is_psr_options(dev_priv, bdb)) {

You only use is_psr_options here once, please just open code the
condition. Also reverse order to not need !something in the condition.

> + if (psr_table->tp1_wakeup_time > 5)
> + dev_priv->vbt.psr.tp1_wakeup_time = 2;
> + else if (psr_table->tp1_wakeup_time > 1)
> + dev_priv->vbt.psr.tp1_wakeup_time = 0;
> + else if (psr_table->tp1_wakeup_time > 0)
> + dev_priv->vbt.psr.tp1_wakeup_time = 1;
> + else
> + dev_priv->vbt.psr.tp1_wakeup_time = 3;
> +
> + if (psr_table->tp2_tp3_wakeup_time > 5)
> + dev_priv->vbt.psr.tp2_tp3_wakeup_time = 2;
> + else if (psr_table->tp2_tp3_wakeup_time > 1)
> + dev_priv->vbt.psr.tp2_tp3_wakeup_time = 0;
> + else if (psr_table->tp1_wakeup_time > 0)
> + dev_priv->vbt.psr.tp2_tp3_wakeup_time = 1;
> + else
> + dev_priv->vbt.psr.tp2_tp3_wakeup_time = 3;
> + } else {
> + dev_priv->vbt.psr.tp1_wakeup_time = psr_table->tp1_wakeup_time;
> + dev_priv->vbt.psr.tp2_tp3_wakeup_time = 
> psr_table->tp2_tp3_wakeup_time;
> + }
>  }

Please rename dev_priv->vbt.psr tp1_wakeup_time and tp2_tp3_wakeup_time
to have _us suffix, and actually assign the wakeup time in us
there. Hide all the hideous, hideous VBT stuff behind that, and doesn't
use magic numbers all over the place.

The old format becomes wakeup_time_us = vbt_value * 100. The code should
handle mismatches between the value and what the hardware can do (see
below).

The new format should just be a switch-case mapping values to us,
whining about values other than 0..3 and defaulting to max in that case.

>  
>  static void parse_dsi_backlight_ports(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 69a5b27..95658ad 100644

[Intel-gfx] ✓ Fi.CI.BAT: success for Enabling content-type setting for HDMI displays. (rev4)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev4)
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4069 -> Patchwork_8753 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/4/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8753 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-y3:  DMESG-WARN (fdo#104951) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (35 -> 31) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4069 -> Patchwork_8753

  CI_DRM_4069: 8136363fe770a1a51688172d5ba46a5017f76677 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8753: 674d7cb399e989924e8fcc0dfafb1af895f7171e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

674d7cb399e9 i915: content-type property for HDMI connector
b77a9ab3cc9a drm: content-type property for HDMI connector

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enabling content-type setting for HDMI displays. (rev4)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev4)
URL   : https://patchwork.freedesktop.org/series/41876/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b77a9ab3cc9a drm: content-type property for HDMI connector
-:113: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#113: FILE: drivers/gpu/drm/drm_connector.c:1017:
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.content_type_property,

-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/drm_connector.c:1304:
+   drm_property_create_enum(dev, 0, "content type",
+   drm_content_type_enum_list,

-:146: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"!dev->mode_config.content_type_property"
#146: FILE: drivers/gpu/drm/drm_connector.c:1307:
+   if (dev->mode_config.content_type_property == NULL)

total: 0 errors, 0 warnings, 3 checks, 172 lines checked
674d7cb399e9 i915: content-type property for HDMI connector

___
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 [v2,1/3] drm/i915: Move request->ctx aside

2018-04-19 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Move request->ctx aside
URL   : https://patchwork.freedesktop.org/series/41964/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Move request->ctx aside
Okay!

Commit: drm/i915: Move fiddling with engine->last_retired_context
Okay!

Commit: drm/i915: Store a pointer to intel_context in i915_request
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2209:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3657:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Enabling content-type setting for HDMI displays. (rev3)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev3)
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4068_full -> Patchwork_8749_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8749_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8749_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/3/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8749_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +2

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP

igt@kms_mmap_write_crc:
  shard-glk:  SKIP -> PASS +73

igt@kms_universal_plane@universal-plane-pipe-b-sanity:
  shard-glk:  PASS -> SKIP +70


== Known issues ==

  Here are the changes found in Patchwork_8749_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_atomic_transition@1x-modeset-transitions-fencing:
  shard-apl:  PASS -> FAIL (fdo#103207)

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
  shard-hsw:  PASS -> FAIL (fdo#104873)


 Possible fixes 

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#106023, fdo#103665) -> PASS

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106087) -> PASS

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> SKIP


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8749

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8749: 67311c808659d0d83a5ca6b844f72fdd9d4b47d4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsi: fix dphy param field widths and range checks for chv+

2018-04-19 Thread Jani Nikula

On Thu, 19 Apr 2018, Ville Syrjälä  wrote:
> On Thu, Apr 19, 2018 at 11:59:40AM +0300, Jani Nikula wrote:
>> Current CHV and BXT bspec says the dphy param register has four 8-bit
>> fields instead of the smaller VLV field widths. CHV bspec mentions the
>> register has changed since K0, but there's no indication of what exactly
>> changed. Lacking further details, change the field widths for all CHV
>> and later.
>
> K0 didn't happen, and looks like the linked HSD specifically says that
> this change was meant for K0. So I suspect this patch is wrong.

Oh well. The referenced bug indicated overflow in the logs, so I figured
this might be it.

I pushed patch 1 for now.

> The BXT HSD says planned for B0, but not sure if that actually happened
> either.
>
> On my VLV the reserved bits can't be set:
> intel_reg write 0x18:0xb080 0x
> intel_reg write 0x18:0xb880 0x
> intel_reg read 0x18:0xb080 0x18:0xb880
>  (0x0018:0xb080): 0x3f1fff3f
>  (0x0018:0xb880): 0x3f1fff3f
>
> So presumably the same rmw trick could be used to check what
> how many bits we have on CHV/BXT.

Asked on the bug, let's see if we get a response.

BR,
Jani.

>
> Also looks like the CHV spec was forked from VLV before someone fixed
> the prepare count to be 6 bits, which seems to be what my VLV actually
> has as well. Not the first time the VLV docs are more up to date than
> the CHV ones unfortunately.
>
>> 
>> Define the max values based on the platform. Also define them based on
>> the register definitions instead of duplicating information.
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106130
>> Cc: sta...@vger.kernel.org
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h  | 11 +++
>>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 31 +++
>>  2 files changed, 26 insertions(+), 16 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index fb106026a1f4..f4435a13b757 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -9547,14 +9547,17 @@ enum skl_power_gate {
>>  #define _MIPIA_DPHY_PARAM   (dev_priv->mipi_mmio_base + 0xb080)
>>  #define _MIPIC_DPHY_PARAM   (dev_priv->mipi_mmio_base + 0xb880)
>>  #define MIPI_DPHY_PARAM(port)   _MMIO_MIPI(port, 
>> _MIPIA_DPHY_PARAM, _MIPIC_DPHY_PARAM)
>> -#define  EXIT_ZERO_COUNT_SHIFT  24
>>  #define  EXIT_ZERO_COUNT_MASK   (0x3f << 24)
>> -#define  TRAIL_COUNT_SHIFT  16
>> +#define  EXIT_ZERO_COUNT_MASK_CHV   (0xff << 24)
>> +#define  EXIT_ZERO_COUNT_SHIFT  24
>>  #define  TRAIL_COUNT_MASK   (0x1f << 16)
>> -#define  CLK_ZERO_COUNT_SHIFT   8
>> +#define  TRAIL_COUNT_MASK_CHV   (0xff << 16)
>> +#define  TRAIL_COUNT_SHIFT  16
>>  #define  CLK_ZERO_COUNT_MASK(0xff << 8)
>> -#define  PREPARE_COUNT_SHIFT0
>> +#define  CLK_ZERO_COUNT_SHIFT   8
>>  #define  PREPARE_COUNT_MASK (0x3f << 0)
>> +#define  PREPARE_COUNT_MASK_CHV (0xff << 0)
>> +#define  PREPARE_COUNT_SHIFT0
>>  
>>  /* bits 31:0 */
>>  #define _MIPIA_DBI_BW_CTRL  (dev_priv->mipi_mmio_base + 0xb084)
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
>> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
>> index 4d6ffa7b3e7b..8d3dea693840 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
>> @@ -41,10 +41,17 @@
>>  #define MIPI_VIRTUAL_CHANNEL_SHIFT  1
>>  #define MIPI_PORT_SHIFT 3
>>  
>> -#define PREPARE_CNT_MAX 0x3F
>> -#define EXIT_ZERO_CNT_MAX   0x3F
>> -#define CLK_ZERO_CNT_MAX0xFF
>> -#define TRAIL_CNT_MAX   0x1F
>> +#define EXIT_ZERO_CNT_MAX(dev_priv) \
>> +((IS_VALLEYVIEW(dev_priv) ? EXIT_ZERO_COUNT_MASK : 
>> EXIT_ZERO_COUNT_MASK_CHV) >> EXIT_ZERO_COUNT_SHIFT)
>> +
>> +#define TRAIL_CNT_MAX(dev_priv) \
>> +((IS_VALLEYVIEW(dev_priv) ? TRAIL_COUNT_MASK : TRAIL_COUNT_MASK_CHV) >> 
>> TRAIL_COUNT_SHIFT)
>> +
>> +#define CLK_ZERO_CNT_MAX(dev_priv) \
>> +(CLK_ZERO_COUNT_MASK >> CLK_ZERO_COUNT_SHIFT)
>> +
>> +#define PREPARE_CNT_MAX(dev_priv)   \
>> +((IS_VALLEYVIEW(dev_priv) ? PREPARE_COUNT_MASK : 
>> PREPARE_COUNT_MASK_CHV) >> PREPARE_COUNT_SHIFT)
>>  
>>  #define NS_KHZ_RATIO 100
>>  
>> @@ -647,9 +654,9 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
>> panel_id)
>>  /* prepare count */
>>  prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den,

Re: [Intel-gfx] [PATCH v2] drm/i915/fbdev: Enable late fbdev initial configuration

2018-04-19 Thread Jani Nikula

On Wed, 18 Apr 2018, José Roberto de Souza  wrote:
> If the initial fbdev configuration(intel_fbdev_initial_config()) runs and
> there still no sink connected it will cause
> drm_fb_helper_initial_config() to return 0 as no error happened(but
> internally the return is -EAGAIN).
> Because no framebuffer was allocated, when a sink is connected
> intel_fbdev_output_poll_changed() will not execute
> drm_fb_helper_hotplug_event() that would trigger another try to do the
> initial fbdev configuration.
>
> So here allowing drm_fb_helper_hotplug_event() to be executed when there
> is not frambebuffer allocated and fbdev was not setup yet.
>
> This issue also happens when a MST DP sink is connected since boot, as
> the MST topology is discovered in parallel if intel_fbdev_initial_config()
> is executed before the first sink MST is discovered it will cause this
> same issue.
>
> This is a follow up patch of
> https://patchwork.freedesktop.org/patch/196089/

What does this mean? Is that patch a required dependency? What?

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425

People responded to v1, please ask them to test v2.

> Cc: Rodrigo Vivi 
> Signed-off-by: Chris Wilson 
> Signed-off-by: José Roberto de Souza 
> ---
>
> Changes from v1:
> - not creating a dump framebuffer anymore, instead just allowing
> drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.

Please look at git log in drm, and observe how we include the changelog
in the commit message itself.

BR,
Jani.

>
>  drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 7d41d139341b..e9e02b58b7be 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct drm_device 
> *dev)
>   return;
>  
>   intel_fbdev_sync(ifbdev);
> - if (ifbdev->vma)
> + if (ifbdev->vma || ifbdev->helper.deferred_setup)
>   drm_fb_helper_hotplug_event(>helper);
>  }

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

Re: [Intel-gfx] [PATCH v5 1/2] drm: content-type property for HDMI connector

2018-04-19 Thread Hans Verkuil

On 04/19/18 14:38, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
> 
> v2:
>  * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
> 
> v3:
>  * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
> 
> v4:
>  * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
> 
> v5:
>  * Moved patch revision's description to commit messages.
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c | 17 ++
>  drivers/gpu/drm/drm_connector.c  | 51 
>  drivers/gpu/drm/drm_edid.c   |  2 ++
>  include/drm/drm_connector.h  | 18 ++
>  include/drm/drm_mode_config.h|  5 +++
>  include/uapi/drm/drm_mode.h  |  7 
>  7 files changed, 101 insertions(+)
> 
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 6b28b014cb7d..a91c9211b8d6 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property 
> to suggest an X offset for a connector
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest 
> an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
> ""Cinema"", ""Game"" }",Connector,TBD
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..479499f5848e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->link_status = val;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio = val;
> + } else if (property == config->content_type_property) {
> + /*
> +  * Lowest two bits of content_type property control
> +  * content_type, bit 2 controls itc bit.
> +  * It was decided to have a single property called
> +  * content_type, instead of content_type and itc.
> +  */
> + state->content_type = val & 3;
> + state->it_content = val >> 2;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
>   } else if (property == connector->content_protection_property) {
> @@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->link_status;
>   } else if (property == config->aspect_ratio_property) {
>   *val = state->picture_aspect_ratio;
> + } else if (property == config->content_type_property) {
> + /*
> +  * Lowest two bits of content_type property control
> +  * content_type, bit 2 controls itc bit.
> +  * It was decided to have a single property called
> +  * content_type, instead of content_type and itc.
> +  */
> + *val = state->content_type | (state->it_content << 2);
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
>   } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b3cde897cd80..757a0712f7c1 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c

Re: [Intel-gfx] [PATCH v5 2/2] i915: content-type property for HDMI connector

2018-04-19 Thread Hans Verkuil

On 04/19/18 14:38, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added encoding of drm content_type property from drm_connector_state
> within AVI infoframe in order to properly handle external HDMI TV
> content-type setting.
> 
> This requires also manipulationg ITC bit, as stated in
> HDMI spec.
> 
> v2:
>  * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
> 
> v3:
>  * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
> 
> v4:
>  * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
> 
> v5:
>  * Moved patch revision's description to commit messages.
> 
> Signed-off-by: Stanislav Lisovskiy 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/i915/intel_atomic.c | 2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c   | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 40285d1b91b7..96a42eb457c5 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct 
> drm_connector *conn,
>   if (new_conn_state->force_audio != old_conn_state->force_audio ||
>   new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
>   new_conn_state->base.picture_aspect_ratio != 
> old_conn_state->base.picture_aspect_ratio ||
> + new_conn_state->base.content_type != 
> old_conn_state->base.content_type ||
> + new_conn_state->base.it_content != old_conn_state->base.it_content 
> ||
>   new_conn_state->base.scaling_mode != 
> old_conn_state->base.scaling_mode)
>   crtc_state->mode_changed = true;
>  
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ee929f31f7db..078200908b7a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>  
> intel_hdmi->rgb_quant_range_selectable,
>  is_hdmi2_sink);
>  
> + frame.avi.content_type = connector->state->content_type;
> + frame.avi.itc = connector->state->it_content;
> +
>   /* TODO: handle pixel repetition for YCBCR420 outputs */
>   intel_write_infoframe(encoder, crtc_state, );
>  }
> @@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi 
> *intel_hdmi, struct drm_connector *c
>   intel_attach_force_audio_property(connector);
>   intel_attach_broadcast_rgb_property(connector);
>   intel_attach_aspect_ratio_property(connector);
> + drm_connector_attach_content_type_property(connector);
>   connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  }
>  
> 

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

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Store a pointer to intel_context in i915_request

2018-04-19 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-19 13:29:42)
> 
> On 19/04/2018 12:58, Chris Wilson wrote:
> > To ease the frequent and ugly pointer dance of
> > >gem_context->engine[request->engine->id] during request
> > submission, store that pointer as request->hw_context. One major
> > advantage that we will exploit later is that this decouples the logical
> > context state from the engine itself.
> > 
> > v2: Set mock_context->ops so we don't crash and burn in selftests.
> >  Cleanups from Tvrtko.
> 
> Which ones? I have to re-read it all? :I

All but fixing engine->class and the semantics differences between
hw_context and gem_context. Other than that I'm seeing if the gvt guys
even read the ml ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5 2/2] i915: content-type property for HDMI connector

2018-04-19 Thread StanLis

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.

This requires also manipulationg ITC bit, as stated in
HDMI spec.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c | 2 ++
 drivers/gpu/drm/i915/intel_hdmi.c   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..96a42eb457c5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
+   new_conn_state->base.it_content != old_conn_state->base.it_content 
||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..078200908b7a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   frame.avi.content_type = connector->state->content_type;
+   frame.avi.itc = connector->state->it_content;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+   drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 }
 
-- 
2.17.0

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

[Intel-gfx] [PATCH v5 0/2] Enabling content-type setting for HDMI displays.

2018-04-19 Thread StanLis

From: Stanislav Lisovskiy 

Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c|  4 +++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 9 files changed, 107 insertions(+)

-- 
2.17.0

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

[Intel-gfx] [PATCH v5 1/2] drm: content-type property for HDMI connector

2018-04-19 Thread StanLis

From: Stanislav Lisovskiy 

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 7 files changed, 101 insertions(+)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..a91c9211b8d6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   state->content_type = val & 3;
+   state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Move request->ctx aside

2018-04-19 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Move request->ctx aside
URL   : https://patchwork.freedesktop.org/series/41964/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4068 -> Patchwork_8752 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41964/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8752 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_chamelium@hdmi-hpd-fast:
  fi-kbl-7500u:   SKIP -> FAIL (fdo#103841, fdo#102672)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084


== Participating hosts (34 -> 31) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8752

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8752: 85da0887e43c97fe443c440052e124aecbcb704a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

85da0887e43c drm/i915: Store a pointer to intel_context in i915_request
a7b57f6eb191 drm/i915: Move fiddling with engine->last_retired_context
d2cce053130b drm/i915: Move request->ctx aside

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Store a pointer to intel_context in i915_request

2018-04-19 Thread Tvrtko Ursulin



On 19/04/2018 12:58, Chris Wilson wrote:

To ease the frequent and ugly pointer dance of
>gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.

v2: Set mock_context->ops so we don't crash and burn in selftests.
 Cleanups from Tvrtko.


Which ones? I have to re-read it all? :I



Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gvt/mmio_context.c   |   6 +-
  drivers/gpu/drm/i915/gvt/mmio_context.h   |   2 +-
  drivers/gpu/drm/i915/gvt/scheduler.c  | 141 ++--
  drivers/gpu/drm/i915/gvt/scheduler.h  |   1 -
  drivers/gpu/drm/i915/i915_debugfs.c   |  20 ++-
  drivers/gpu/drm/i915/i915_drv.h   |   1 +
  drivers/gpu/drm/i915/i915_gem.c   |  14 +-
  drivers/gpu/drm/i915/i915_gem_context.c   |  23 +--
  drivers/gpu/drm/i915/i915_gem_context.h   |  29 +++-
  drivers/gpu/drm/i915/i915_gpu_error.c |   2 +-
  drivers/gpu/drm/i915/i915_perf.c  |  28 ++--
  drivers/gpu/drm/i915/i915_request.c   |  23 ++-
  drivers/gpu/drm/i915/i915_request.h   |   3 +-
  drivers/gpu/drm/i915/intel_engine_cs.c|  55 ---
  drivers/gpu/drm/i915/intel_guc_ads.c  |   2 +-
  drivers/gpu/drm/i915/intel_guc_submission.c   |  15 +-
  drivers/gpu/drm/i915/intel_lrc.c  | 151 +++---
  drivers/gpu/drm/i915/intel_lrc.h  |   7 -
  drivers/gpu/drm/i915/intel_ringbuffer.c   | 104 +++-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |   9 +-
  drivers/gpu/drm/i915/selftests/mock_context.c |   7 +
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  42 +++--
  22 files changed, 377 insertions(+), 308 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index a5bac83d53a9..708170e61625 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -446,9 +446,9 @@ static void switch_mocs(struct intel_vgpu *pre, struct 
intel_vgpu *next,
  
  #define CTX_CONTEXT_CONTROL_VAL	0x03
  
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id)

+bool is_inhibit_context(struct intel_context *ce)
  {
-   u32 *reg_state = ctx->engine[ring_id].lrc_reg_state;
+   const u32 *reg_state = ce->lrc_reg_state;
u32 inhibit_mask =
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
  
@@ -501,7 +501,7 @@ static void switch_mmio(struct intel_vgpu *pre,

 * itself.
 */
if (mmio->in_context &&
-   !is_inhibit_context(s->shadow_ctx, ring_id))
+   
!is_inhibit_context(>shadow_ctx->__engine[ring_id]))
continue;
  
  			if (mmio->mask)

diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.h 
b/drivers/gpu/drm/i915/gvt/mmio_context.h
index 0439eb8057a8..5c3b9ff9f96a 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.h
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.h
@@ -49,7 +49,7 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
  
  void intel_gvt_init_engine_mmio_context(struct intel_gvt *gvt);
  
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id);

+bool is_inhibit_context(struct intel_context *ce);
  
  int intel_vgpu_restore_inhibit_context(struct intel_vgpu *vgpu,

   struct i915_request *req);
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f64cccb2e793..c2e440200b0c 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -54,11 +54,8 @@ static void set_context_pdp_root_pointer(
  
  static void update_shadow_pdps(struct intel_vgpu_workload *workload)

  {
-   struct intel_vgpu *vgpu = workload->vgpu;
-   int ring_id = workload->ring_id;
-   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   workload->req->hw_context->state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
  
@@ -128,9 +125,8 @@ static int populate_shadow_context(struct intel_vgpu_workload *workload)

struct intel_vgpu *vgpu = workload->vgpu;
struct intel_gvt *gvt = vgpu->gvt;
int ring_id = workload->ring_id;
-   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   workload->req->hw_context->state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
void *dst;

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)
URL   : https://patchwork.freedesktop.org/series/40747/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4068 -> Patchwork_8751 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/40747/revisions/2/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8751 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)

igt@prime_vgem@basic-gtt:
  fi-glk-1:   NOTRUN -> INCOMPLETE (k.org#198133, fdo#103359)


  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (34 -> 32) ==

  Additional (1): fi-glk-1 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8751

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8751: 8e4bae99c5587cb819b3ebb7a22dd8d75883be1b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

8e4bae99c558 drm/i915/gen11: Preempt-to-idle support in execlists.

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Store a pointer to intel_context in i915_request

2018-04-19 Thread Tvrtko Ursulin



On 19/04/2018 12:10, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-04-19 11:40:06)


On 19/04/2018 08:17, Chris Wilson wrote:

To ease the frequent and ugly pointer dance of
>gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.


I can see merit in making all the places which work on engines or
requests more logically and elegantly grab the engine specific context.

Authors of current unmerged work will probably be not so thrilled though.



@@ -353,60 +346,56 @@ int intel_gvt_scan_and_shadow_workload(struct 
intel_vgpu_workload *workload)
   struct intel_vgpu_submission *s = >submission;
   struct i915_gem_context *shadow_ctx = s->shadow_ctx;
   struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
- int ring_id = workload->ring_id;
- struct intel_engine_cs *engine = dev_priv->engine[ring_id];
- struct intel_ring *ring;
+ struct intel_engine_cs *engine = dev_priv->engine[workload->ring_id];
+ struct intel_context *ce;
   int ret;
   
   lockdep_assert_held(_priv->drm.struct_mutex);
   
- if (workload->shadowed)

+ if (workload->req)
   return 0;


GVT team will need to look at this hunk/function.

...

At which point I skip over all GVT and continue further down. :)


That code doesn't merit your attention (or ours really until it is
improved, it really is staging/ quality).


Still, best to ask GVT team to r-b their parts.

[snip]


diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0777226e65a6..e6725690b5b6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -164,7 +164,8 @@
   #define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
   
   static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,

- struct intel_engine_cs *engine);
+ struct intel_engine_cs *engine,
+ struct intel_context *ce);


Feels a bit redundant to pass in everything but OK.


You do remember which patch this was split out of ;)


   {
   return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
- i915_gem_context_force_single_submission(ctx));
+ i915_gem_context_force_single_submission(ctx->gem_context));
   }


But the whole function change is again not needed I think.

   
-static bool can_merge_ctx(const struct i915_gem_context *prev,

-   const struct i915_gem_context *next)
+static bool can_merge_ctx(const struct intel_context *prev,
+   const struct intel_context *next)


This one neither.


Consider what it means. The rule is that we are not allowed to submit
the same lrc descriptor to subsequent ports; that corresponds to
the hw context, not gem_context. The payoff, aside from the better
semantics now, is in subsequent patches.


Yes all fine, just saying it did not have to be in _this_ series but 
could have came later.



+static struct intel_context *
+execlists_context_pin(struct intel_engine_cs *engine,
+   struct i915_gem_context *ctx)
   {
- struct intel_context *ce = >engine[engine->id];
+ struct intel_context *ce = to_intel_context(ctx, engine);
   
   lockdep_assert_held(>i915->drm.struct_mutex);

- GEM_BUG_ON(ce->pin_count == 0);
-
- if (--ce->pin_count)
- return;
   
- intel_ring_unpin(ce->ring);

+ if (likely(ce->pin_count++))
+ return ce;
+ GEM_BUG_ON(!ce->pin_count); /* no overflow please! */
   
- ce->state->obj->pin_global--;

- i915_gem_object_unpin_map(ce->state->obj);
- i915_vma_unpin(ce->state);
+ ce->ops = _context_ops;


If ops are set on pin it would be good to unset them on destroy.


No point on destroy, since it's being destroyed.


Hm, or even set them not on pin but on creation.


engine->context_pin() is our intel_context factory, pin is the creation
function.

Definitely a bit asymmetrical, the key bit was having ce->unpin() so that
we didn't try to release the intel_context via a stale engine reference.

What I have been considering is passing intel_context to
i915_request_alloc() instead and trying to avoid that asymmetry by
managing the creation in the caller and separating it from pin().


Not a huge deal but it is a
bit unbalanced, and also if ce->ops is also a guard to distinguish
possible from impossible engines then it is a bit more strange.


Not impossible engines in this regard, unused contexts.


Both then, since impossible engines will have unused contexts. :)


@@ -1323,10 +1345,6 @@ static int intel_init_ring_buffer(struct intel_engine_cs 
*engine)
   
   intel_engine_setup_common(engine);
   
- err = intel_engine_init_common(engine);

- if (err)
- goto err;
-

[Intel-gfx] [PATCH v2 2/3] drm/i915: Move fiddling with engine->last_retired_context

2018-04-19 Thread Chris Wilson

Move the knowledge about resetting the current context tracking on the
engine from inside i915_gem_context.c into intel_engine_cs.c

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c  | 23 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74435affe23f..2fe779cab298 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -514,16 +514,8 @@ void i915_gem_contexts_lost(struct drm_i915_private 
*dev_priv)
 
lockdep_assert_held(_priv->drm.struct_mutex);
 
-   for_each_engine(engine, dev_priv, id) {
-   engine->legacy_active_context = NULL;
-   engine->legacy_active_ppgtt = NULL;
-
-   if (!engine->last_retired_context)
-   continue;
-
-   engine->context_unpin(engine, engine->last_retired_context);
-   engine->last_retired_context = NULL;
-   }
+   for_each_engine(engine, dev_priv, id)
+   intel_engine_lost_context(engine);
 }
 
 void i915_gem_contexts_fini(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0248d64c2a72..b26867eed4ca 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1084,6 +1084,29 @@ void intel_engines_unpark(struct drm_i915_private *i915)
}
 }
 
+/**
+ * intel_engine_lost_context: called when the GPU is reset into unknown state
+ * @engine: the engine
+ *
+ * We have either reset the GPU or otherwise about to lose state tracking of
+ * the current GPU logical state (e.g. suspend). On next use, it is therefore
+ * imperative that we make no presumptions about the current state and load
+ * from scratch.
+ */
+void intel_engine_lost_context(struct intel_engine_cs *engine)
+{
+   struct i915_gem_context *ctx;
+
+   lockdep_assert_held(>i915->drm.struct_mutex);
+
+   engine->legacy_active_context = NULL;
+   engine->legacy_active_ppgtt = NULL;
+
+   ctx = fetch_and_zero(>last_retired_context);
+   if (ctx)
+   engine->context_unpin(engine, ctx);
+}
+
 bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
 {
switch (INTEL_GEN(engine->i915)) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c5e27905b0e1..584b7f246374 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -1040,6 +1040,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine);
 bool intel_engines_are_idle(struct drm_i915_private *dev_priv);
 
 bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine);
+void intel_engine_lost_context(struct intel_engine_cs *engine);
 
 void intel_engines_park(struct drm_i915_private *i915);
 void intel_engines_unpark(struct drm_i915_private *i915);
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 1/3] drm/i915: Move request->ctx aside

2018-04-19 Thread Chris Wilson

In the next patch, we want to store the intel_context pointer inside
i915_request, as it is frequently access via a convoluted dance when
submitting the request to hw. Having two context pointers inside
i915_request leads to confusion so first rename the existing
i915_gem_context pointer to i915_request.gem_context.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gvt/scheduler.c  |  4 +--
 drivers/gpu/drm/i915/i915_debugfs.c   |  4 +--
 drivers/gpu/drm/i915/i915_gem.c   | 10 +++
 drivers/gpu/drm/i915/i915_gpu_error.c | 18 +++-
 drivers/gpu/drm/i915/i915_request.c   |  8 ++---
 drivers/gpu/drm/i915/i915_request.h   |  2 +-
 drivers/gpu/drm/i915/i915_trace.h |  6 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_submission.c   |  7 +++--
 drivers/gpu/drm/i915/intel_lrc.c  | 29 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 11 +++
 .../gpu/drm/i915/selftests/intel_hangcheck.c  |  5 +++-
 drivers/gpu/drm/i915/selftests/intel_lrc.c|  2 +-
 13 files changed, 58 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f3d21849b0cb..f64cccb2e793 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -205,7 +205,7 @@ static int populate_shadow_context(struct 
intel_vgpu_workload *workload)
 
 static inline bool is_gvt_request(struct i915_request *req)
 {
-   return i915_gem_context_force_single_submission(req->ctx);
+   return i915_gem_context_force_single_submission(req->gem_context);
 }
 
 static void save_ring_hw_state(struct intel_vgpu *vgpu, int ring_id)
@@ -305,7 +305,7 @@ static int copy_workload_to_ring_buffer(struct 
intel_vgpu_workload *workload)
struct i915_request *req = workload->req;
 
if (IS_KABYLAKE(req->i915) &&
-   is_inhibit_context(req->ctx, req->engine->id))
+   is_inhibit_context(req->gem_context, req->engine->id))
intel_vgpu_restore_inhibit_context(vgpu, req);
 
/* allocate shadow ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e0274f41bc76..792f69e44ba5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -539,8 +539,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
   struct i915_request,
   client_link);
rcu_read_lock();
-   task = pid_task(request && request->ctx->pid ?
-   request->ctx->pid : file->pid,
+   task = pid_task(request && request->gem_context->pid ?
+   request->gem_context->pid : file->pid,
PIDTYPE_PID);
print_file_stats(m, task ? task->comm : "", stats);
rcu_read_unlock();
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..4dba735505d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3108,7 +3108,7 @@ static void skip_request(struct i915_request *request)
 static void engine_skip_context(struct i915_request *request)
 {
struct intel_engine_cs *engine = request->engine;
-   struct i915_gem_context *hung_ctx = request->ctx;
+   struct i915_gem_context *hung_ctx = request->gem_context;
struct intel_timeline *timeline;
unsigned long flags;
 
@@ -3118,7 +3118,7 @@ static void engine_skip_context(struct i915_request 
*request)
spin_lock(>lock);
 
list_for_each_entry_continue(request, >timeline->requests, link)
-   if (request->ctx == hung_ctx)
+   if (request->gem_context == hung_ctx)
skip_request(request);
 
list_for_each_entry(request, >requests, link)
@@ -3164,11 +3164,11 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
}
 
if (stalled) {
-   i915_gem_context_mark_guilty(request->ctx);
+   i915_gem_context_mark_guilty(request->gem_context);
skip_request(request);
 
/* If this context is now banned, skip all pending requests. */
-   if (i915_gem_context_is_banned(request->ctx))
+   if (i915_gem_context_is_banned(request->gem_context))
engine_skip_context(request);
} else {
/*
@@ -3178,7 +3178,7 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
 */
request = i915_gem_find_active_request(engine);
if

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)
URL   : https://patchwork.freedesktop.org/series/40747/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/gen11: Preempt-to-idle support in execlists.
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3658:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev2)
URL   : https://patchwork.freedesktop.org/series/40747/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8e4bae99c558 drm/i915/gen11: Preempt-to-idle support in execlists.
-:107: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"!execlists->ctrl_reg"
#107: FILE: drivers/gpu/drm/i915/intel_lrc.c:566:
+   GEM_BUG_ON(execlists->ctrl_reg == NULL);

-:160: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#160: FILE: drivers/gpu/drm/i915/intel_lrc.c:1060:
+   buf[2*head + 1] == 
execlists->preempt_complete_status)) {
 ^

total: 0 errors, 0 warnings, 2 checks, 124 lines checked

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

Re: [Intel-gfx] [PATCH v2] drm/i915/gen11: Preempt-to-idle support in execlists.

2018-04-19 Thread Chris Wilson

Quoting Tomasz Lis (2018-04-19 12:44:48)
> The patch adds support of preempt-to-idle requesting by setting a proper
> bit within Execlist Control Register, and receiving preemption result from
> Context Status Buffer.
> 
> Preemption in previous gens required a special batch buffer to be executed,
> so the Command Streamer never preempted to idle directly. In Icelake it is
> possible, as there is a hardware mechanism to inform the kernel about
> status of the preemption request.
> 
> This patch does not cover using the new preemption mechanism when GuC is
> active.
> 
> v2: Added needs_preempt_context() change so that it is not created when
> preempt-to-idle is supported. (Chris)
> Updated setting HWACK flag so that it is cleared after
> preempt-to-dle. (Chris, Daniele)
> Updated to use I915_ENGINE_HAS_PREEMPTION flag. (Chris)
> 
> Bspec: 18922
> Signed-off-by: Tomasz Lis 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/i915_gem_context.c  |  4 ++-
>  drivers/gpu/drm/i915/i915_pci.c  |  3 +-
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  drivers/gpu/drm/i915/intel_lrc.c | 47 
> 
>  drivers/gpu/drm/i915/intel_lrc.h |  1 +
>  6 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0286911..f445340 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2518,6 +2518,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> ((dev_priv)->info.has_logical_ring_elsq)
>  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> ((dev_priv)->info.has_logical_ring_preemption)
> +#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
> +   ((dev_priv)->info.has_hw_preempt_to_idle)
>  
>  #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 74435af..d65f469 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -454,7 +454,9 @@ destroy_kernel_context(struct i915_gem_context **ctxp)
>  
>  static bool needs_preempt_context(struct drm_i915_private *i915)
>  {
> -   return HAS_LOGICAL_RING_PREEMPTION(i915);
> +   return HAS_LOGICAL_RING_PREEMPTION(i915) &&
> +  !HAS_HW_PREEMPT_TO_IDLE(i915) &&
> +  !USES_GUC_SUBMISSION(i915);

Pardon? The guc uses the preempt_context for its preempt_client.

>  int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 4364922..66b6700 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -595,7 +595,8 @@ static const struct intel_device_info 
> intel_cannonlake_info = {
> GEN(11), \
> .ddb_size = 2048, \
> .has_csr = 0, \
> -   .has_logical_ring_elsq = 1
> +   .has_logical_ring_elsq = 1, \
> +   .has_hw_preempt_to_idle = 1
>  
>  static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 933e316..4eb97b5 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -98,6 +98,7 @@ enum intel_platform {
> func(has_logical_ring_contexts); \
> func(has_logical_ring_elsq); \
> func(has_logical_ring_preemption); \
> +   func(has_hw_preempt_to_idle); \
> func(has_overlay); \
> func(has_pooled_eu); \
> func(has_psr); \
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 029901a..4c94488 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -154,6 +154,7 @@
>  #define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
>  #define GEN8_CTX_STATUS_COMPLETE   (1 << 4)
>  #define GEN8_CTX_STATUS_LITE_RESTORE   (1 << 15)
> +#define GEN11_CTX_STATUS_PREEMPT_IDLE  (1 << 29)
>  
>  #define GEN8_CTX_STATUS_COMPLETED_MASK \
>  (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
> @@ -552,6 +553,25 @@ static void inject_preempt_context(struct 
> intel_engine_cs *engine)
> execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
>  }
>  
> +static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
> +{
> +   struct intel_engine_execlists *execlists = >execlists;
> +
> +   GEM_TRACE("%s\n", engine->name);
> +
> +   /*
> +* hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
> +* HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
> +*/
> +   GEM_BUG_ON(execlists->ctrl_reg == NULL);
> +
> +   /* trigger preemption to idle */
> +   writel(EL_CTRL_PREEMPT_TO_IDLE,

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Ville Syrjälä

On Thu, Apr 19, 2018 at 01:30:32PM +0200, Maarten Lankhorst wrote:
> Op 19-04-18 om 13:22 schreef Ville Syrjälä:
> > On Thu, Apr 19, 2018 at 02:36:42AM +, Srinivas, Vidya wrote:
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >>> Sent: Thursday, April 19, 2018 12:06 AM
> >>> To: Maarten Lankhorst 
> >>> Cc: Srinivas, Vidya ; intel-
> >>> g...@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> >>> skl_check_nv12_surface for NV12
> >>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
>  Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> >> From: Maarten Lankhorst 
> >> >
> >> We skip src trunction/adjustments for
> >> NV12 case and handle the sizes directly.
> >> Without this, pipe fifo underruns are seen on APL/KBL.
> >> v2: For NV12, making the src coordinates multiplier of 4
> >> v3: Moving all the src coords handling code for NV12 to
> >> skl_check_nv12_surface
> >> Signed-off-by: Maarten Lankhorst
> >> >
> >> Signed-off-by: Vidya Srinivas 
> >> >
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 39
> >> 
> >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
> >>  2 files changed, 50 insertions(+), 4 deletions(-)
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 925402e..b8dbaca 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
> >>> struct intel_crtc_state *crtc_state,
> >>  return 0;
> >>  }
> >> +static int
> >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> >> +   struct intel_plane_state 
> >> *plane_state) {
> >> +int crtc_x2 = plane_state->base.crtc_x + 
> >> plane_state->base.crtc_w;
> >> +int crtc_y2 = plane_state->base.crtc_y +
> >> +plane_state->base.crtc_h;
> >> +
> >> +if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> >> +((plane_state->base.src_y >> 16) % 4) != 0 ||
> >> +((plane_state->base.src_w >> 16) % 4) != 0 ||
> >> +((plane_state->base.src_h >> 16) % 4) != 0) {
> >> +DRM_DEBUG_KMS("src coords must be 
> >> multiple of 4 for
> >>> NV12\n");
> >> +return -EINVAL;
> >> +}
> > I don't really see why we should check these. The clipped
> > coordinates are what matters.
>  To propagate our limits to the userspace. I think we should do it for
>  all formats, but NV12 is the first YUV format we have tests for. If we
>  could we should do something similar for the other YUV formats, but they
> >>> have different requirements.
>  In case of NV12 we don't have existing userspace, there will be
>  nothing that breaks if we enforce limits from the start.
> >>> But what about sub-pixel coordinates? You're totally ignoring them here.
> >>> We need to come up with some proper rules for this stuff.
> >> +
> >> +/* Clipping would cause a 1-3 pixel gap at the edge 
> >> of the screen? */
> >> +if ((crtc_x2 > crtc_state->pipe_src_w && 
> >> crtc_state->pipe_src_w %
> >>> 4) ||
> >> +(crtc_y2 > crtc_state->pipe_src_h && 
> >> crtc_state->pipe_src_h % 4))
> >>> {
> >> +DRM_DEBUG_KMS("It's not possible to 
> >> clip %u,%u to
> >>> %u,%u\n",
> >> +  crtc_x2, 
> >> crtc_y2,
> >> +  
> >> crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> >> +return -EINVAL;
> >> +}
> > Why should we care? The current code already plays it fast and loose
> > and allows the dst rectangle to shrink to accomodate the hw limits.
> > If we want to change that we should change it universally.
>  Unfortunately for the other formats we already have an existing
>  userspace
>  (X.org) that doesn't perform any validation. We can't change it for
>  that, but we can prevent future mistakes.
> >>> We should do it uniformly. Not per-format. That will make the code
> >>> unmaintainable real quick.
> >>

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move request->ctx aside

2018-04-19 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-19 11:43:25)
> 
> On 19/04/2018 08:17, Chris Wilson wrote:
> > In the next patch, we want to store the intel_context pointer inside
> > i915_request, as it is frequently access via a convoluted dance when
> > submitting the request to hw. Having two context pointers inside
> > i915_request leads to confusion so first rename the existing
> > i915_gem_context pointer to i915_request.gem_context.
> 
> Did you do this manually or with spatch? If spatch then please paste the 
> rule in commit message.

Oh no, by hand. I still find it quicker to do search and replace in vim
than find then decypher spatch documentation ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/2] Enabling content-type setting for HDMI displays.

2018-04-19 Thread Ville Syrjälä

On Thu, Apr 19, 2018 at 10:58:44AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Rev 1:
> Added content type setting property to drm_connector(part 1)
> and enabled transmitting it with HDMI AVI infoframes
> for i915(part 2).
> 
> Rev 2:
> Moved helper function which attaches content type property
> to the drm core, as was suggested.
> Removed redundant connector state initialization.
> 
> Rev 3:
> Removed caps in drm_content_type_enum_list.
> After some discussion it turned out that HDMI Spec 1.4
> was wrongly assuming that IT Content(itc) bit doesn't affect
> Content type states, however itc bit needs to be manupulated
> as well. In order to not expose additional property for itc,
> for sake of simplicity it was decided to bind those together
> in same "content type" property.

Please put these changelogs into the commit messages themselves.
Plenty of examples of that practice in git log -- drivers/gpu/drm

> 
> Stanislav Lisovskiy (2):
>   drm: content-type property for HDMI connector
>   i915: content-type property for HDMI connector
> 
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c |  5 +++
>  drivers/gpu/drm/drm_connector.c  | 51 
>  drivers/gpu/drm/drm_edid.c   |  2 ++
>  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
>  drivers/gpu/drm/i915/intel_hdmi.c|  4 +++
>  include/drm/drm_connector.h  | 17 ++
>  include/drm/drm_mode_config.h|  5 +++
>  include/uapi/drm/drm_mode.h  |  7 
>  9 files changed, 93 insertions(+)
> 
> -- 
> 2.17.0

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

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Maarten Lankhorst

Op 19-04-18 om 13:32 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 10:12:56AM +0200, Maarten Lankhorst wrote:
>> Op 18-04-18 om 20:35 schreef Ville Syrjälä:
>>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
 Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>> From: Maarten Lankhorst 
>>
>> We skip src trunction/adjustments for
>> NV12 case and handle the sizes directly.
>> Without this, pipe fifo underruns are seen on APL/KBL.
>>
>> v2: For NV12, making the src coordinates multiplier of 4
>>
>> v3: Moving all the src coords handling code for NV12
>> to skl_check_nv12_surface
>>
>> Signed-off-by: Maarten Lankhorst 
>> Signed-off-by: Vidya Srinivas 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 39 
>> 
>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
>>  2 files changed, 50 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 925402e..b8dbaca 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct 
>> intel_crtc_state *crtc_state,
>>  return 0;
>>  }
>>  
>> +static int
>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>> +   struct intel_plane_state *plane_state)
>> +{
>> +int crtc_x2 = plane_state->base.crtc_x + 
>> plane_state->base.crtc_w;
>> +int crtc_y2 = plane_state->base.crtc_y + 
>> plane_state->base.crtc_h;
>> +
>> +if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>> +((plane_state->base.src_y >> 16) % 4) != 0 ||
>> +((plane_state->base.src_w >> 16) % 4) != 0 ||
>> +((plane_state->base.src_h >> 16) % 4) != 0) {
>> +DRM_DEBUG_KMS("src coords must be multiple of 4 for 
>> NV12\n");
>> +return -EINVAL;
>> +}
> I don't really see why we should check these. The clipped coordinates
> are what matters.
 To propagate our limits to the userspace. I think we should do it for all 
 formats,
 but NV12 is the first YUV format we have tests for. If we could we should 
 do
 something similar for the other YUV formats, but they have different 
 requirements.

 In case of NV12 we don't have existing userspace, there will be nothing 
 that
 breaks if we enforce limits from the start.
>>> But what about sub-pixel coordinates? You're totally ignoring them here.
>>> We need to come up with some proper rules for this stuff.
>> Would we break anything if we disallow sub-pixel coordinates for i915 
>> globally? It's not like we supported them before,
>> but I'm not sure that change would break anything.
> Not really I suppose. IIRC the hw did reintroduce partial sub-pixel
> coordinate support for NV12 specifically. I do wish they'd done it
> fully for all formats.
>
>> +
>> +/* Clipping would cause a 1-3 pixel gap at the edge of the 
>> screen? */
>> +if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w 
>> % 4) ||
>> +(crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h 
>> % 4)) {
>> +DRM_DEBUG_KMS("It's not possible to clip %u,%u to 
>> %u,%u\n",
>> +  crtc_x2, crtc_y2,
>> +  crtc_state->pipe_src_w, 
>> crtc_state->pipe_src_h);
>> +return -EINVAL;
>> +}
> Why should we care? The current code already plays it fast and loose
> and allows the dst rectangle to shrink to accomodate the hw limits.
> If we want to change that we should change it universally.
 Unfortunately for the other formats we already have an existing userspace
 (X.org) that doesn't perform any validation. We can't change it for that,
 but we can prevent future mistakes.
>>> We should do it uniformly. Not per-format. That will make the code
>>> unmaintainable real quick.
>> +
>> +plane_state->base.src.x1 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 
>> 18;
>> +plane_state->base.src.x2 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 
>> 18;
>> +plane_state->base.src.y1 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 
>> 18;
>> +plane_state->base.src.y2 =
>> +DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 
>> 18;
> Since this can

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Ville Syrjälä

On Thu, Apr 19, 2018 at 10:12:56AM +0200, Maarten Lankhorst wrote:
> Op 18-04-18 om 20:35 schreef Ville Syrjälä:
> > On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> >> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> >>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>  From: Maarten Lankhorst 
> 
>  We skip src trunction/adjustments for
>  NV12 case and handle the sizes directly.
>  Without this, pipe fifo underruns are seen on APL/KBL.
> 
>  v2: For NV12, making the src coordinates multiplier of 4
> 
>  v3: Moving all the src coords handling code for NV12
>  to skl_check_nv12_surface
> 
>  Signed-off-by: Maarten Lankhorst 
>  Signed-off-by: Vidya Srinivas 
>  ---
>   drivers/gpu/drm/i915/intel_display.c | 39 
>  
>   drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
>   2 files changed, 50 insertions(+), 4 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/intel_display.c 
>  b/drivers/gpu/drm/i915/intel_display.c
>  index 925402e..b8dbaca 100644
>  --- a/drivers/gpu/drm/i915/intel_display.c
>  +++ b/drivers/gpu/drm/i915/intel_display.c
>  @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct 
>  intel_crtc_state *crtc_state,
>   return 0;
>   }
>   
>  +static int
>  +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>  +   struct intel_plane_state *plane_state)
>  +{
>  +int crtc_x2 = plane_state->base.crtc_x + 
>  plane_state->base.crtc_w;
>  +int crtc_y2 = plane_state->base.crtc_y + 
>  plane_state->base.crtc_h;
>  +
>  +if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>  +((plane_state->base.src_y >> 16) % 4) != 0 ||
>  +((plane_state->base.src_w >> 16) % 4) != 0 ||
>  +((plane_state->base.src_h >> 16) % 4) != 0) {
>  +DRM_DEBUG_KMS("src coords must be multiple of 4 for 
>  NV12\n");
>  +return -EINVAL;
>  +}
> >>> I don't really see why we should check these. The clipped coordinates
> >>> are what matters.
> >> To propagate our limits to the userspace. I think we should do it for all 
> >> formats,
> >> but NV12 is the first YUV format we have tests for. If we could we should 
> >> do
> >> something similar for the other YUV formats, but they have different 
> >> requirements.
> >>
> >> In case of NV12 we don't have existing userspace, there will be nothing 
> >> that
> >> breaks if we enforce limits from the start.
> > But what about sub-pixel coordinates? You're totally ignoring them here.
> > We need to come up with some proper rules for this stuff.
> 
> Would we break anything if we disallow sub-pixel coordinates for i915 
> globally? It's not like we supported them before,
> but I'm not sure that change would break anything.

Not really I suppose. IIRC the hw did reintroduce partial sub-pixel
coordinate support for NV12 specifically. I do wish they'd done it
fully for all formats.

> 
>  +
>  +/* Clipping would cause a 1-3 pixel gap at the edge of the 
>  screen? */
>  +if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w 
>  % 4) ||
>  +(crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h 
>  % 4)) {
>  +DRM_DEBUG_KMS("It's not possible to clip %u,%u to 
>  %u,%u\n",
>  +  crtc_x2, crtc_y2,
>  +  crtc_state->pipe_src_w, 
>  crtc_state->pipe_src_h);
>  +return -EINVAL;
>  +}
> >>> Why should we care? The current code already plays it fast and loose
> >>> and allows the dst rectangle to shrink to accomodate the hw limits.
> >>> If we want to change that we should change it universally.
> >> Unfortunately for the other formats we already have an existing userspace
> >> (X.org) that doesn't perform any validation. We can't change it for that,
> >> but we can prevent future mistakes.
> > We should do it uniformly. Not per-format. That will make the code
> > unmaintainable real quick.
>  +
>  +plane_state->base.src.x1 =
>  +DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 
>  18;
>  +plane_state->base.src.x2 =
>  +DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 
>  18;
>  +plane_state->base.src.y1 =
>  +DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 
>  18;
>  +plane_state->base.src.y2 =
>  +DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 
>  18;
> >>> Since this can now increase the size of the source rectangle our

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Maarten Lankhorst

Op 19-04-18 om 13:22 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 02:36:42AM +, Srinivas, Vidya wrote:
>>
>>
>>
>>> -Original Message-
>>> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>>> Sent: Thursday, April 19, 2018 12:06 AM
>>> To: Maarten Lankhorst 
>>> Cc: Srinivas, Vidya ; intel-
>>> g...@lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
>>> skl_check_nv12_surface for NV12
>>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
 Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>> From: Maarten Lankhorst 
>> >
>> We skip src trunction/adjustments for
>> NV12 case and handle the sizes directly.
>> Without this, pipe fifo underruns are seen on APL/KBL.
>> v2: For NV12, making the src coordinates multiplier of 4
>> v3: Moving all the src coords handling code for NV12 to
>> skl_check_nv12_surface
>> Signed-off-by: Maarten Lankhorst
>> >
>> Signed-off-by: Vidya Srinivas 
>> >
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 39
>> 
>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
>>  2 files changed, 50 insertions(+), 4 deletions(-)
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 925402e..b8dbaca 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
>>> struct intel_crtc_state *crtc_state,
>>  return 0;
>>  }
>> +static int
>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>> +   struct intel_plane_state 
>> *plane_state) {
>> +int crtc_x2 = plane_state->base.crtc_x + 
>> plane_state->base.crtc_w;
>> +int crtc_y2 = plane_state->base.crtc_y +
>> +plane_state->base.crtc_h;
>> +
>> +if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>> +((plane_state->base.src_y >> 16) % 4) != 0 ||
>> +((plane_state->base.src_w >> 16) % 4) != 0 ||
>> +((plane_state->base.src_h >> 16) % 4) != 0) {
>> +DRM_DEBUG_KMS("src coords must be 
>> multiple of 4 for
>>> NV12\n");
>> +return -EINVAL;
>> +}
> I don't really see why we should check these. The clipped
> coordinates are what matters.
 To propagate our limits to the userspace. I think we should do it for
 all formats, but NV12 is the first YUV format we have tests for. If we
 could we should do something similar for the other YUV formats, but they
>>> have different requirements.
 In case of NV12 we don't have existing userspace, there will be
 nothing that breaks if we enforce limits from the start.
>>> But what about sub-pixel coordinates? You're totally ignoring them here.
>>> We need to come up with some proper rules for this stuff.
>> +
>> +/* Clipping would cause a 1-3 pixel gap at the edge of 
>> the screen? */
>> +if ((crtc_x2 > crtc_state->pipe_src_w && 
>> crtc_state->pipe_src_w %
>>> 4) ||
>> +(crtc_y2 > crtc_state->pipe_src_h && 
>> crtc_state->pipe_src_h % 4))
>>> {
>> +DRM_DEBUG_KMS("It's not possible to 
>> clip %u,%u to
>>> %u,%u\n",
>> +  crtc_x2, crtc_y2,
>> +  
>> crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>> +return -EINVAL;
>> +}
> Why should we care? The current code already plays it fast and loose
> and allows the dst rectangle to shrink to accomodate the hw limits.
> If we want to change that we should change it universally.
 Unfortunately for the other formats we already have an existing
 userspace
 (X.org) that doesn't perform any validation. We can't change it for
 that, but we can prevent future mistakes.
>>> We should do it uniformly. Not per-format. That will make the code
>>> unmaintainable real quick.
>> +
>> +plane_state->base.src.x1 =
>> +
>> DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<
>>> 18;
>> +plane_state->base.src.x2 =
>> +
>>

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Ville Syrjälä

On Thu, Apr 19, 2018 at 02:36:42AM +, Srinivas, Vidya wrote:
> 
> 
> 
> 
> > -Original Message-
> 
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> 
> > Sent: Thursday, April 19, 2018 12:06 AM
> 
> > To: Maarten Lankhorst 
> 
> > Cc: Srinivas, Vidya ; intel-
> 
> > g...@lists.freedesktop.org
> 
> > Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> 
> > skl_check_nv12_surface for NV12
> 
> >
> 
> > On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> 
> > > Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> 
> > > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> 
> > > >> From: Maarten Lankhorst 
> > > >> >
> 
> > > >>
> 
> > > >> We skip src trunction/adjustments for
> 
> > > >> NV12 case and handle the sizes directly.
> 
> > > >> Without this, pipe fifo underruns are seen on APL/KBL.
> 
> > > >>
> 
> > > >> v2: For NV12, making the src coordinates multiplier of 4
> 
> > > >>
> 
> > > >> v3: Moving all the src coords handling code for NV12 to
> 
> > > >> skl_check_nv12_surface
> 
> > > >>
> 
> > > >> Signed-off-by: Maarten Lankhorst
> 
> > > >> >
> 
> > > >> Signed-off-by: Vidya Srinivas 
> > > >> >
> 
> > > >> ---
> 
> > > >>  drivers/gpu/drm/i915/intel_display.c | 39
> 
> > > >> 
> 
> > > >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
> 
> > > >>  2 files changed, 50 insertions(+), 4 deletions(-)
> 
> > > >>
> 
> > > >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> b/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> index 925402e..b8dbaca 100644
> 
> > > >> --- a/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
> 
> > struct intel_crtc_state *crtc_state,
> 
> > > >>  return 0;
> 
> > > >>  }
> 
> > > >>
> 
> > > >> +static int
> 
> > > >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> 
> > > >> +   struct intel_plane_state 
> > > >> *plane_state) {
> 
> > > >> +int crtc_x2 = plane_state->base.crtc_x + 
> > > >> plane_state->base.crtc_w;
> 
> > > >> +int crtc_y2 = plane_state->base.crtc_y +
> 
> > > >> +plane_state->base.crtc_h;
> 
> > > >> +
> 
> > > >> +if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> 
> > > >> +((plane_state->base.src_y >> 16) % 4) != 0 ||
> 
> > > >> +((plane_state->base.src_w >> 16) % 4) != 0 ||
> 
> > > >> +((plane_state->base.src_h >> 16) % 4) != 0) {
> 
> > > >> +DRM_DEBUG_KMS("src coords must be 
> > > >> multiple of 4 for
> 
> > NV12\n");
> 
> > > >> +return -EINVAL;
> 
> > > >> +}
> 
> > > > I don't really see why we should check these. The clipped
> 
> > > > coordinates are what matters.
> 
> > >
> 
> > > To propagate our limits to the userspace. I think we should do it for
> 
> > > all formats, but NV12 is the first YUV format we have tests for. If we
> 
> > > could we should do something similar for the other YUV formats, but they
> 
> > have different requirements.
> 
> > >
> 
> > > In case of NV12 we don't have existing userspace, there will be
> 
> > > nothing that breaks if we enforce limits from the start.
> 
> >
> 
> > But what about sub-pixel coordinates? You're totally ignoring them here.
> 
> > We need to come up with some proper rules for this stuff.
> 
> >
> 
> > >
> 
> > > >> +
> 
> > > >> +/* Clipping would cause a 1-3 pixel gap at the edge 
> > > >> of the screen? */
> 
> > > >> +if ((crtc_x2 > crtc_state->pipe_src_w && 
> > > >> crtc_state->pipe_src_w %
> 
> > 4) ||
> 
> > > >> +(crtc_y2 > crtc_state->pipe_src_h && 
> > > >> crtc_state->pipe_src_h % 4))
> 
> > {
> 
> > > >> +DRM_DEBUG_KMS("It's not possible to 
> > > >> clip %u,%u to
> 
> > %u,%u\n",
> 
> > > >> +  crtc_x2, 
> > > >> crtc_y2,
> 
> > > >> +  
> > > >> crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> 
> > > >> +return -EINVAL;
> 
> > > >> +}
> 
> > > > Why should we care? The current code already plays it fast and loose
> 
> > > > and allows the dst rectangle to shrink to accomodate the hw limits.
> 
> > > > If we want to change that we should change it universally.
> 
> > >
> 
> > > Unfortunately for the other formats we already have an existing
> 
> > > userspace
> 
> > > (X.org) that doesn't perform any

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/psr: Remove intel_crtc_state parameter from disable()

2018-04-19 Thread Ville Syrjälä

On Wed, Apr 18, 2018 at 03:43:05PM -0700, José Roberto de Souza wrote:
> It is only used by VLV/CHV and we can get this information from
> intel_dp for those platforms.

But why? Abusing active_pipe (which is there just for the pps
tracking) is not a good idea IMO.

> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Cc: Lucas De Marchi 
> Cc: Ville Syrjälä 
> ---
> 
> Changes from v1:
> - not using legacy drm_crtc pointer(struct drm_crtc *crtc = 
> intel_dig_port->base.base.crtc)
> 
>  drivers/gpu/drm/i915/i915_drv.h  |  3 +--
>  drivers/gpu/drm/i915/intel_psr.c | 17 +++--
>  2 files changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 476bca872d48..f5ffb3d72cef 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -612,8 +612,7 @@ struct i915_psr {
>  
>   void (*enable_source)(struct intel_dp *,
> const struct intel_crtc_state *);
> - void (*disable_source)(struct intel_dp *,
> -const struct intel_crtc_state *);
> + void (*disable_source)(struct intel_dp *intel_dp);
>   void (*enable_sink)(struct intel_dp *);
>   void (*activate)(struct intel_dp *);
>   void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index ebc47e2b08ca..934498505356 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -665,38 +665,35 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> -static void vlv_psr_disable(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *old_crtc_state)
> +static void vlv_psr_disable(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
>   uint32_t val;
>  
>   if (dev_priv->psr.active) {
>   /* Put VLV PSR back to PSR_state 0 (disabled). */
>   if (intel_wait_for_register(dev_priv,
> - VLV_PSRSTAT(crtc->pipe),
> + VLV_PSRSTAT(intel_dp->active_pipe),
>   VLV_EDP_PSR_IN_TRANS,
>   0,
>   1))
>   WARN(1, "PSR transition took longer than expected\n");
>  
> - val = I915_READ(VLV_PSRCTL(crtc->pipe));
> + val = I915_READ(VLV_PSRCTL(intel_dp->active_pipe));
>   val &= ~VLV_EDP_PSR_ACTIVE_ENTRY;
>   val &= ~VLV_EDP_PSR_ENABLE;
>   val &= ~VLV_EDP_PSR_MODE_MASK;
> - I915_WRITE(VLV_PSRCTL(crtc->pipe), val);
> + I915_WRITE(VLV_PSRCTL(intel_dp->active_pipe), val);
>  
>   dev_priv->psr.active = false;
>   } else {
> - WARN_ON(vlv_is_psr_active_on_pipe(dev, crtc->pipe));
> + WARN_ON(vlv_is_psr_active_on_pipe(dev, intel_dp->active_pipe));
>   }
>  }
>  
> -static void hsw_psr_disable(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *old_crtc_state)
> +static void hsw_psr_disable(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
> @@ -765,7 +762,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
>   return;
>   }
>  
> - dev_priv->psr.disable_source(intel_dp, old_crtc_state);
> + dev_priv->psr.disable_source(intel_dp);
>  
>   /* Disable PSR on Sink */
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
> -- 
> 2.17.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable NV12 support (rev3)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enable NV12 support (rev3)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4068 -> Patchwork_8750 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/3/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8750 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128)

igt@kms_setmode@basic-clone-single-crtc:
  fi-glk-1:   NOTRUN -> INCOMPLETE (k.org#198133, fdo#103359)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (34 -> 32) ==

  Additional (1): fi-glk-1 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8750

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8750: 81fc20b459963794dc35ce57ecf8a5761488ea97 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

81fc20b45996 drm/i915: Add skl_check_nv12_surface for NV12
01ff447071f1 drm/i915: Enable Display WA 0528
867177cbf535 drm/i915: Add NV12 support to intel_framebuffer_init
97ee459e9828 drm/i915: Add NV12 as supported format for sprite plane
1e16d33c75f5 drm/i915: Add NV12 as supported format for primary plane
5083520a4ee4 drm/i915: Enable display workaround 827 for all planes, v2.

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Store a pointer to intel_context in i915_request

2018-04-19 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-19 11:40:06)
> 
> On 19/04/2018 08:17, Chris Wilson wrote:
> > To ease the frequent and ugly pointer dance of
> > >gem_context->engine[request->engine->id] during request
> > submission, store that pointer as request->hw_context. One major
> > advantage that we will exploit later is that this decouples the logical
> > context state from the engine itself.
> 
> I can see merit in making all the places which work on engines or 
> requests more logically and elegantly grab the engine specific context.
> 
> Authors of current unmerged work will probably be not so thrilled though.

> > @@ -353,60 +346,56 @@ int intel_gvt_scan_and_shadow_workload(struct 
> > intel_vgpu_workload *workload)
> >   struct intel_vgpu_submission *s = >submission;
> >   struct i915_gem_context *shadow_ctx = s->shadow_ctx;
> >   struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
> > - int ring_id = workload->ring_id;
> > - struct intel_engine_cs *engine = dev_priv->engine[ring_id];
> > - struct intel_ring *ring;
> > + struct intel_engine_cs *engine = dev_priv->engine[workload->ring_id];
> > + struct intel_context *ce;
> >   int ret;
> >   
> >   lockdep_assert_held(_priv->drm.struct_mutex);
> >   
> > - if (workload->shadowed)
> > + if (workload->req)
> >   return 0;
> 
> GVT team will need to look at this hunk/function.
...
> At which point I skip over all GVT and continue further down. :)

That code doesn't merit your attention (or ours really until it is
improved, it really is staging/ quality).

> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 2fe779cab298..ed1c591ee866 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -125,16 +125,10 @@ static void i915_gem_context_free(struct 
> > i915_gem_context *ctx)
> >   i915_ppgtt_put(ctx->ppgtt);
> >   
> >   for (i = 0; i < I915_NUM_ENGINES; i++) {
> > - struct intel_context *ce = >engine[i];
> > + struct intel_context *ce = >__engine[i];
> >   
> > - if (!ce->state)
> > - continue;
> > -
> > - WARN_ON(ce->pin_count);
> > - if (ce->ring)
> > - intel_ring_free(ce->ring);
> > -
> > - __i915_gem_object_release_unless_active(ce->state->obj);
> > + if (ce->ops)
> 
> Is ce->ops now the gate which was "if (!ce->state) continue" before, to 
> avoid GEM_BUG_ON in execlists_context_destroy? I am wondering if this 
> loop should not just be for_each_engine. Places which walk until 
> I915_NUM_ENGINES should be very special and this one doesn't feel like 
> one.

s/I915_NUM_ENGINES/ARRAY_SIZE(ctx->__engine)/ That's the semantic intent
here. That we aren't just thinking about engines, but the contents of
the context struct. We teardown the struct.

> > @@ -1010,9 +1018,12 @@ bool intel_engine_has_kernel_context(const struct 
> > intel_engine_cs *engine)
> >*/
> >   rq = __i915_gem_active_peek(>timeline->last_request);
> >   if (rq)
> > - return rq->gem_context == kernel_context;
> > - else
> > - return engine->last_retired_context == kernel_context;
> > + return rq->gem_context == kctx;
> > +
> > + if (!engine->last_retired_context)
> > + return false;
> > +
> > + return engine->last_retired_context->gem_context == kctx;
> 
> You thought this will be a bit more readable/obvious?

Hmm, I wrote this before I wrote to_intel_context(). If we use that, it
looks like

const struct intel_context *kernel_context =
to_intel_context(engine->i915->kernel_context, engine);
struct i915_request *rq;

rq = __i915_gem_active_peek(>timeline->last_request);
if (rq)
return rq->hw_context == kernel_context;
else
return engine->last_retired_context == kernel_context;

which isn't as bad as the first pass was...

> > @@ -511,9 +511,7 @@ static void guc_add_request(struct intel_guc *guc, 
> > struct i915_request *rq)
> >   {
> >   struct intel_guc_client *client = guc->execbuf_client;
> >   struct intel_engine_cs *engine = rq->engine;
> > - u32 ctx_desc =
> > - lower_32_bits(intel_lr_context_descriptor(rq->gem_context,
> > -   engine));
> > + u32 ctx_desc = lower_32_bits(rq->hw_context->lrc_desc);
> 
> Ha...
> 
> >   u32 ring_tail = intel_ring_set_tail(rq->ring, rq->tail) / sizeof(u64);
> >   
> >   spin_lock(>wq_lock);
> > @@ -551,8 +549,8 @@ 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);
> > -

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsi: fix dphy param field widths and range checks for chv+

2018-04-19 Thread Ville Syrjälä

On Thu, Apr 19, 2018 at 11:59:40AM +0300, Jani Nikula wrote:
> Current CHV and BXT bspec says the dphy param register has four 8-bit
> fields instead of the smaller VLV field widths. CHV bspec mentions the
> register has changed since K0, but there's no indication of what exactly
> changed. Lacking further details, change the field widths for all CHV
> and later.

K0 didn't happen, and looks like the linked HSD specifically says that
this change was meant for K0. So I suspect this patch is wrong.

The BXT HSD says planned for B0, but not sure if that actually happened
either.

On my VLV the reserved bits can't be set:
intel_reg write 0x18:0xb080 0x
intel_reg write 0x18:0xb880 0x
intel_reg read 0x18:0xb080 0x18:0xb880
 (0x0018:0xb080): 0x3f1fff3f
 (0x0018:0xb880): 0x3f1fff3f

So presumably the same rmw trick could be used to check what
how many bits we have on CHV/BXT.

Also looks like the CHV spec was forked from VLV before someone fixed
the prepare count to be 6 bits, which seems to be what my VLV actually
has as well. Not the first time the VLV docs are more up to date than
the CHV ones unfortunately.

> 
> Define the max values based on the platform. Also define them based on
> the register definitions instead of duplicating information.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106130
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 11 +++
>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 31 +++
>  2 files changed, 26 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fb106026a1f4..f4435a13b757 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9547,14 +9547,17 @@ enum skl_power_gate {
>  #define _MIPIA_DPHY_PARAM(dev_priv->mipi_mmio_base + 0xb080)
>  #define _MIPIC_DPHY_PARAM(dev_priv->mipi_mmio_base + 0xb880)
>  #define MIPI_DPHY_PARAM(port)_MMIO_MIPI(port, 
> _MIPIA_DPHY_PARAM, _MIPIC_DPHY_PARAM)
> -#define  EXIT_ZERO_COUNT_SHIFT   24
>  #define  EXIT_ZERO_COUNT_MASK(0x3f << 24)
> -#define  TRAIL_COUNT_SHIFT   16
> +#define  EXIT_ZERO_COUNT_MASK_CHV(0xff << 24)
> +#define  EXIT_ZERO_COUNT_SHIFT   24
>  #define  TRAIL_COUNT_MASK(0x1f << 16)
> -#define  CLK_ZERO_COUNT_SHIFT8
> +#define  TRAIL_COUNT_MASK_CHV(0xff << 16)
> +#define  TRAIL_COUNT_SHIFT   16
>  #define  CLK_ZERO_COUNT_MASK (0xff << 8)
> -#define  PREPARE_COUNT_SHIFT 0
> +#define  CLK_ZERO_COUNT_SHIFT8
>  #define  PREPARE_COUNT_MASK  (0x3f << 0)
> +#define  PREPARE_COUNT_MASK_CHV  (0xff << 0)
> +#define  PREPARE_COUNT_SHIFT 0
>  
>  /* bits 31:0 */
>  #define _MIPIA_DBI_BW_CTRL   (dev_priv->mipi_mmio_base + 0xb084)
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index 4d6ffa7b3e7b..8d3dea693840 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -41,10 +41,17 @@
>  #define MIPI_VIRTUAL_CHANNEL_SHIFT   1
>  #define MIPI_PORT_SHIFT  3
>  
> -#define PREPARE_CNT_MAX  0x3F
> -#define EXIT_ZERO_CNT_MAX0x3F
> -#define CLK_ZERO_CNT_MAX 0xFF
> -#define TRAIL_CNT_MAX0x1F
> +#define EXIT_ZERO_CNT_MAX(dev_priv) \
> + ((IS_VALLEYVIEW(dev_priv) ? EXIT_ZERO_COUNT_MASK : 
> EXIT_ZERO_COUNT_MASK_CHV) >> EXIT_ZERO_COUNT_SHIFT)
> +
> +#define TRAIL_CNT_MAX(dev_priv) \
> + ((IS_VALLEYVIEW(dev_priv) ? TRAIL_COUNT_MASK : TRAIL_COUNT_MASK_CHV) >> 
> TRAIL_COUNT_SHIFT)
> +
> +#define CLK_ZERO_CNT_MAX(dev_priv) \
> + (CLK_ZERO_COUNT_MASK >> CLK_ZERO_COUNT_SHIFT)
> +
> +#define PREPARE_CNT_MAX(dev_priv)\
> + ((IS_VALLEYVIEW(dev_priv) ? PREPARE_COUNT_MASK : 
> PREPARE_COUNT_MASK_CHV) >> PREPARE_COUNT_SHIFT)
>  
>  #define NS_KHZ_RATIO 100
>  
> @@ -647,9 +654,9 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
> panel_id)
>   /* prepare count */
>   prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * mul);
>  
> - if (prepare_cnt > PREPARE_CNT_MAX) {
> + if (prepare_cnt > PREPARE_CNT_MAX(dev_priv)) {
>   DRM_DEBUG_KMS("prepare count too high %u\n", prepare_cnt);
> - prepare_cnt = PREPARE_CNT_MAX;
> + prepare_cnt = PREPARE_CNT_MAX(dev_priv);
>   }
>  
>   /* exit zero count */
> @@ -667,9 +674,9 @@ bool

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/dsi: improve dphy param limits logging

2018-04-19 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915/dsi: improve dphy param limits 
logging
URL   : https://patchwork.freedesktop.org/series/41953/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4067_full -> Patchwork_8748_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8748_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8748_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41953/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8748_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  SKIP -> PASS +3


== Known issues ==

  Here are the changes found in Patchwork_8748_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_hangman@error-state-capture-blt:
  shard-snb:  PASS -> INCOMPLETE (fdo#103880)

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_chv_cursor_fail@pipe-b-128x128-bottom-edge:
  shard-apl:  PASS -> FAIL (fdo#104671)

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#102887)


 Possible fixes 

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-apl:  FAIL (fdo#100368) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880
  fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023


== Participating hosts (6 -> 4) ==

  Missing(2): shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4067 -> Patchwork_8748

  CI_DRM_4067: 1c7ccdf37b04bedb10e2191d34dfbba62beb79ea @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8748: b6472fbf79b8a753fd55d7ec7a93f484ad61bae1 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable NV12 support (rev3)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enable NV12 support (rev3)
URL   : https://patchwork.freedesktop.org/series/41674/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5083520a4ee4 drm/i915: Enable display workaround 827 for all planes, v2.
-:64: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#64: FILE: drivers/gpu/drm/i915/intel_display.c:5151:
+   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+  IS_CANNONLAKE(dev_priv))

total: 0 errors, 0 warnings, 1 checks, 98 lines checked
1e16d33c75f5 drm/i915: Add NV12 as supported format for primary plane
97ee459e9828 drm/i915: Add NV12 as supported format for sprite plane
867177cbf535 drm/i915: Add NV12 support to intel_framebuffer_init
01ff447071f1 drm/i915: Enable Display WA 0528
81fc20b45996 drm/i915: Add skl_check_nv12_surface for NV12

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move fiddling with engine->last_retired_context

2018-04-19 Thread Tvrtko Ursulin



On 19/04/2018 08:17, Chris Wilson wrote:

Move the knowledge about resetting the current context tracking on the
engine from inside i915_gem_context.c into intel_engine_cs.c

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
  drivers/gpu/drm/i915/intel_engine_cs.c  | 24 
  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
  3 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74435affe23f..2fe779cab298 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -514,16 +514,8 @@ void i915_gem_contexts_lost(struct drm_i915_private 
*dev_priv)
  
  	lockdep_assert_held(_priv->drm.struct_mutex);
  
-	for_each_engine(engine, dev_priv, id) {

-   engine->legacy_active_context = NULL;
-   engine->legacy_active_ppgtt = NULL;
-
-   if (!engine->last_retired_context)
-   continue;
-
-   engine->context_unpin(engine, engine->last_retired_context);
-   engine->last_retired_context = NULL;
-   }
+   for_each_engine(engine, dev_priv, id)
+   intel_engine_lost_context(engine);
  }
  
  void i915_gem_contexts_fini(struct drm_i915_private *i915)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0248d64c2a72..4749426f9cad 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1084,6 +1084,30 @@ void intel_engines_unpark(struct drm_i915_private *i915)
}
  }
  
+

+/**
+ * intel_engine_lost_context: called when the GPU is reset into unknown state
+ * @engine: the engine
+ *
+ * We have either reset the GPU or otherwise about to lose state tracking of
+ * the current GPU logical state (e.g. suspend). On next use, it is therefore
+ * imperative that we make no presumptions about the current state and load
+ * from scratch.
+ */
+void intel_engine_lost_context(struct intel_engine_cs *engine)
+{
+   struct i915_gem_context *ctx;
+
+   lockdep_assert_held(>i915->drm.struct_mutex);
+
+   engine->legacy_active_context = NULL;
+   engine->legacy_active_ppgtt = NULL;
+
+   ctx = fetch_and_zero(>last_retired_context);
+   if (ctx)
+   engine->context_unpin(engine, ctx);
+}
+
  bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
  {
switch (INTEL_GEN(engine->i915)) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c5e27905b0e1..1231695fb4da 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -1044,6 +1044,8 @@ bool intel_engine_has_kernel_context(const struct 
intel_engine_cs *engine);
  void intel_engines_park(struct drm_i915_private *i915);
  void intel_engines_unpark(struct drm_i915_private *i915);
  
+void intel_engine_lost_context(struct intel_engine_cs *engine);

+
  void intel_engines_reset_default_submission(struct drm_i915_private *i915);
  unsigned int intel_engines_has_context_isolation(struct drm_i915_private 
*i915);
  



Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move request->ctx aside

2018-04-19 Thread Tvrtko Ursulin



On 19/04/2018 08:17, Chris Wilson wrote:

In the next patch, we want to store the intel_context pointer inside
i915_request, as it is frequently access via a convoluted dance when
submitting the request to hw. Having two context pointers inside
i915_request leads to confusion so first rename the existing
i915_gem_context pointer to i915_request.gem_context.


Did you do this manually or with spatch? If spatch then please paste the 
rule in commit message.




Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/gvt/scheduler.c  |  4 +--
  drivers/gpu/drm/i915/i915_debugfs.c   |  4 +--
  drivers/gpu/drm/i915/i915_gem.c   | 10 +++
  drivers/gpu/drm/i915/i915_gpu_error.c | 18 +++-
  drivers/gpu/drm/i915/i915_request.c   |  8 ++---
  drivers/gpu/drm/i915/i915_request.h   |  2 +-
  drivers/gpu/drm/i915/i915_trace.h |  6 ++--
  drivers/gpu/drm/i915/intel_engine_cs.c|  2 +-
  drivers/gpu/drm/i915/intel_guc_submission.c   |  7 +++--
  drivers/gpu/drm/i915/intel_lrc.c  | 29 ++-
  drivers/gpu/drm/i915/intel_ringbuffer.c   | 11 +++
  .../gpu/drm/i915/selftests/intel_hangcheck.c  |  5 +++-
  drivers/gpu/drm/i915/selftests/intel_lrc.c|  2 +-
  13 files changed, 58 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f3d21849b0cb..f64cccb2e793 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -205,7 +205,7 @@ static int populate_shadow_context(struct 
intel_vgpu_workload *workload)
  
  static inline bool is_gvt_request(struct i915_request *req)

  {
-   return i915_gem_context_force_single_submission(req->ctx);
+   return i915_gem_context_force_single_submission(req->gem_context);
  }
  
  static void save_ring_hw_state(struct intel_vgpu *vgpu, int ring_id)

@@ -305,7 +305,7 @@ static int copy_workload_to_ring_buffer(struct 
intel_vgpu_workload *workload)
struct i915_request *req = workload->req;
  
  	if (IS_KABYLAKE(req->i915) &&

-   is_inhibit_context(req->ctx, req->engine->id))
+   is_inhibit_context(req->gem_context, req->engine->id))
intel_vgpu_restore_inhibit_context(vgpu, req);
  
  	/* allocate shadow ring buffer */

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e0274f41bc76..792f69e44ba5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -539,8 +539,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
   struct i915_request,
   client_link);
rcu_read_lock();
-   task = pid_task(request && request->ctx->pid ?
-   request->ctx->pid : file->pid,
+   task = pid_task(request && request->gem_context->pid ?
+   request->gem_context->pid : file->pid,
PIDTYPE_PID);
print_file_stats(m, task ? task->comm : "", stats);
rcu_read_unlock();
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..4dba735505d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3108,7 +3108,7 @@ static void skip_request(struct i915_request *request)
  static void engine_skip_context(struct i915_request *request)
  {
struct intel_engine_cs *engine = request->engine;
-   struct i915_gem_context *hung_ctx = request->ctx;
+   struct i915_gem_context *hung_ctx = request->gem_context;
struct intel_timeline *timeline;
unsigned long flags;
  
@@ -3118,7 +3118,7 @@ static void engine_skip_context(struct i915_request *request)

spin_lock(>lock);
  
  	list_for_each_entry_continue(request, >timeline->requests, link)

-   if (request->ctx == hung_ctx)
+   if (request->gem_context == hung_ctx)
skip_request(request);
  
  	list_for_each_entry(request, >requests, link)

@@ -3164,11 +3164,11 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
}
  
  	if (stalled) {

-   i915_gem_context_mark_guilty(request->ctx);
+   i915_gem_context_mark_guilty(request->gem_context);
skip_request(request);
  
  		/* If this context is now banned, skip all pending requests. */

-   if (i915_gem_context_is_banned(request->ctx))
+   if (i915_gem_context_is_banned(request->gem_context))
engine_skip_context(request);
} else {
/*
@@ -3178,7 +3178,7 @@ i915_gem_reset_request(struct intel_engine_cs *engine,

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Store a pointer to intel_context in i915_request

2018-04-19 Thread Tvrtko Ursulin



On 19/04/2018 08:17, Chris Wilson wrote:

To ease the frequent and ugly pointer dance of
>gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.


I can see merit in making all the places which work on engines or 
requests more logically and elegantly grab the engine specific context.


Authors of current unmerged work will probably be not so thrilled though.


Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gvt/mmio_context.c   |   6 +-
  drivers/gpu/drm/i915/gvt/mmio_context.h   |   2 +-
  drivers/gpu/drm/i915/gvt/scheduler.c  | 141 ++--
  drivers/gpu/drm/i915/gvt/scheduler.h  |   1 -
  drivers/gpu/drm/i915/i915_debugfs.c   |  20 ++-
  drivers/gpu/drm/i915/i915_drv.h   |   1 +
  drivers/gpu/drm/i915/i915_gem.c   |  14 +-
  drivers/gpu/drm/i915/i915_gem_context.c   |  19 +--
  drivers/gpu/drm/i915/i915_gem_context.h   |  27 +++-
  drivers/gpu/drm/i915/i915_gpu_error.c |   2 +-
  drivers/gpu/drm/i915/i915_perf.c  |  28 ++--
  drivers/gpu/drm/i915/i915_request.c   |  23 ++-
  drivers/gpu/drm/i915/i915_request.h   |   3 +-
  drivers/gpu/drm/i915/intel_engine_cs.c|  61 ---
  drivers/gpu/drm/i915/intel_guc_ads.c  |   2 +-
  drivers/gpu/drm/i915/intel_guc_submission.c   |  15 +-
  drivers/gpu/drm/i915/intel_lrc.c  | 151 +++---
  drivers/gpu/drm/i915/intel_lrc.h  |   7 -
  drivers/gpu/drm/i915/intel_ringbuffer.c   | 104 +++-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |   9 +-
  drivers/gpu/drm/i915/selftests/mock_context.c |   7 +
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  41 +++--
  .../gpu/drm/i915/selftests/mock_gem_device.c  |   5 +
  23 files changed, 381 insertions(+), 308 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index a5bac83d53a9..708170e61625 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -446,9 +446,9 @@ static void switch_mocs(struct intel_vgpu *pre, struct 
intel_vgpu *next,
  
  #define CTX_CONTEXT_CONTROL_VAL	0x03
  
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id)

+bool is_inhibit_context(struct intel_context *ce)
  {
-   u32 *reg_state = ctx->engine[ring_id].lrc_reg_state;
+   const u32 *reg_state = ce->lrc_reg_state;
u32 inhibit_mask =
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
  
@@ -501,7 +501,7 @@ static void switch_mmio(struct intel_vgpu *pre,

 * itself.
 */
if (mmio->in_context &&
-   !is_inhibit_context(s->shadow_ctx, ring_id))
+   
!is_inhibit_context(>shadow_ctx->__engine[ring_id]))
continue;
  
  			if (mmio->mask)

diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.h 
b/drivers/gpu/drm/i915/gvt/mmio_context.h
index 0439eb8057a8..5c3b9ff9f96a 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.h
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.h
@@ -49,7 +49,7 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
  
  void intel_gvt_init_engine_mmio_context(struct intel_gvt *gvt);
  
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id);

+bool is_inhibit_context(struct intel_context *ce);
  
  int intel_vgpu_restore_inhibit_context(struct intel_vgpu *vgpu,

   struct i915_request *req);
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f64cccb2e793..c2e440200b0c 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -54,11 +54,8 @@ static void set_context_pdp_root_pointer(
  
  static void update_shadow_pdps(struct intel_vgpu_workload *workload)

  {
-   struct intel_vgpu *vgpu = workload->vgpu;
-   int ring_id = workload->ring_id;
-   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   workload->req->hw_context->state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
  
@@ -128,9 +125,8 @@ static int populate_shadow_context(struct intel_vgpu_workload *workload)

struct intel_vgpu *vgpu = workload->vgpu;
struct intel_gvt *gvt = vgpu->gvt;
int ring_id = workload->ring_id;
-   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   workload->req->hw_context->state->obj;
struct

[Intel-gfx] [PATCH v5 1/6] drm/i915: Enable display workaround 827 for all planes, v2.

2018-04-19 Thread Vidya Srinivas

From: Maarten Lankhorst 

The workaround was applied only to the primary plane, but is required
on all planes. Iterate over all planes in the crtc atomic check to see
if the workaround is enabled, and only perform the actual toggling in
the pre/post plane update functions.

Changes since v1:
- Track active NV12 planes in a nv12_planes bitmask. (Ville)

v2: Removing BROXTON support for NV12 due to WA826

Signed-off-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  7 -
 drivers/gpu/drm/i915/intel_display.c  | 43 +++
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 3 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce8..6d06878 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -183,11 +183,16 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
}
 
/* FIXME pre-g4x don't work like this */
-   if (intel_state->base.visible)
+   if (state->visible)
crtc_state->active_planes |= BIT(intel_plane->id);
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
 
+   if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+   crtc_state->nv12_planes |= BIT(intel_plane->id);
+   else
+   crtc_state->nv12_planes &= ~BIT(intel_plane->id);
+
return intel_plane_atomic_calc_changes(old_crtc_state,
   _state->base,
   old_plane_state,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 020900e..53f82fa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5138,6 +5138,22 @@ static bool hsw_post_update_enable_ips(const struct 
intel_crtc_state *old_crtc_s
return !old_crtc_state->ips_enabled;
 }
 
+static bool needs_nv12_wa(struct drm_i915_private *dev_priv,
+ const struct intel_crtc_state *crtc_state)
+{
+   if (!crtc_state->nv12_planes)
+   return false;
+
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+
+   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+  IS_CANNONLAKE(dev_priv))
+   return true;
+
+   return false;
+}
+
 static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
@@ -5162,7 +5178,6 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
if (old_primary_state) {
struct drm_plane_state *new_primary_state =
drm_atomic_get_new_plane_state(old_state, primary);
-   struct drm_framebuffer *fb = new_primary_state->fb;
 
intel_fbc_post_update(crtc);
 
@@ -5170,15 +5185,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
(needs_modeset(_config->base) ||
 !old_primary_state->visible))
intel_post_enable_primary(>base, pipe_config);
-
-   /* Display WA 827 */
-   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-   IS_CANNONLAKE(dev_priv)) {
-   if (fb && fb->format->format == DRM_FORMAT_NV12)
-   skl_wa_clkgate(dev_priv, crtc->pipe, false);
-   }
-
}
+
+   /* Display WA 827 */
+   if (needs_nv12_wa(dev_priv, old_crtc_state) &&
+   !needs_nv12_wa(dev_priv, pipe_config))
+   skl_wa_clkgate(dev_priv, crtc->pipe, false);
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5202,14 +5214,6 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
struct intel_plane_state *new_primary_state =
intel_atomic_get_new_plane_state(old_intel_state,
 
to_intel_plane(primary));
-   struct drm_framebuffer *fb = new_primary_state->base.fb;
-
-   /* Display WA 827 */
-   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-   IS_CANNONLAKE(dev_priv)) {
-   if (fb && fb->format->format == DRM_FORMAT_NV12)
-   skl_wa_clkgate(dev_priv, crtc->pipe, true);
-   }
 
intel_fbc_pre_update(crtc, pipe_config,

[Intel-gfx] [PATCH v5 3/6] drm/i915: Add NV12 as supported format for sprite plane

2018-04-19 Thread Vidya Srinivas

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

v11: Addressed review comments from Shashank Sharma

v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.

v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported. These were
review comments from Kristian Høgsberg 

v15: Added reviewed by from Juha-Pekka Heikkila

v16: Rebased the series

v17: Added all tiling under mod supported for NV12
Credits to Megha Aggarwal

v18: Added RB by Maarten and Kristian

Credits-to: Megha Aggarwal 
Credits-to: Kristian Høgsberg 
Reviewed-by: Kristian Høgsberg 
Reviewed-by: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aa1dfaa..8b7947d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1253,6 +1253,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static uint32_t skl_planar_formats[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1350,6 +1363,12 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
+   case DRM_FORMAT_NV12:
+   if (modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED ||
+   modifier == I915_FORMAT_MOD_Yf_TILED)
+   return true;
case DRM_FORMAT_C8:
if (modifier == DRM_FORMAT_MOD_LINEAR ||
modifier == I915_FORMAT_MOD_X_TILED ||
@@ -1446,8 +1465,14 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
 
-   plane_formats = skl_plane_formats;
-   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+   plane_formats = skl_planar_formats;
+   num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+   } else {
+

[Intel-gfx] [PATCH v5 5/6] drm/i915: Enable Display WA 0528

2018-04-19 Thread Vidya Srinivas

Possible hang with NV12 plane surface formats.
WA: When the plane source pixel format is NV12,
the CHICKEN_PIPESL_* register bit 22 must be set to 1
and the render decompression must not be enabled
on any of the planes in that pipe.

v2: removed unnecessary POSTING_READ

v3: Added RB from Maarten

v4: Removed support for NV12 for BROXTON

Credits-to: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 356336c..4d80bfe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -505,9 +505,21 @@ static const struct intel_limit intel_limits_bxt = {
 };
 
 static void
+skl_wa_528(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return;
+
+   if (enable)
+   I915_WRITE(CHICKEN_PIPESL_1(pipe), HSW_FBCQ_DIS);
+   else
+   I915_WRITE(CHICKEN_PIPESL_1(pipe), 0);
+}
+
+static void
 skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
 {
-   if (IS_SKYLAKE(dev_priv))
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
return;
 
if (enable)
@@ -5205,8 +5217,10 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
 
/* Display WA 827 */
if (needs_nv12_wa(dev_priv, old_crtc_state) &&
-   !needs_nv12_wa(dev_priv, pipe_config))
+   !needs_nv12_wa(dev_priv, pipe_config)) {
skl_wa_clkgate(dev_priv, crtc->pipe, false);
+   skl_wa_528(dev_priv, crtc->pipe, false);
+   }
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5243,8 +5257,10 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
 
/* Display WA 827 */
if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
-   needs_nv12_wa(dev_priv, pipe_config))
+   needs_nv12_wa(dev_priv, pipe_config)) {
skl_wa_clkgate(dev_priv, crtc->pipe, true);
+   skl_wa_528(dev_priv, crtc->pipe, true);
+   }
 
/*
 * Vblank time updates from the shadow to live plane control register
-- 
2.7.4

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

[Intel-gfx] [PATCH v5 4/6] drm/i915: Add NV12 support to intel_framebuffer_init

2018-04-19 Thread Vidya Srinivas

From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

v11: Addressed review comments from Shashank Sharma

v12: Adding Reviewed By from Shashank Sharma

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Maarten.
Add checks for fb width height for NV12 and fail the fb
creation if check fails. Added reviewed by from
Juha-Pekka Heikkila

v15: Rebased the series

v16: Setting the minimum value during fb creating to 16
as per Bspec for NV12. Earlier minimum was expected
to be > 16. Now changed it to >=16.

v17: Adding restriction to framebuffer_init - the fb
width and height should be a multiplier of 4

v18: Added RB from Maarten. Included Maarten's review comments
Dont allow CCS formats for fb creation of NV12

v19: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826

Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dc9c424..356336c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14264,6 +14264,20 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS ||
+   mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS) {
+   DRM_DEBUG_KMS("RC not to be enabled with NV12\n");
+   goto err;
+   }
+   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv) ||
+   IS_BROXTON(dev_priv)) {
+   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+ 
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
+   goto err;
+   }
+   break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
@@ -14276,6 +14290,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 
drm_helper_mode_fill_fb_struct(_priv->drm, fb, mode_cmd);
 
+   if (fb->format->format == DRM_FORMAT_NV12 &&
+   (fb->width < SKL_MIN_YUV_420_SRC_W ||
+fb->height < SKL_MIN_YUV_420_SRC_H ||
+(fb->width % 4) != 0 || (fb->height % 4) != 0)) {
+   DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
+   return -EINVAL;
+   }
+
for (i = 0; i < fb->format->num_planes; i++) {
u32 stride_alignment;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v5 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Vidya Srinivas

From: Maarten Lankhorst 

We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.

v2: For NV12, making the src coordinates multiplier of 4

v3: Moving all the src coords handling code for NV12
to skl_check_nv12_surface

v4: Added RB from Mika

Reviewed-by: Mika Kahola 
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 39 
 drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
 2 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4d80bfe..685845c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
return 0;
 }
 
+static int
+skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
+  struct intel_plane_state *plane_state)
+{
+   int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
+   int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
+
+   if (((plane_state->base.src_x >> 16) % 4) != 0 ||
+   ((plane_state->base.src_y >> 16) % 4) != 0 ||
+   ((plane_state->base.src_w >> 16) % 4) != 0 ||
+   ((plane_state->base.src_h >> 16) % 4) != 0) {
+   DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
+   return -EINVAL;
+   }
+
+   /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
+   if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
+   (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
+   DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
+ crtc_x2, crtc_y2,
+ crtc_state->pipe_src_w, crtc_state->pipe_src_h);
+   return -EINVAL;
+   }
+
+   plane_state->base.src.x1 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
+   plane_state->base.src.x2 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
+   plane_state->base.src.y1 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
+   plane_state->base.src.y2 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
+
+   return 0;
+}
+
 static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -3201,6 +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
 * the main surface setup depends on it.
 */
if (fb->format->format == DRM_FORMAT_NV12) {
+   ret = skl_check_nv12_surface(crtc_state, plane_state);
+   if (ret)
+   return ret;
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 8b7947d..f9985fb 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane,
return vscale;
}
 
-   /* Make the source viewport size an exact multiple of the 
scaling factors. */
-   drm_rect_adjust_size(src,
-drm_rect_width(dst) * hscale - 
drm_rect_width(src),
-drm_rect_height(dst) * vscale - 
drm_rect_height(src));
+   if (fb->format->format != DRM_FORMAT_NV12) {
+   /*
+* Make the source viewport size
+* an exact multiple of the scaling factors
+*/
+   drm_rect_adjust_size(src,
+(drm_rect_width(dst) * hscale -
+ drm_rect_width(src)),
+(drm_rect_height(dst) * vscale -
+ drm_rect_height(src)));
+   }
 
drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
state->base.rotation);
-- 
2.7.4

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

[Intel-gfx] [PATCH v5 2/6] drm/i915: Add NV12 as supported format for primary plane

2018-04-19 Thread Vidya Srinivas

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

v5: Rebased (me)

v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)

v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.

v11: Adding Reviewed By tag from Shashank Sharma

v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported. These were review comments
from Kristian Høgsberg 

v14: Added reviewed by from Juha-Pekka Heikkila

v15: Rebased the series

v16: Added all tiling support under mod supported
for NV12. Credits to Megha Aggarwal

v17: Added RB by Maarten and Kristian

v18: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826

Credits-to: Megha Aggarwal megha.aggar...@intel.com
Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Kristian Høgsberg 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 55 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 53f82fa..dc9c424 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t skl_pri_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13127,6 +13143,12 @@ static bool skl_mod_supported(uint32_t format, 
uint64_t modifier)
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
+   case DRM_FORMAT_NV12:
+   if (modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED ||
+   modifier == I915_FORMAT_MOD_Yf_TILED)
+   return true;
case DRM_FORMAT_C8:
if (modifier == DRM_FORMAT_MOD_LINEAR ||
modifier == I915_FORMAT_MOD_X_TILED ||
@@ -13331,6 +13353,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private 
*dev_priv,
return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
 }
 
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+   if (plane_id == PLANE_PRIMARY) {
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+   else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+!IS_GEMINILAKE(dev_priv))
+   return false;
+   } else if (plane_id >= PLANE_SPRITE0) {
+   if (plane_id == PLANE_CURSOR)
+   return false;
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+   if (plane_id != PLANE_SPRITE0)
+   return false;
+   } else {
+   if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+   IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+   }
+   }
+   return true;
+}
+
 static struct intel_plane *

[Intel-gfx] [PATCH v5 0/6] Enable NV12 support

2018-04-19 Thread Vidya Srinivas

Enabling NV12 support:
- Framebuffer creation
- Primary and Sprite plane support
Patch series depend on Enable display workaround 827 patch
mentioned below submitted by Maarten

Changes from prev version:
Removed BXT support for NV12 due to WA826

Chandra Konduru (3):
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Maarten Lankhorst (2):
  drm/i915: Enable display workaround 827 for all planes, v2.
  drm/i915: Add skl_check_nv12_surface for NV12

Vidya Srinivas (1):
  drm/i915: Enable Display WA 0528

 drivers/gpu/drm/i915/intel_atomic_plane.c |   7 +-
 drivers/gpu/drm/i915/intel_display.c  | 175 ++
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_sprite.c   |  44 +++-
 4 files changed, 203 insertions(+), 26 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v5 5/6] drm/i915: Enable Display WA 0528

2018-04-19 Thread Vidya Srinivas

Possible hang with NV12 plane surface formats.
WA: When the plane source pixel format is NV12,
the CHICKEN_PIPESL_* register bit 22 must be set to 1
and the render decompression must not be enabled
on any of the planes in that pipe.

v2: removed unnecessary POSTING_READ

v3: Added RB from Maarten

v4: Removed support for NV12 for BROXTON

Credits-to: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 641bf9e..3e1c26a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -505,9 +505,21 @@ static const struct intel_limit intel_limits_bxt = {
 };
 
 static void
+skl_wa_528(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return;
+
+   if (enable)
+   I915_WRITE(CHICKEN_PIPESL_1(pipe), HSW_FBCQ_DIS);
+   else
+   I915_WRITE(CHICKEN_PIPESL_1(pipe), 0);
+}
+
+static void
 skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
 {
-   if (IS_SKYLAKE(dev_priv))
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
return;
 
if (enable)
@@ -5205,8 +5217,10 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
 
/* Display WA 827 */
if (needs_nv12_wa(dev_priv, old_crtc_state) &&
-   !needs_nv12_wa(dev_priv, pipe_config))
+   !needs_nv12_wa(dev_priv, pipe_config)) {
skl_wa_clkgate(dev_priv, crtc->pipe, false);
+   skl_wa_528(dev_priv, crtc->pipe, false);
+   }
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5243,8 +5257,10 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
 
/* Display WA 827 */
if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
-   needs_nv12_wa(dev_priv, pipe_config))
+   needs_nv12_wa(dev_priv, pipe_config)) {
skl_wa_clkgate(dev_priv, crtc->pipe, true);
+   skl_wa_528(dev_priv, crtc->pipe, true);
+   }
 
/*
 * Vblank time updates from the shadow to live plane control register
-- 
2.7.4

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

[Intel-gfx] [PATCH v5 6/6] drm/i915: Add skl_check_nv12_surface for NV12

2018-04-19 Thread Vidya Srinivas

From: Maarten Lankhorst 

We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.

v2: For NV12, making the src coordinates multiplier of 4

v3: Moving all the src coords handling code for NV12
to skl_check_nv12_surface

v4: Added RB from Mika

Reviewed-by: Mika Kahola 
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 39 
 drivers/gpu/drm/i915/intel_sprite.c  | 15 ++
 2 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3e1c26a..dcbc70d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
return 0;
 }
 
+static int
+skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
+  struct intel_plane_state *plane_state)
+{
+   int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
+   int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
+
+   if (((plane_state->base.src_x >> 16) % 4) != 0 ||
+   ((plane_state->base.src_y >> 16) % 4) != 0 ||
+   ((plane_state->base.src_w >> 16) % 4) != 0 ||
+   ((plane_state->base.src_h >> 16) % 4) != 0) {
+   DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
+   return -EINVAL;
+   }
+
+   /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
+   if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
+   (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
+   DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
+ crtc_x2, crtc_y2,
+ crtc_state->pipe_src_w, crtc_state->pipe_src_h);
+   return -EINVAL;
+   }
+
+   plane_state->base.src.x1 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
+   plane_state->base.src.x2 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
+   plane_state->base.src.y1 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
+   plane_state->base.src.y2 =
+   DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
+
+   return 0;
+}
+
 static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -3201,6 +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
 * the main surface setup depends on it.
 */
if (fb->format->format == DRM_FORMAT_NV12) {
+   ret = skl_check_nv12_surface(crtc_state, plane_state);
+   if (ret)
+   return ret;
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 8b7947d..f9985fb 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane,
return vscale;
}
 
-   /* Make the source viewport size an exact multiple of the 
scaling factors. */
-   drm_rect_adjust_size(src,
-drm_rect_width(dst) * hscale - 
drm_rect_width(src),
-drm_rect_height(dst) * vscale - 
drm_rect_height(src));
+   if (fb->format->format != DRM_FORMAT_NV12) {
+   /*
+* Make the source viewport size
+* an exact multiple of the scaling factors
+*/
+   drm_rect_adjust_size(src,
+(drm_rect_width(dst) * hscale -
+ drm_rect_width(src)),
+(drm_rect_height(dst) * vscale -
+ drm_rect_height(src)));
+   }
 
drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
state->base.rotation);
-- 
2.7.4

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

[Intel-gfx] [PATCH] drm/i915: Add NV12 support to intel_framebuffer_init

2018-04-19 Thread Vidya Srinivas

From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

v11: Addressed review comments from Shashank Sharma

v12: Adding Reviewed By from Shashank Sharma

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Maarten.
Add checks for fb width height for NV12 and fail the fb
creation if check fails. Added reviewed by from
Juha-Pekka Heikkila

v15: Rebased the series

v16: Setting the minimum value during fb creating to 16
as per Bspec for NV12. Earlier minimum was expected
to be > 16. Now changed it to >=16.

v17: Adding restriction to framebuffer_init - the fb
width and height should be a multiplier of 4

v18: Added RB from Maarten. Included Maarten's review comments
Dont allow CCS formats for fb creation of NV12

v19: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826

Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dc9c424..356336c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14264,6 +14264,20 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS ||
+   mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS) {
+   DRM_DEBUG_KMS("RC not to be enabled with NV12\n");
+   goto err;
+   }
+   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv) ||
+   IS_BROXTON(dev_priv)) {
+   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+ 
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
+   goto err;
+   }
+   break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
@@ -14276,6 +14290,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 
drm_helper_mode_fill_fb_struct(_priv->drm, fb, mode_cmd);
 
+   if (fb->format->format == DRM_FORMAT_NV12 &&
+   (fb->width < SKL_MIN_YUV_420_SRC_W ||
+fb->height < SKL_MIN_YUV_420_SRC_H ||
+(fb->width % 4) != 0 || (fb->height % 4) != 0)) {
+   DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
+   return -EINVAL;
+   }
+
for (i = 0; i < fb->format->num_planes; i++) {
u32 stride_alignment;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v5 3/6] drm/i915: Add NV12 as supported format for sprite plane

2018-04-19 Thread Vidya Srinivas

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

v11: Addressed review comments from Shashank Sharma

v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.

v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported. These were
review comments from Kristian Høgsberg 

v15: Added reviewed by from Juha-Pekka Heikkila

v16: Rebased the series

v17: Added all tiling under mod supported for NV12
Credits to Megha Aggarwal

v18: Added RB by Maarten and Kristian

Credits-to: Megha Aggarwal 
Credits-to: Kristian Høgsberg 
Reviewed-by: Kristian Høgsberg 
Reviewed-by: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aa1dfaa..8b7947d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1253,6 +1253,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static uint32_t skl_planar_formats[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1350,6 +1363,12 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
+   case DRM_FORMAT_NV12:
+   if (modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED ||
+   modifier == I915_FORMAT_MOD_Yf_TILED)
+   return true;
case DRM_FORMAT_C8:
if (modifier == DRM_FORMAT_MOD_LINEAR ||
modifier == I915_FORMAT_MOD_X_TILED ||
@@ -1446,8 +1465,14 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
 
-   plane_formats = skl_plane_formats;
-   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+   plane_formats = skl_planar_formats;
+   num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+   } else {
+

[Intel-gfx] [PATCH v5 2/6] drm/i915: Add NV12 as supported format for primary plane

2018-04-19 Thread Vidya Srinivas

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

v5: Rebased (me)

v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)

v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.

v11: Adding Reviewed By tag from Shashank Sharma

v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported. These were review comments
from Kristian Høgsberg 

v14: Added reviewed by from Juha-Pekka Heikkila

v15: Rebased the series

v16: Added all tiling support under mod supported
for NV12. Credits to Megha Aggarwal

v17: Added RB by Maarten and Kristian

v18: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826

Credits-to: Megha Aggarwal megha.aggar...@intel.com
Credits-to: Maarten Lankhorst 
Tested-by: Clinton Taylor 
Reviewed-by: Kristian Høgsberg 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 55 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 53f82fa..dc9c424 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t skl_pri_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13127,6 +13143,12 @@ static bool skl_mod_supported(uint32_t format, 
uint64_t modifier)
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
+   case DRM_FORMAT_NV12:
+   if (modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED ||
+   modifier == I915_FORMAT_MOD_Yf_TILED)
+   return true;
case DRM_FORMAT_C8:
if (modifier == DRM_FORMAT_MOD_LINEAR ||
modifier == I915_FORMAT_MOD_X_TILED ||
@@ -13331,6 +13353,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private 
*dev_priv,
return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
 }
 
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+   if (plane_id == PLANE_PRIMARY) {
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+   else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+!IS_GEMINILAKE(dev_priv))
+   return false;
+   } else if (plane_id >= PLANE_SPRITE0) {
+   if (plane_id == PLANE_CURSOR)
+   return false;
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+   if (plane_id != PLANE_SPRITE0)
+   return false;
+   } else {
+   if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+   IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+   }
+   }
+   return true;
+}
+
 static struct intel_plane *

[Intel-gfx] [PATCH v5 1/6] drm/i915: Enable display workaround 827 for all planes, v2.

2018-04-19 Thread Vidya Srinivas

From: Maarten Lankhorst 

The workaround was applied only to the primary plane, but is required
on all planes. Iterate over all planes in the crtc atomic check to see
if the workaround is enabled, and only perform the actual toggling in
the pre/post plane update functions.

Changes since v1:
- Track active NV12 planes in a nv12_planes bitmask. (Ville)

v2: Removing BROXTON support for NV12 due to WA826

Signed-off-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  7 -
 drivers/gpu/drm/i915/intel_display.c  | 43 +++
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 3 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce8..6d06878 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -183,11 +183,16 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
}
 
/* FIXME pre-g4x don't work like this */
-   if (intel_state->base.visible)
+   if (state->visible)
crtc_state->active_planes |= BIT(intel_plane->id);
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
 
+   if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+   crtc_state->nv12_planes |= BIT(intel_plane->id);
+   else
+   crtc_state->nv12_planes &= ~BIT(intel_plane->id);
+
return intel_plane_atomic_calc_changes(old_crtc_state,
   _state->base,
   old_plane_state,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 020900e..53f82fa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5138,6 +5138,22 @@ static bool hsw_post_update_enable_ips(const struct 
intel_crtc_state *old_crtc_s
return !old_crtc_state->ips_enabled;
 }
 
+static bool needs_nv12_wa(struct drm_i915_private *dev_priv,
+ const struct intel_crtc_state *crtc_state)
+{
+   if (!crtc_state->nv12_planes)
+   return false;
+
+   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+   return false;
+
+   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+  IS_CANNONLAKE(dev_priv))
+   return true;
+
+   return false;
+}
+
 static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
@@ -5162,7 +5178,6 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
if (old_primary_state) {
struct drm_plane_state *new_primary_state =
drm_atomic_get_new_plane_state(old_state, primary);
-   struct drm_framebuffer *fb = new_primary_state->fb;
 
intel_fbc_post_update(crtc);
 
@@ -5170,15 +5185,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
(needs_modeset(_config->base) ||
 !old_primary_state->visible))
intel_post_enable_primary(>base, pipe_config);
-
-   /* Display WA 827 */
-   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-   IS_CANNONLAKE(dev_priv)) {
-   if (fb && fb->format->format == DRM_FORMAT_NV12)
-   skl_wa_clkgate(dev_priv, crtc->pipe, false);
-   }
-
}
+
+   /* Display WA 827 */
+   if (needs_nv12_wa(dev_priv, old_crtc_state) &&
+   !needs_nv12_wa(dev_priv, pipe_config))
+   skl_wa_clkgate(dev_priv, crtc->pipe, false);
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5202,14 +5214,6 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
struct intel_plane_state *new_primary_state =
intel_atomic_get_new_plane_state(old_intel_state,
 
to_intel_plane(primary));
-   struct drm_framebuffer *fb = new_primary_state->base.fb;
-
-   /* Display WA 827 */
-   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-   IS_CANNONLAKE(dev_priv)) {
-   if (fb && fb->format->format == DRM_FORMAT_NV12)
-   skl_wa_clkgate(dev_priv, crtc->pipe, true);
-   }
 
intel_fbc_pre_update(crtc, pipe_config,

[Intel-gfx] [PATCH v5 0/6] Enable NV12 support

2018-04-19 Thread Vidya Srinivas

Enabling NV12 support:
- Framebuffer creation
- Primary and Sprite plane support
Patch series depend on Enable display workaround 827 patch
mentioned below submitted by Maarten

Changes from prev version:
Removed BXT support for NV12 due to WA826

Chandra Konduru (3):
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Maarten Lankhorst (2):
  drm/i915: Enable display workaround 827 for all planes, v2.
  drm/i915: Add skl_check_nv12_surface for NV12

Vidya Srinivas (1):
  drm/i915: Enable Display WA 0528

 drivers/gpu/drm/i915/intel_atomic_plane.c |   7 +-
 drivers/gpu/drm/i915/intel_display.c  | 175 ++
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_sprite.c   |  44 +++-
 4 files changed, 203 insertions(+), 26 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [PULL] gvt-next for 4.17

2018-04-19 Thread Zhi Wang

Weird. I try to apply the patches one by one on 
drm-intel-next-2018-04-13. I didn't get any conflicts... Let me dig more..


On 04/19/18 17:50, Zhi Wang wrote:
Thanks, Let me discuss with Zhenyu about how to deal with this. It must 
be the git rebase I've done which causes the commiter change without new 
signoff-by.


Thanks,
Zhi.

On 04/19/18 17:34, Jani Nikula wrote:

On Thu, 19 Apr 2018, Zhi Wang  wrote:

Hi:

Here is the pull request of gvt-next for 4.17 with some new features and
optimizations.

Thanks,
Zhi.

--
The following changes since commit 
fadec6eefe232696c5c471b40df33e6db616e854:


drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)

are available in the git repository at:

https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-19

for you to fetch changes up to c0fb4098fc47dcaeb47085c08d8fafa42fa8e471:

drm/i915/gvt: Mark expected switch fall-through in
handle_g2v_notification (2018-04-19 16:35:55 +0800)


- Minor condition check improvment (Gustavo A. R. Silva)
- Reverting GVT context priority hack (Weinan Li)
- Non-priviliged batch buffer scan (Yan Zhao)
- Scheduling optimizations (Zhipeng Gong)


Gustavo A. R. Silva (2):
drm/i915/gvt/scheduler: Remove unnecessary NULL checks in 
sr_oa_regs

drm/i915/gvt: Mark expected switch fall-through in
handle_g2v_notification

Weinan Li (1):
Revert "drm/i915/gvt: set max priority for gvt context"


This reverts a commit in v4.15. Why is it in a -next pull and not a
-fixes pull?

It also conflicts, please advise how to resolve:

diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
index f3d21849b0cb,080fb5027d9c..
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -1134,9 -1156,6 +1156,12 @@@ int intel_vgpu_setup_submission(struct
 if (IS_ERR(s->shadow_ctx))
 return PTR_ERR(s->shadow_ctx);
++<<< HEAD
  +  if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
  +  s->shadow_ctx->sched.priority = INT_MAX;
  +
++===
++>>> c2f6410ef67740ebcbf5d92dffc2679d4a0e288c
 bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
 s->workloads = kmem_cache_create_usercopy("gvt-g_vgpu_workload",

Finally, it's committed by Zhi Wang  but without
his Signed-off-by.


BR,
Jani.




Zhao Yan (1):
drm/i915/gvt: scan non-privileged batch buffer for debug purpose

Zhipeng Gong (2):
drm/i915/gvt: Use real time to do timer check
drm/i915/gvt: Update time slice more frequently

   drivers/gpu/drm/i915/gvt/cmd_parser.c   | 55 
+++---

   drivers/gpu/drm/i915/gvt/debugfs.c  | 67

   drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
   drivers/gpu/drm/i915/gvt/handlers.c |  1 +
   drivers/gpu/drm/i915/gvt/sched_policy.c | 31 ---
   drivers/gpu/drm/i915/gvt/scheduler.c| 69
+
   drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
   drivers/gpu/drm/i915/gvt/trace.h| 24 +---
   8 files changed, 193 insertions(+), 56 deletions(-)



___
intel-gvt-dev mailing list
intel-gvt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Enabling content-type setting for HDMI displays. (rev3)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev3)
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4068 -> Patchwork_8749 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/3/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8749 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@gem_exec_suspend@basic-s3:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (34 -> 32) ==

  Additional (1): fi-glk-1 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4068 -> Patchwork_8749

  CI_DRM_4068: 28fecc12e5c2b1beb9ab89e3616266d5d5e58e3d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8749: 67311c808659d0d83a5ca6b844f72fdd9d4b47d4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

67311c808659 i915: content-type property for HDMI connector
859e0b2e808c drm: content-type property for HDMI connector

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8749/issues.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 Enabling content-type setting for HDMI displays. (rev2)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev2)
URL   : https://patchwork.freedesktop.org/series/41876/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4067_full -> Patchwork_8747_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8747_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8747_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8747_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  SKIP -> PASS +2

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +4

igt@kms_vblank@pipe-a-wait-busy:
  shard-snb:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_8747_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_flip@basic-flip-vs-wf_vblank:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip@flip-vs-modeset-vs-hang-interruptible:
  shard-kbl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558, 
fdo#103313) +1

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)

igt@kms_vblank@pipe-a-accuracy-idle:
  shard-hsw:  PASS -> FAIL (fdo#102583)

igt@pm_rpm@basic-pci-d3-state:
  shard-kbl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558) +2


 Possible fixes 

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-apl:  FAIL (fdo#100368) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023


== Participating hosts (6 -> 4) ==

  Missing(2): shard-glk shard-glkb 


== Build changes ==

* Linux: CI_DRM_4067 -> Patchwork_8747

  CI_DRM_4067: 1c7ccdf37b04bedb10e2191d34dfbba62beb79ea @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8747: 9829fc99304f4e832c5ae1daf41f1a940b0ebf74 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PULL] gvt-next for 4.17

2018-04-19 Thread Zhenyu Wang

On 2018.04.19 12:34:16 +0300, Jani Nikula wrote:
> On Thu, 19 Apr 2018, Zhi Wang  wrote:
> > Hi:
> >
> > Here is the pull request of gvt-next for 4.17 with some new features and 
> > optimizations.
> >
> > Thanks,
> > Zhi.
> >
> > --
> > The following changes since commit fadec6eefe232696c5c471b40df33e6db616e854:
> >
> >drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)
> >
> > are available in the git repository at:
> >
> >https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-19
> >
> > for you to fetch changes up to c0fb4098fc47dcaeb47085c08d8fafa42fa8e471:
> >
> >drm/i915/gvt: Mark expected switch fall-through in 
> > handle_g2v_notification (2018-04-19 16:35:55 +0800)
> >
> > 
> > - Minor condition check improvment (Gustavo A. R. Silva)
> > - Reverting GVT context priority hack (Weinan Li)
> > - Non-priviliged batch buffer scan (Yan Zhao)
> > - Scheduling optimizations (Zhipeng Gong)
> >
> > 
> > Gustavo A. R. Silva (2):
> >drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
> >drm/i915/gvt: Mark expected switch fall-through in 
> > handle_g2v_notification
> >
> > Weinan Li (1):
> >Revert "drm/i915/gvt: set max priority for gvt context"
> 
> This reverts a commit in v4.15. Why is it in a -next pull and not a
> -fixes pull?

This one was originally queued for 4.17 in gvt-next-fixes, but declined as
Joonas thought this is new feature as enabling vGPU priority scheduling,
https://lists.freedesktop.org/archives/intel-gfx/2018-March/160431.html

> 
> It also conflicts, please advise how to resolve:
> 
> diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
> index f3d21849b0cb,080fb5027d9c..
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@@ -1134,9 -1156,6 +1156,12 @@@ int intel_vgpu_setup_submission(struct 
> if (IS_ERR(s->shadow_ctx))
> return PTR_ERR(s->shadow_ctx);
>   
> ++<<< HEAD
>  +  if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
>  +  s->shadow_ctx->sched.priority = INT_MAX;
>  +
> ++===
> ++>>> c2f6410ef67740ebcbf5d92dffc2679d4a0e288c
> bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
>   
> s->workloads = kmem_cache_create_usercopy("gvt-g_vgpu_workload",
> 
> Finally, it's committed by Zhi Wang  but without
> his Signed-off-by.
> 
> 
> BR,
> Jani.
> 
> 
> >
> > Zhao Yan (1):
> >drm/i915/gvt: scan non-privileged batch buffer for debug purpose
> >
> > Zhipeng Gong (2):
> >drm/i915/gvt: Use real time to do timer check
> >drm/i915/gvt: Update time slice more frequently
> >
> >   drivers/gpu/drm/i915/gvt/cmd_parser.c   | 55 +++---
> >   drivers/gpu/drm/i915/gvt/debugfs.c  | 67 
> > 
> >   drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
> >   drivers/gpu/drm/i915/gvt/handlers.c |  1 +
> >   drivers/gpu/drm/i915/gvt/sched_policy.c | 31 ---
> >   drivers/gpu/drm/i915/gvt/scheduler.c| 69 
> > +
> >   drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
> >   drivers/gpu/drm/i915/gvt/trace.h| 24 +---
> >   8 files changed, 193 insertions(+), 56 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

Re: [Intel-gfx] [PULL] gvt-next for 4.17

2018-04-19 Thread Zhi Wang

Thanks, Let me discuss with Zhenyu about how to deal with this. It must 
be the git rebase I've done which causes the commiter change without new 
signoff-by.


Thanks,
Zhi.

On 04/19/18 17:34, Jani Nikula wrote:

On Thu, 19 Apr 2018, Zhi Wang  wrote:

Hi:

Here is the pull request of gvt-next for 4.17 with some new features and
optimizations.

Thanks,
Zhi.

--
The following changes since commit fadec6eefe232696c5c471b40df33e6db616e854:

drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)

are available in the git repository at:

https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-19

for you to fetch changes up to c0fb4098fc47dcaeb47085c08d8fafa42fa8e471:

drm/i915/gvt: Mark expected switch fall-through in
handle_g2v_notification (2018-04-19 16:35:55 +0800)


- Minor condition check improvment (Gustavo A. R. Silva)
- Reverting GVT context priority hack (Weinan Li)
- Non-priviliged batch buffer scan (Yan Zhao)
- Scheduling optimizations (Zhipeng Gong)


Gustavo A. R. Silva (2):
drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
drm/i915/gvt: Mark expected switch fall-through in
handle_g2v_notification

Weinan Li (1):
Revert "drm/i915/gvt: set max priority for gvt context"


This reverts a commit in v4.15. Why is it in a -next pull and not a
-fixes pull?

It also conflicts, please advise how to resolve:

diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
index f3d21849b0cb,080fb5027d9c..
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -1134,9 -1156,6 +1156,12 @@@ int intel_vgpu_setup_submission(struct
 if (IS_ERR(s->shadow_ctx))
 return PTR_ERR(s->shadow_ctx);
   
++<<< HEAD

  +  if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
  +  s->shadow_ctx->sched.priority = INT_MAX;
  +
++===
++>>> c2f6410ef67740ebcbf5d92dffc2679d4a0e288c
 bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
   
 s->workloads = kmem_cache_create_usercopy("gvt-g_vgpu_workload",


Finally, it's committed by Zhi Wang  but without
his Signed-off-by.


BR,
Jani.




Zhao Yan (1):
drm/i915/gvt: scan non-privileged batch buffer for debug purpose

Zhipeng Gong (2):
drm/i915/gvt: Use real time to do timer check
drm/i915/gvt: Update time slice more frequently

   drivers/gpu/drm/i915/gvt/cmd_parser.c   | 55 +++---
   drivers/gpu/drm/i915/gvt/debugfs.c  | 67

   drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
   drivers/gpu/drm/i915/gvt/handlers.c |  1 +
   drivers/gpu/drm/i915/gvt/sched_policy.c | 31 ---
   drivers/gpu/drm/i915/gvt/scheduler.c| 69
+
   drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
   drivers/gpu/drm/i915/gvt/trace.h| 24 +---
   8 files changed, 193 insertions(+), 56 deletions(-)



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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enabling content-type setting for HDMI displays. (rev3)

2018-04-19 Thread Patchwork

== Series Details ==

Series: Enabling content-type setting for HDMI displays. (rev3)
URL   : https://patchwork.freedesktop.org/series/41876/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
859e0b2e808c drm: content-type property for HDMI connector
-:92: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#92: FILE: drivers/gpu/drm/drm_connector.c:1017:
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.content_type_property,

-:122: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#122: FILE: drivers/gpu/drm/drm_connector.c:1304:
+   drm_property_create_enum(dev, 0, "content type",
+   drm_content_type_enum_list,

-:125: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"!dev->mode_config.content_type_property"
#125: FILE: drivers/gpu/drm/drm_connector.c:1307:
+   if (dev->mode_config.content_type_property == NULL)

total: 0 errors, 0 warnings, 3 checks, 172 lines checked
67311c808659 i915: content-type property for HDMI connector

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

[Intel-gfx] [PATCH v4 2/2] i915: content-type property for HDMI connector

2018-04-19 Thread StanLis

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from
drm_connector_state within AVI infoframe in order to properly handle
external HDMI TV content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c | 2 ++
 drivers/gpu/drm/i915/intel_hdmi.c   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..96a42eb457c5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
+   new_conn_state->base.it_content != old_conn_state->base.it_content 
||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..078200908b7a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   frame.avi.content_type = connector->state->content_type;
+   frame.avi.itc = connector->state->it_content;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+   drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 }
 
-- 
2.17.0

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

[Intel-gfx] [PATCH v4 0/2] Enabling content-type setting for HDMI displays.

2018-04-19 Thread StanLis

From: Stanislav Lisovskiy 

Rev 1:
Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Rev 2:
Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.

Rev 3:
Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.

Rev 4:
Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c|  4 +++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 9 files changed, 107 insertions(+)

-- 
2.17.0

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

[Intel-gfx] [PATCH v4 1/2] drm: content-type property for HDMI connector

2018-04-19 Thread StanLis

From: Stanislav Lisovskiy 

Added content_type  property to
drm_connector_state in order to properly handle
external HDMI TV content-type setting.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 7 files changed, 101 insertions(+)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..a91c9211b8d6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   state->content_type = val & 3;
+   state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
+   { DRM_MODE_CONTENT_TYPE_NO_DATA, "No data" },
+   { DRM_MODE_CONTENT_TYPE_GRAPHICS, "Graphics" },
+   { DRM_MODE_CONTENT_TYPE_PHOTO, "Photo" },
+   { DRM_MODE_CONTENT_TYPE_CINEMA, "Cinema" },
+   { DRM_MODE_CONTENT_TYPE_GAME, "Game" },
+};
+
 static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
@@ -996,6 +1004,22 @@ int drm_mode_create_dvi_i_properties(struct drm_device 
*dev)
 }
 EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
 
+/**
+ * drm_connector_attach_content_type_property - attach content-type property
+

Re: [Intel-gfx] [PULL] gvt-next for 4.17

2018-04-19 Thread Jani Nikula

On Thu, 19 Apr 2018, Zhi Wang  wrote:
> Hi:
>
> Here is the pull request of gvt-next for 4.17 with some new features and 
> optimizations.
>
> Thanks,
> Zhi.
>
> --
> The following changes since commit fadec6eefe232696c5c471b40df33e6db616e854:
>
>drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)
>
> are available in the git repository at:
>
>https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-19
>
> for you to fetch changes up to c0fb4098fc47dcaeb47085c08d8fafa42fa8e471:
>
>drm/i915/gvt: Mark expected switch fall-through in 
> handle_g2v_notification (2018-04-19 16:35:55 +0800)
>
> 
> - Minor condition check improvment (Gustavo A. R. Silva)
> - Reverting GVT context priority hack (Weinan Li)
> - Non-priviliged batch buffer scan (Yan Zhao)
> - Scheduling optimizations (Zhipeng Gong)
>
> 
> Gustavo A. R. Silva (2):
>drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
>drm/i915/gvt: Mark expected switch fall-through in 
> handle_g2v_notification
>
> Weinan Li (1):
>Revert "drm/i915/gvt: set max priority for gvt context"

This reverts a commit in v4.15. Why is it in a -next pull and not a
-fixes pull?

It also conflicts, please advise how to resolve:

diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
index f3d21849b0cb,080fb5027d9c..
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -1134,9 -1156,6 +1156,12 @@@ int intel_vgpu_setup_submission(struct 
if (IS_ERR(s->shadow_ctx))
return PTR_ERR(s->shadow_ctx);
  
++<<< HEAD
 +  if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
 +  s->shadow_ctx->sched.priority = INT_MAX;
 +
++===
++>>> c2f6410ef67740ebcbf5d92dffc2679d4a0e288c
bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
  
s->workloads = kmem_cache_create_usercopy("gvt-g_vgpu_workload",

Finally, it's committed by Zhi Wang  but without
his Signed-off-by.


BR,
Jani.


>
> Zhao Yan (1):
>drm/i915/gvt: scan non-privileged batch buffer for debug purpose
>
> Zhipeng Gong (2):
>drm/i915/gvt: Use real time to do timer check
>drm/i915/gvt: Update time slice more frequently
>
>   drivers/gpu/drm/i915/gvt/cmd_parser.c   | 55 +++---
>   drivers/gpu/drm/i915/gvt/debugfs.c  | 67 
> 
>   drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
>   drivers/gpu/drm/i915/gvt/handlers.c |  1 +
>   drivers/gpu/drm/i915/gvt/sched_policy.c | 31 ---
>   drivers/gpu/drm/i915/gvt/scheduler.c| 69 
> +
>   drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
>   drivers/gpu/drm/i915/gvt/trace.h| 24 +---
>   8 files changed, 193 insertions(+), 56 deletions(-)

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

[Intel-gfx] [PULL] drm-intel-next-fixes

2018-04-19 Thread Joonas Lahtinen

Hi Dave,

I was travelling last week, and thought you wouldn't be back until this week,
but you were :) So, my PR is against older drm-next for that I don't want to
make GVT folks redo their PR twice.

It's looking good on CI. Biggest things are the fix to be tolerant against bad
BIOSes (FDO #105549) and fix on GVT regression.

Next week should be a normal PR, then!

Regards, Joonas

drm-intel-next-fixes-2018-04-19:
- Fix for FDO #105549: Avoid OOPS on bad VBT (Jani)
- Fix rare pre-emption race (Chris)
- Fix RC6 race against PM transitions (Tvrtko)

gvt-fixes-2018-04-03

- fix unhandled vfio ioctl return value (Gerd)
- no-op user interrupt for vGPU (Zhipeng)
- fix ggtt dma unmap (Changbin)
- fix warning in fb decoder (Xiong)
- dmabuf drm_format_mod fix (Tina)
- misc cleanup

The following changes since commit 694f54f680f7fd8e9561928fbfc537d9afbc3d79:

  Merge branch 'drm-misc-next-fixes' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-03-29 09:25:13 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2018-04-19

for you to fetch changes up to b4615730530be85fc45ab4631c2ad6d8e2d0b97d:

  drm/i915/audio: Fix audio detection issue on GLK (2018-04-18 14:26:15 +0300)


- Fix for FDO #105549: Avoid OOPS on bad VBT (Jani)
- Fix rare pre-emption race (Chris)
- Fix RC6 race against PM transitions (Tvrtko)


Changbin Du (2):
  drm/i915/gvt: Missed to cancel dma map for ggtt entries
  drm/i915/gvt: Cancel dma map when resetting ggtt entries

Chris Wilson (2):
  drm/i915/execlists: Clear user-active flag on preemption completion
  drm/i915: Call i915_perf_fini() on init_hw error unwind

Gaurav K Singh (1):
  drm/i915/audio: Fix audio detection issue on GLK

Gerd Hoffmann (1):
  drm/i915/gvt: throw error on unhandled vfio ioctls

Gustavo A. R. Silva (1):
  drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification

Jani Nikula (1):
  drm/i915/bios: filter out invalid DDC pins from VBT child devices

Joonas Lahtinen (1):
  Merge tag 'gvt-fixes-2018-04-03' of https://github.com/intel/gvt-linux 
into drm-intel-next-fixes

Tina Zhang (1):
  drm/i915/gvt: Add drm_format_mod update

Tvrtko Ursulin (1):
  drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6

Xidong Wang (1):
  drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value

Xiong Zhang (2):
  drm/i915/gvt: Delete redundant error message in fb_decode.c
  drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
initialization

Zhipeng Gong (1):
  drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser

 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  1 +
 drivers/gpu/drm/i915/gvt/display.c | 10 ++
 drivers/gpu/drm/i915/gvt/dmabuf.c  |  1 +
 drivers/gpu/drm/i915/gvt/fb_decoder.c  | 27 ++--
 drivers/gpu/drm/i915/gvt/gtt.c | 52 ++
 drivers/gpu/drm/i915/gvt/gtt.h |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c|  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.c| 27 +---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_pmu.c| 37 +++--
 drivers/gpu/drm/i915/intel_audio.c |  2 +-
 drivers/gpu/drm/i915/intel_bios.c  | 13 +---
 drivers/gpu/drm/i915/intel_lrc.c   |  9 ++
 14 files changed, 131 insertions(+), 55 deletions(-)

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsi: improve dphy param limits logging

2018-04-19 Thread Ville Syrjälä

On Thu, Apr 19, 2018 at 11:59:39AM +0300, Jani Nikula wrote:
> Move the limit checks near the calculations for each field, and actually
> log the values that exceed limits.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 34 ++
>  1 file changed, 18 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index 91c07b0c8db9..4d6ffa7b3e7b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -647,6 +647,11 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
> panel_id)
>   /* prepare count */
>   prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * mul);
>  
> + if (prepare_cnt > PREPARE_CNT_MAX) {
> + DRM_DEBUG_KMS("prepare count too high %u\n", prepare_cnt);
> + prepare_cnt = PREPARE_CNT_MAX;
> + }
> +
>   /* exit zero count */
>   exit_zero_cnt = DIV_ROUND_UP(
>   (ths_prepare_hszero - ths_prepare_ns) * ui_den,
> @@ -662,32 +667,29 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, 
> u16 panel_id)
>   if (exit_zero_cnt < (55 * ui_den / ui_num) && (55 * ui_den) % ui_num)
>   exit_zero_cnt += 1;
>  
> + if (exit_zero_cnt > EXIT_ZERO_CNT_MAX) {
> + DRM_DEBUG_KMS("exit zero count too high %u\n", exit_zero_cnt);
> + exit_zero_cnt = EXIT_ZERO_CNT_MAX;
> + }
> +
>   /* clk zero count */
>   clk_zero_cnt = DIV_ROUND_UP(
>   (tclk_prepare_clkzero - ths_prepare_ns)
>   * ui_den, ui_num * mul);
>  
> + if (clk_zero_cnt > CLK_ZERO_CNT_MAX) {
> + DRM_DEBUG_KMS("clock zero count too high %u\n", clk_zero_cnt);
> + clk_zero_cnt = CLK_ZERO_CNT_MAX;
> + }
> +
>   /* trail count */
>   tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
>   trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, ui_num * mul);
>  
> - if (prepare_cnt > PREPARE_CNT_MAX ||
> - exit_zero_cnt > EXIT_ZERO_CNT_MAX ||
> - clk_zero_cnt > CLK_ZERO_CNT_MAX ||
> - trail_cnt > TRAIL_CNT_MAX)
> - DRM_DEBUG_DRIVER("Values crossing maximum limits, restricting 
> to max values\n");
> -
> - if (prepare_cnt > PREPARE_CNT_MAX)
> - prepare_cnt = PREPARE_CNT_MAX;
> -
> - if (exit_zero_cnt > EXIT_ZERO_CNT_MAX)
> - exit_zero_cnt = EXIT_ZERO_CNT_MAX;
> -
> - if (clk_zero_cnt > CLK_ZERO_CNT_MAX)
> - clk_zero_cnt = CLK_ZERO_CNT_MAX;
> -
> - if (trail_cnt > TRAIL_CNT_MAX)
> + if (trail_cnt > TRAIL_CNT_MAX) {
> + DRM_DEBUG_KMS("trail count too high %u\n", trail_cnt);
>   trail_cnt = TRAIL_CNT_MAX;
> + }
>  
>   /* B080 */
>   intel_dsi->dphy_reg = exit_zero_cnt << 24 | trail_cnt << 16 |
> -- 
> 2.11.0

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

1 2 >

1 - 100 of 130 matches

Mail list logo