Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/uc: Create intel_uc_init_mmio

[Sagar Arun Kamble]

On 10/2/2017 7:31 PM, Michal Wajdeczko wrote:

From: Sagar Arun Kamble 

This patch adds new function intel_uc_init_mmio which will initialize
MMIO access related variables prior to uc load/init.

v2: Removed unnecessary export of guc_send_init_regs. Created
intel_uc_init_mmio that currently wraps guc_init_send_regs. (Michal)

Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Michal Wajdeczko 

Looks good to me.
Acked-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_drv.c | 2 ++
  drivers/gpu/drm/i915/intel_uc.c | 7 +--
  drivers/gpu/drm/i915/intel_uc.h | 1 +
  3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5cc2434..74a456f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1007,6 +1007,8 @@ static int i915_driver_init_mmio(struct drm_i915_private 
*dev_priv)
  
  	intel_uncore_init(dev_priv);
  
+	intel_uc_init_mmio(dev_priv);

+
ret = intel_engines_init_mmio(dev_priv);
if (ret)
goto err_uncore;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 201d23e..d921509 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -137,6 +137,11 @@ static void guc_init_send_regs(struct intel_guc *guc)
guc->send_regs.fw_domains = fw_domains;
  }
  
+void intel_uc_init_mmio(struct drm_i915_private *dev_priv)

+{
+   guc_init_send_regs(_priv->guc);
+}
+
  static void guc_capture_load_err_log(struct intel_guc *guc)
  {
if (!guc->log.vma || i915_modparams.guc_log_level < 0)
@@ -158,8 +163,6 @@ static int guc_enable_communication(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
  
-	guc_init_send_regs(guc);

-
if (HAS_GUC_CT(dev_priv))
return intel_guc_enable_ct(guc);
  
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h

index d111f79..f0d5a3f 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -137,6 +137,7 @@ struct intel_huc {
  /* intel_uc.c */
  void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
  void intel_uc_init_early(struct drm_i915_private *dev_priv);
+void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
  void intel_uc_init_fw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
  int intel_uc_init_hw(struct drm_i915_private *dev_priv);


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

Re: [Intel-gfx] [dim PATCH] dim: note the testing tag in the drm-intel-testing mail

[Jani Nikula]

On Mon, 02 Oct 2017, Joonas Lahtinen  wrote:
> On Mon, 2017-10-02 at 12:24 +0300, Jani Nikula wrote:
>> Signed-off-by: Jani Nikula 
>
> Yay :)
>
> Reviewed-by: Joonas Lahtinen 

Pushed, thanks.

Jani.

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

Re: [Intel-gfx] [dim PATCH] dim: use git ls-files file matching instead of grep

[Jani Nikula]

On Mon, 02 Oct 2017, Joonas Lahtinen  wrote:
> On Mon, 2017-10-02 at 12:23 +0300, Jani Nikula wrote:
>> Avoid extra pipelines for no good reason.
>> 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Joonas Lahtinen 

Pushed, thanks.

Jani.

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.

[Jani Nikula]

On Mon, 02 Oct 2017, Rodrigo Vivi  wrote:
> On Mon, Oct 02, 2017 at 01:02:28PM +, Jani Nikula wrote:
>> On Thu, 28 Sep 2017, Rodrigo Vivi  wrote:
>> > Let's organize this in a way that it gets more obvious
>> > when looking to the platform colors and in a easier
>> > way to get inherited.
>> >
>> > Signed-off-by: Rodrigo Vivi 
>> > ---
>> >  drivers/gpu/drm/i915/i915_pci.c | 6 --
>> >  1 file changed, 4 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
>> > b/drivers/gpu/drm/i915/i915_pci.c
>> > index 9b54aafa2a0b..10537dcdd9c1 100644
>> > --- a/drivers/gpu/drm/i915/i915_pci.c
>> > +++ b/drivers/gpu/drm/i915/i915_pci.c
>> > @@ -54,6 +54,8 @@
>> >.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
>> >  #define CHV_COLORS \
>> >.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
>> > +#define GLK_COLORS \
>> > +  .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
>> >  
>> >  /* Keep in gen based order, and chronological order within a gen */
>> >  #define GEN2_FEATURES \
>> > @@ -495,7 +497,7 @@ static const struct intel_device_info 
>> > intel_geminilake_info __initconst = {
>> >GEN9_LP_FEATURES,
>> >.platform = INTEL_GEMINILAKE,
>> >.ddb_size = 1024,
>> > -  .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
>> > +  GLK_COLORS
>> 
>> Please add he comma at the end.
>> 
>> >  };
>> >  
>> >  #define KBL_PLATFORM \
>> > @@ -543,7 +545,7 @@ static const struct intel_device_info 
>> > intel_coffeelake_gt3_info __initconst = {
>> >  #define GEN10_FEATURES \
>> >GEN9_FEATURES, \
>> >.ddb_size = 1024, \
>> > -  .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
>> > +  GLK_COLORS
>
> this one here doesn't compile. it is inside a define...
>
> So, I have a:
> "v2: Add comma at the end (Jani), when possible." here

Oops, yeah, only when applicable. :)

BR,
Jani.


>
> but I'm not sure about that since comma here is not really needed, also it 
> wasn't there with the .color
> and it is not symmetric anymore...
>
>> 
>> Ditto.
>> 
>> BR,
>> Jani.
>> 
>> >  
>> >  static const struct intel_device_info intel_cannonlake_gt2_info 
>> > __initconst = {
>> >GEN10_FEATURES,
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center

-- 
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 4/4] drm/i915: Extend WaDisableIPC to all platforms.

[Mahesh Kumar]

Hi,

sorry for late reply, it was India site holiday.

On Friday 29 September 2017 12:42 AM, Rodrigo Vivi wrote:

On Thu, Sep 28, 2017 at 07:02:59PM +, Chris Wilson wrote:

Quoting Rodrigo Vivi (2017-09-28 19:51:48)

Although Bspec state this Workaround is only relevant for SKL:All.

The wa_database state this is needed for All platforms from SKL to CNL.

So let's pick the safest case.

Cc: Mahesh Kumar 
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ede871b7982e..27f9d5ab2d23 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5828,8 +5828,8 @@ void intel_enable_ipc(struct drm_i915_private *dev_priv)
  {
 u32 val;
  
-   /* Display WA #0477 WaDisableIPC: skl */

-   if (IS_SKYLAKE(dev_priv)) {
+   /* Display WA #0477 WaDisableIPC: skl,kbl,bxt,glk,cfl,cnl */
+   if (INTEL_GEN(dev_priv) <= 10) {
WA #0477 asks us to disable IPC for SKL:ALL, for all other GEN9 variant 
it should be enabled.
Enabling IPC improves performance of other memory clients, as without 
IPC enabled display always fetches from memory with High-priority.


-Mahesh

But at that point, why not just define has_ipc as a gen10 feature?

it's already there...


You
can have a comment before gen9 feature that although IPC was introduced
for gen9, it is recommended (w/a) to leave disabled.

so you mean moving this Wa from here to set has_ipc = 0 to all platforms?

Anyways I'd like to hear from Manesh about it since this basically revert
all IPC work for all platforms...


-Chris


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC.

[Mahesh Kumar]

Hi,


On Friday 29 September 2017 12:21 AM, Rodrigo Vivi wrote:

According to Spec for SKL+: "Isochronous Priority Control.
If enabled, Display sends demoted requests once the transition
watermark is reached. If transition watermark is not enabled,
Display sends demoted requests when the display buffer is full."

The commit 'e57f1c02155f ("drm/i915/gen9+: Add has_ipc flag in
device info structure")' introduced that as gen9+ but missing many
SKL Skus.

I believe the reason for that is Spec also mentions workarounds for
SKL-ALL: "IPC (Isoch Priority Control) may cause underflows
WA: Do not enable IPC in register ARB_CTL2"

yes, it was intentional as you correctly pointed out WA #0477.


It seems lame to add the feature and forever disable it,
but it will avoid a mistake of enabling it when we are reorganizing
the feature definitions on i915_pci.c later.

sounds Good,


It will also allow us to probably extend that workaround for
other platforms.

Cc: Mahesh Kumar 
Cc: Maarten Lankhorst 
Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/i915_pci.c | 1 +
  drivers/gpu/drm/i915/intel_pm.c | 6 ++
  2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index da60866b6628..df751a152057 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -426,6 +426,7 @@ static const struct intel_device_info intel_cherryview_info 
__initconst = {
.platform = INTEL_SKYLAKE, \
.has_csr = 1, \
.has_guc = 1, \
+   .has_ipc = 1, \
.ddb_size = 896
  
  static const struct intel_device_info intel_skylake_gt1_info __initconst = {

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 52c4c194aa51..ede871b7982e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5828,6 +5828,12 @@ void intel_enable_ipc(struct drm_i915_private *dev_priv)
  {
u32 val;
  
+	/* Display WA #0477 WaDisableIPC: skl */

+   if (IS_SKYLAKE(dev_priv)) {
+   dev_priv->ipc_enabled = false;
+   return;
+   }
+

looks good to me.
Reviewed-by: Mahesh Kumar 
-Mahesh

val = I915_READ(DISP_ARB_CTL2);
  
  	if (dev_priv->ipc_enabled)


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

Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro

[Jérémy Lefaure]

On Mon, 2 Oct 2017 15:22:24 -0400
bfie...@fieldses.org (J. Bruce Fields) wrote:

> Mainly I'd just like to know which you're asking for.  Do you want me to
> apply this, or to ACK it so someone else can?  If it's sent as a series
> I tend to assume the latter.
> 
> But in this case I'm assuming it's the former, so I'll pick up the nfsd
> one
Could you to apply the NFSD patch ("nfsd: use ARRAY_SIZE") with the
Reviewed-by: Jeff Layton ) tag please ?

This patch is an individual patch and it should not have been sent in a
series (sorry about that).

Thank you,
Jérémy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for tests/gem_bad_length: drop gem_bad_length.c

[Patchwork]

== Series Details ==

Series: tests/gem_bad_length: drop gem_bad_length.c
URL   : https://patchwork.freedesktop.org/series/31292/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup wf_vblank-vs-dpms-interruptible:
dmesg-warn -> PASS   (shard-hsw)
Test gem_eio:
Subgroup throttle:
dmesg-warn -> PASS   (shard-hsw) fdo#102886

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886

shard-hswtotal:2428 pass:1331 dwarn:6   dfail:0   fail:8   skip:1083 
time:10104s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_284/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 Drop tests for object creation from stolen

[Patchwork]

== Series Details ==

Series: Drop tests for object creation from stolen
URL   : https://patchwork.freedesktop.org/series/31290/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup wf_vblank-vs-dpms-interruptible:
dmesg-warn -> PASS   (shard-hsw)

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

shard-hswtotal:2412 pass:1331 dwarn:7   dfail:0   fail:8   skip:1066 
time:10058s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_283/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 tests/gem_bad_length: drop gem_bad_length.c

[Patchwork]

== Series Details ==

Series: tests/gem_bad_length: drop gem_bad_length.c
URL   : https://patchwork.freedesktop.org/series/31292/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
b5404f8435f828ca039a2e46be629b3d4c92465b meson: Follow suit with the renaming 
of kms_pipe_color

with latest DRM-Tip kernel build CI_DRM_3163
14f3207683e1 drm-tip: 2017y-10m-02d-20h-23m-38s UTC integration manifest

Testlist changes:
-igt@gem_bad_length

Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> INCOMPLETE (fi-cfl-s) k.org#196765

k.org#196765 https://bugzilla.kernel.org/show_bug.cgi?id=196765

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:462s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:470s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:395s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:573s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:289s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:535s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:537s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:549s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:549s
fi-cfl-s total:288  pass:255  dwarn:1   dfail:0   fail:0   skip:31 
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:636s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:439s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:440s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:422s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:467s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:499s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:583s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:497s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:658s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:541s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:524s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:482s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:590s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:441s

== Logs ==

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

[Intel-gfx] [PATCH i-g-t] tests/gem_bad_length: drop gem_bad_length.c

[Daniele Ceraolo Spurio]

Most of the gem_bad_length code is compiled out because creating
a zero-length object is not allowed anymore by i915 and thus it is
not possible to execute it. The remaining part checks that creation of
a zero-length object does indeed fail, which is also checked by
gem_create/create-invalid-size.
The only difference between the 2 tests is that gem_bad_length checks
specifically for EINVAL while create-invalid-size only looks for
failure, so after adding the EINVAL check to create-invalid-size it is
safe to drop gem_bad_length.

Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/Makefile.sources |   1 -
 tests/gem_bad_length.c | 133 -
 tests/gem_create.c |   2 +-
 3 files changed, 1 insertion(+), 135 deletions(-)
 delete mode 100644 tests/gem_bad_length.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c4d320e..142ff2b 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -40,7 +40,6 @@ TESTS_progs = \
drv_module_reload \
drv_selftest \
drv_suspend \
-   gem_bad_length \
gem_bad_reloc \
gem_basic \
gem_busy \
diff --git a/tests/gem_bad_length.c b/tests/gem_bad_length.c
deleted file mode 100644
index cca0145..000
--- a/tests/gem_bad_length.c
+++ /dev/null
@@ -1,133 +0,0 @@
-/*
- * Copyright © 2011 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- * Authors:
- *Chris Wilson 
- *
- */
-
-#include "igt.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "drm.h"
-
-IGT_TEST_DESCRIPTION("Test minimal bo_create and batchbuffer exec.");
-
-/*
- * Testcase: Minimal bo_create and batchbuffer exec
- *
- * Originally this caught an kernel oops due to the unchecked assumption that
- * objects have size > 0.
- */
-
-static uint32_t do_gem_create(int fd, int size, int *retval)
-{
-   struct drm_i915_gem_create create;
-   int ret;
-
-   create.handle = 0;
-   create.size = (size + 4095) & -4096;
-   ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, );
-   igt_assert(retval || ret == 0);
-   if (retval)
-   *retval = errno;
-
-   return create.handle;
-}
-
-#if 0
-static int gem_exec(int fd, struct drm_i915_gem_execbuffer2 *execbuf)
-{
-   return drmIoctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf);
-}
-#endif
-
-static void create0(int fd)
-{
-   int retval = 0;
-   igt_info("trying to create a zero-length gem object\n");
-   do_gem_create(fd, 0, );
-   igt_assert(retval == EINVAL);
-}
-
-#if 0
-static void exec0(int fd)
-{
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 exec[1];
-   uint32_t buf[2] = { MI_BATCH_BUFFER_END, 0 };
-
-   /* Just try executing with a zero-length bo.
-* We expect the kernel to either accept the nop batch, or reject it
-* for the zero-length buffer, but never crash.
-*/
-
-   exec[0].handle = gem_create(fd, 4096);
-   gem_write(fd, exec[0].handle, 0, buf, sizeof(buf));
-   exec[0].relocation_count = 0;
-   exec[0].relocs_ptr = 0;
-   exec[0].alignment = 0;
-   exec[0].offset = 0;
-   exec[0].flags = 0;
-   exec[0].rsvd1 = 0;
-   exec[0].rsvd2 = 0;
-
-   execbuf.buffers_ptr = (uintptr_t)exec;
-   execbuf.buffer_count = 1;
-   execbuf.batch_start_offset = 0;
-   execbuf.batch_len = sizeof(buf);
-   execbuf.cliprects_ptr = 0;
-   execbuf.num_cliprects = 0;
-   execbuf.DR1 = 0;
-   execbuf.DR4 = 0;
-   execbuf.flags = 0;
-   i915_execbuffer2_set_context_id(execbuf, 0);
-   execbuf.rsvd2 = 0;
-
-   igt_info("trying to run an empty batchbuffer\n");
-   gem_exec(fd, );
-
-   gem_close(fd, exec[0].handle);
-}
-#endif
-
-igt_simple_main

[Intel-gfx] ✓ Fi.CI.BAT: success for Drop tests for object creation from stolen

[Patchwork]

== Series Details ==

Series: Drop tests for object creation from stolen
URL   : https://patchwork.freedesktop.org/series/31290/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
b5404f8435f828ca039a2e46be629b3d4c92465b meson: Follow suit with the renaming 
of kms_pipe_color

with latest DRM-Tip kernel build CI_DRM_3163
14f3207683e1 drm-tip: 2017y-10m-02d-20h-23m-38s UTC integration manifest

Testlist changes:
-igt@gem_create@stolen-invalid-flag
-igt@gem_pread@pagefault-pread
-igt@gem_pread@stolen-display
-igt@gem_pread@stolen-normal
-igt@gem_pread@stolen-snoop
-igt@gem_pread@stolen-uncached
-igt@gem_pwrite@stolen-display
-igt@gem_pwrite@stolen-normal
-igt@gem_pwrite@stolen-snoop
-igt@gem_pwrite@stolen-uncached
-igt@gem_stolen@large-object-alloc
-igt@gem_stolen@stolen-clear
-igt@gem_stolen@stolen-copy
-igt@gem_stolen@stolen-fill-purge
-igt@gem_stolen@stolen-hibernate
-igt@gem_stolen@stolen-no-mmap
-igt@gem_stolen@stolen-pread
-igt@gem_stolen@stolen-pwrite

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:458s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:472s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:391s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:585s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:291s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:532s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:533s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:555s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:546s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:567s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:639s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:441s
fi-glk-1 total:289  pass:258  dwarn:3   dfail:0   fail:0   skip:28  
time:597s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:442s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:423s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:462s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:509s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:582s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:491s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:595s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:661s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:537s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:522s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:479s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:593s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:446s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for 2-in-1: Organize feature inheritance and disable IPC.

[Patchwork]

== Series Details ==

Series: 2-in-1: Organize feature inheritance and disable IPC.
URL   : https://patchwork.freedesktop.org/series/31090/
State : success

== Summary ==

Series 31090v1 2-in-1: Organize feature inheritance and disable IPC.
https://patchwork.freedesktop.org/api/1.0/series/31090/revisions/1/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:459s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:476s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:395s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:570s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:288s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:534s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:541s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:548s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:521s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:560s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:614s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:433s
fi-glk-1 total:289  pass:258  dwarn:3   dfail:0   fail:0   skip:28  
time:597s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:438s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:424s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:466s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:499s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:472s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:503s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:581s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:498s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:594s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:659s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:533s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:519s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:477s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:591s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:434s

14f3207683e165f826d0e5861944fc6f39e8e20f drm-tip: 2017y-10m-02d-20h-23m-38s UTC 
integration manifest
8da14f06fd4a drm/i915: Extend WaDisableIPC to all platforms.
37a80792833f drm/i915: Organize GLK_COLORS.
dcd1fd8d44c9 drm/i915: Organize GEN features inheritance.
9d19c7ea1a15 drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC.

== Logs ==

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

[Intel-gfx] [RFC i-g-t 6/6] lib/ioctl_wrappers: drop stolen memory related wrappers

[Daniele Ceraolo Spurio]

The feature was never merged and there has been no progress in the
last year. The wrappers are using a wrong ioctl number (38 is
HAS_POOLED_EU and not CREATE_VERSION) and extensions of the
gem_create and get_aperture ioctl structures that never made it into
the kernel.
Tests that were using the wrappers have already been removed by previous
patches so it is now safe to remove the wrappers themselves.

Signed-off-by: Daniele Ceraolo Spurio 
---
 lib/ioctl_wrappers.c | 119 ---
 lib/ioctl_wrappers.h |  16 ---
 2 files changed, 135 deletions(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 51b6b7b..fdf6cc5 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -479,79 +479,6 @@ void gem_sync(int fd, uint32_t handle)
errno = 0;
 }
 
-
-bool gem_create__has_stolen_support(int fd)
-{
-   static int has_stolen_support = -1;
-   struct drm_i915_getparam gp;
-   int val = -1;
-
-   if (has_stolen_support < 0) {
-   memset(, 0, sizeof(gp));
-   gp.param = 38; /* CREATE_VERSION */
-   gp.value = 
-
-   /* Do we have the extended gem_create_ioctl? */
-   ioctl(fd, DRM_IOCTL_I915_GETPARAM, );
-   has_stolen_support = val >= 2;
-   }
-
-   return has_stolen_support;
-}
-
-struct local_i915_gem_create_v2 {
-   uint64_t size;
-   uint32_t handle;
-   uint32_t pad;
-#define I915_CREATE_PLACEMENT_STOLEN (1<<0)
-   uint32_t flags;
-};
-
-#define LOCAL_IOCTL_I915_GEM_CREATE   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_CREATE, struct local_i915_gem_create_v2)
-uint32_t __gem_create_stolen(int fd, uint64_t size)
-{
-   struct local_i915_gem_create_v2 create;
-   int ret;
-
-   memset(, 0, sizeof(create));
-   create.handle = 0;
-   create.size = size;
-   create.flags = I915_CREATE_PLACEMENT_STOLEN;
-   ret = igt_ioctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-
-   if (ret < 0)
-   return 0;
-
-   errno = 0;
-   return create.handle;
-}
-
-/**
- * gem_create_stolen:
- * @fd: open i915 drm file descriptor
- * @size: desired size of the buffer
- *
- * This wraps the new GEM_CREATE ioctl, which allocates a new gem buffer
- * object of @size and placement in stolen memory region.
- *
- * Returns: The file-private handle of the created buffer object
- */
-
-uint32_t gem_create_stolen(int fd, uint64_t size)
-{
-   struct local_i915_gem_create_v2 create;
-
-   memset(, 0, sizeof(create));
-   create.handle = 0;
-   create.size = size;
-   create.flags = I915_CREATE_PLACEMENT_STOLEN;
-   do_ioctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-   igt_assert(create.handle);
-
-   return create.handle;
-}
-
-
 uint32_t __gem_create(int fd, int size)
 {
struct drm_i915_gem_create create;
@@ -1378,52 +1305,6 @@ bool gem_has_bsd2(int fd)
has_bsd2 = has_param(fd, LOCAL_I915_PARAM_HAS_BSD2);
return has_bsd2;
 }
-
-struct local_i915_gem_get_aperture {
-   __u64 aper_size;
-   __u64 aper_available_size;
-   __u64 version;
-   __u64 map_total_size;
-   __u64 stolen_total_size;
-};
-#define DRM_I915_GEM_GET_APERTURE  0x23
-#define LOCAL_IOCTL_I915_GEM_GET_APERTURE DRM_IOR  (DRM_COMMAND_BASE + 
DRM_I915_GEM_GET_APERTURE, struct local_i915_gem_get_aperture)
-/**
- * gem_total_mappable_size:
- * @fd: open i915 drm file descriptor
- *
- * Feature test macro to query the kernel for the total mappable size.
- *
- * Returns: Total mappable address space size.
- */
-uint64_t gem_total_mappable_size(int fd)
-{
-   struct local_i915_gem_get_aperture aperture;
-
-   memset(, 0, sizeof(aperture));
-   do_ioctl(fd, LOCAL_IOCTL_I915_GEM_GET_APERTURE, );
-
-   return aperture.map_total_size;
-}
-
-/**
- * gem_total_stolen_size:
- * @fd: open i915 drm file descriptor
- *
- * Feature test macro to query the kernel for the total stolen size.
- *
- * Returns: Total stolen memory.
- */
-uint64_t gem_total_stolen_size(int fd)
-{
-   struct local_i915_gem_get_aperture aperture;
-
-   memset(, 0, sizeof(aperture));
-   do_ioctl(fd, LOCAL_IOCTL_I915_GEM_GET_APERTURE, );
-
-   return aperture.stolen_total_size;
-}
-
 /**
  * gem_available_aperture_size:
  * @fd: open i915 drm file descriptor
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index 090c125..008747a 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -70,9 +70,6 @@ int __gem_set_domain(int fd, uint32_t handle, uint32_t read, 
uint32_t write);
 void gem_set_domain(int fd, uint32_t handle, uint32_t read, uint32_t write);
 int gem_wait(int fd, uint32_t handle, int64_t *timeout_ns);
 void gem_sync(int fd, uint32_t handle);
-bool gem_create__has_stolen_support(int fd);
-uint32_t __gem_create_stolen(int fd, uint64_t size);
-uint32_t gem_create_stolen(int fd, uint64_t size);
 uint32_t __gem_create(int fd, int 

[Intel-gfx] [RFC i-g-t 5/6] tests/gem_concurrent_all: drop stolen memory related subtests

[Daniele Ceraolo Spurio]

The feature was never merged and there has been no progress in the
last year. The tests are currently excluded from compilation with and
ifdef.

Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/gem_concurrent_all.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
index 201b491..87f2129 100644
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -170,36 +170,6 @@ static void can_create_private(const struct create 
*create, unsigned count)
 }
 #endif
 
-#if HAVE_CREATE_STOLEN
-static drm_intel_bo *
-create_stolen_bo(drm_intel_bufmgr *bufmgr, uint64_t size)
-{
-   drm_intel_bo *bo;
-   uint32_t handle;
-
-   /* XXX gem_create_with_flags(fd, size, I915_CREATE_STOLEN); */
-
-   handle = gem_create(fd, size);
-   bo = gem_handle_to_libdrm_bo(bufmgr, fd, "stolen", handle);
-   gem_close(fd, handle);
-
-   return bo;
-}
-
-static void can_create_stolen(const struct create *create, unsigned count)
-{
-   /* XXX check num_buffers against available stolen */
-   igt_require(0);
-}
-#endif
-
-static void create_cpu_require(const struct create *create, unsigned count)
-{
-#if HAVE_CREATE_STOLEN
-   igt_require(create->create != create_stolen_bo);
-#endif
-}
-
 static drm_intel_bo *
 unmapped_create_bo(const struct buffers *b)
 {
@@ -208,7 +178,6 @@ unmapped_create_bo(const struct buffers *b)
 
 static void create_snoop_require(const struct create *create, unsigned count)
 {
-   create_cpu_require(create, count);
igt_require(!gem_has_llc(fd));
 }
 
@@ -1727,7 +1696,6 @@ igt_main
{
.name = "cpu",
.create_bo = unmapped_create_bo,
-   .require = create_cpu_require,
.set_bo = cpu_set_bo,
.cmp_bo = cpu_cmp_bo,
.release_bo = nop_release_bo,
@@ -1807,9 +1775,6 @@ igt_main
 #if HAVE_CREATE_PRIVATE
{ "private-", can_create_private, create_private_bo},
 #endif
-#if HAVE_CREATE_STOLEN
-   { "stolen-", can_create_stolen, create_stolen_bo},
-#endif
{ NULL, NULL }
};
const struct size sizes[] = {
-- 
1.9.1

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

[Intel-gfx] [RFC i-g-t 4/6] tests/gem_stolen: drop gem_stolen.c

[Daniele Ceraolo Spurio]

The feature was never merged and there has been no progress in the
last year. The subtests are currently skipping on all platforms by
checking a field in the get_aperture ioctl structure that doesn't
exist in the kernel version of the struct.

Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/Makefile.sources |   1 -
 tests/gem_stolen.c | 455 -
 2 files changed, 456 deletions(-)
 delete mode 100644 tests/gem_stolen.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c4d320e..b2a9cfe 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -141,7 +141,6 @@ TESTS_progs = \
gem_shrink \
gem_softpin \
gem_spin_batch \
-   gem_stolen \
gem_storedw_batches_loop \
gem_storedw_loop \
gem_streaming_writes \
diff --git a/tests/gem_stolen.c b/tests/gem_stolen.c
deleted file mode 100644
index 1d48997..000
--- a/tests/gem_stolen.c
+++ /dev/null
@@ -1,455 +0,0 @@
-/*
- * Copyright © 2015 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- * Authors:
- *Ankitprasad Sharma 
- *
- */
-
-/** @file gem_create_stolen.c
- *
- * This is a test for the extended gem_create ioctl, that includes allocation
- * of object from stolen memory.
- *
- * The goal is to simply ensure the basics work, and invalid input combinations
- * are rejected.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "ioctl_wrappers.h"
-#include "intel_bufmgr.h"
-#include "intel_batchbuffer.h"
-#include "intel_io.h"
-#include "intel_chipset.h"
-#include "igt_aux.h"
-#include "drmtest.h"
-#include "drm.h"
-#include "i915_drm.h"
-
-IGT_TEST_DESCRIPTION("This test verifies the exetended gem_create ioctl,"
-" that includes allocation of obj from stolen region");
-#define CLEAR(s) memset(, 0, sizeof(s))
-#define SIZE 1024*1024
-#define DWORD_SIZE 4
-#define DATA 0xdead
-#define LARGE_SIZE 0x
-#define MAX_OBJECTS 100
-
-static drm_intel_bufmgr *bufmgr;
-static struct intel_batchbuffer *batch;
-
-static void verify_copy_op(drm_intel_bo *src, drm_intel_bo *dest)
-{
-   uint32_t *virt, i, ret;
-   /* Fill the src BO with dwords */
-   ret = drm_intel_gem_bo_map_gtt(src);
-   igt_assert(!ret);
-
-   virt = src->virtual;
-   for (i = 0; i < SIZE/DWORD_SIZE; i++)
-   virt[i] = i;
-
-   intel_copy_bo(batch, dest, src, SIZE);
-
-   ret = drm_intel_gem_bo_map_gtt(dest);
-   igt_assert(!ret);
-
-   virt = dest->virtual;
-   /* verify */
-   for (i = 0; i < SIZE/DWORD_SIZE; i++)
-   igt_assert_eq(virt[i], i);
-
-   drm_intel_bo_unmap(src);
-   drm_intel_bo_unmap(dest);
-}
-
-static void stolen_pwrite(int fd)
-{
-   drm_intel_bo *bo;
-   uint32_t buf[SIZE/DWORD_SIZE];
-   uint32_t handle = 0;
-   uint32_t *virt;
-   int i, ret = 0;
-
-   for (i = 0; i < SIZE/DWORD_SIZE; i++)
-   buf[i] = DATA;
-
-   gem_require_stolen_support(fd);
-
-   handle = gem_create_stolen(fd, SIZE);
-
-   gem_write(fd, handle, 0, buf, SIZE);
-   bo = gem_handle_to_libdrm_bo(bufmgr, fd, "bo", handle);
-
-   ret = drm_intel_gem_bo_map_gtt(bo);
-   igt_assert(!ret);
-
-   virt = bo->virtual;
-
-   for (i = 0; i < SIZE/DWORD_SIZE; i++)
-   igt_assert_eq(virt[i], DATA);
-
-   drm_intel_bo_unmap(bo);
-   drm_intel_bo_unreference(bo);
-   gem_close(fd, handle);
-}
-
-static void stolen_pread(int fd)
-{
-   drm_intel_bo *bo;
-   uint32_t buf[SIZE/DWORD_SIZE];
-   uint32_t handle = 0;
-   uint32_t *virt;
-   int i, ret = 0;
-
-   CLEAR(buf);
-
-   gem_require_stolen_support(fd);
-
-   handle = gem_create_stolen(fd, SIZE);
-
-   bo = 

[Intel-gfx] [RFC i-g-t 2/6] tests/gem_pwrite: drop stolen memory related subtests

[Daniele Ceraolo Spurio]

The feature was never merged and there has been no progress in the
last year. The subtests are currently skipping on all platforms by
checking a field in the get_aperture ioctl structure that doesn't
exist in the kernel version of the struct.

Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/gem_pwrite.c | 43 ---
 1 file changed, 43 deletions(-)

diff --git a/tests/gem_pwrite.c b/tests/gem_pwrite.c
index b61b446..1c3d23d 100644
--- a/tests/gem_pwrite.c
+++ b/tests/gem_pwrite.c
@@ -206,7 +206,6 @@ static void test_big_gtt(int fd, int scale, unsigned flags)
 }
 
 uint32_t *src, dst;
-uint32_t *src_user, dst_stolen;
 int fd;
 
 int main(int argc, char **argv)
@@ -241,8 +240,6 @@ int main(int argc, char **argv)
 
dst = gem_create(fd, object_size);
src = malloc(object_size);
-   dst_stolen = gem_create_stolen(fd, object_size);
-   src_user = malloc(object_size);
}
 
igt_subtest("basic") {
@@ -279,49 +276,9 @@ int main(int argc, char **argv)
}
}
 
-   igt_subtest("stolen-normal") {
-   gem_require_stolen_support(fd);
-   for (count = 1; count <= 1<<17; count <<= 1) {
-   struct timeval start, end;
-
-   gettimeofday(, NULL);
-   do_gem_write(fd, dst_stolen, src_user,
-object_size, count);
-   gettimeofday(, NULL);
-   usecs = elapsed(, , count);
-   bps = bytes_per_sec(buf, object_size/usecs*1e6);
-   igt_info("Time to pwrite %d bytes x %6d:
%7.3fµs, %s\n",
-object_size, count, usecs, bps);
-   fflush(stdout);
-   }
-   }
-
-   for (c = cache; c->level != -1; c++) {
-   igt_subtest_f("stolen-%s", c->name) {
-   gem_require_stolen_support(fd);
-   gem_set_caching(fd, dst, c->level);
-   for (count = 1; count <= 1<<17; count <<= 1) {
-   struct timeval start, end;
-
-   gettimeofday(, NULL);
-   do_gem_write(fd, dst_stolen, src_user,
-object_size, count);
-   gettimeofday(, NULL);
-   bps = bytes_per_sec(buf,
-   object_size/usecs*1e6);
-   igt_info("Time to stolen-%s pwrite %d bytes x 
%6d: %7.3fµs, %s\n",
-c->name, object_size, count,
-usecs, bps);
-   fflush(stdout);
-   }
-   }
-   }
-
igt_fixture {
free(src);
gem_close(fd, dst);
-   free(src_user);
-   gem_close(fd, dst_stolen);
}
 
{
-- 
1.9.1

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

[Intel-gfx] [RFC i-g-t 1/6] tests/gem_pread: drop stolen memory related subtests

[Daniele Ceraolo Spurio]

The feature was never merged and there has been no progress in the
last year. The subtests are currently skipping on all platforms by
checking a field in the get_aperture ioctl structure that doesn't
exist in the kernel version of the struct.

Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/gem_pread.c | 95 ---
 1 file changed, 95 deletions(-)

diff --git a/tests/gem_pread.c b/tests/gem_pread.c
index f4cf472..39a46ed 100644
--- a/tests/gem_pread.c
+++ b/tests/gem_pread.c
@@ -40,10 +40,6 @@
 #include "drm.h"
 
 #define OBJECT_SIZE 16384
-#define LARGE_OBJECT_SIZE 1024 * 1024
-#define KGRN "\x1B[32m"
-#define KRED "\x1B[31m"
-#define KNRM "\x1B[0m"
 
 static void do_gem_read(int fd, uint32_t handle, void *buf, int len, int loops)
 {
@@ -79,8 +75,6 @@ static const char *bytes_per_sec(char *buf, double v)
 
 
 uint32_t *src, dst;
-uint32_t *dst_user, src_stolen, large_stolen;
-uint32_t *stolen_pf_user, *stolen_nopf_user;
 int fd, count;
 
 int main(int argc, char **argv)
@@ -113,8 +107,6 @@ int main(int argc, char **argv)
 
dst = gem_create(fd, object_size);
src = malloc(object_size);
-   src_stolen = gem_create_stolen(fd, object_size);
-   dst_user = malloc(object_size);
}
 
igt_subtest("basic") {
@@ -151,96 +143,9 @@ int main(int argc, char **argv)
}
}
 
-   igt_subtest("stolen-normal") {
-   gem_require_stolen_support(fd);
-   for (count = 1; count <= 1<<17; count <<= 1) {
-   struct timeval start, end;
-
-   gettimeofday(, NULL);
-   do_gem_read(fd, src_stolen, dst_user, object_size, 
count);
-   gettimeofday(, NULL);
-   usecs = elapsed(, , count);
-   bps = bytes_per_sec(buf, object_size/usecs*1e6);
-   igt_info("Time to pread %d bytes x %6d: %7.3fµs, %s\n",
-object_size, count, usecs, bps);
-   fflush(stdout);
-   }
-   }
-   for (c = cache; c->level != -1; c++) {
-   igt_subtest_f("stolen-%s", c->name) {
-   gem_require_stolen_support(fd);
-   gem_set_caching(fd, src_stolen, c->level);
-
-   for (count = 1; count <= 1<<17; count <<= 1) {
-   struct timeval start, end;
-
-   gettimeofday(, NULL);
-   do_gem_read(fd, src_stolen, dst_user,
-   object_size, count);
-   gettimeofday(, NULL);
-   usecs = elapsed(, , count);
-   bps = bytes_per_sec(buf, object_size/usecs*1e6);
-   igt_info("Time to stolen-%s pread %d bytes x 
%6d:  %7.3fµs, %s\n",
-c->name, object_size, count, usecs, 
bps);
-   fflush(stdout);
-   }
-   }
-   }
-
-   /* List the time taken in pread operation for stolen objects, with
-* and without the overhead of page fault handling on accessing the
-* user space buffer
-*/
-   igt_subtest("pagefault-pread") {
-   gem_require_stolen_support(fd);
-   large_stolen = gem_create_stolen(fd, LARGE_OBJECT_SIZE);
-   stolen_nopf_user = (uint32_t *) mmap(NULL, LARGE_OBJECT_SIZE,
-   PROT_WRITE,
-   MAP_ANONYMOUS|MAP_PRIVATE,
-   -1, 0);
-   igt_assert(stolen_nopf_user);
-
-   for (count = 1; count <= 10; count ++) {
-   struct timeval start, end;
-   double t_elapsed = 0;
-
-   gettimeofday(, NULL);
-   do_gem_read(fd, large_stolen, stolen_nopf_user,
-   LARGE_OBJECT_SIZE, 1);
-   gettimeofday(, NULL);
-   t_elapsed = elapsed(, , count);
-   bps = bytes_per_sec(buf, object_size/t_elapsed*1e6);
-   igt_info("Pagefault-N - Time to pread %d bytes: 
%7.3fµs, %s\n",
-LARGE_OBJECT_SIZE, t_elapsed, bps);
-
-   stolen_pf_user = (uint32_t *) mmap(NULL, 
LARGE_OBJECT_SIZE,
- PROT_WRITE,
- MAP_ANONYMOUS|MAP_PRIVATE,
- -1, 0);
-   igt_assert(stolen_pf_user);
-
-   gettimeofday(, NULL);
-   do_gem_read(fd, large_stolen, 

[Intel-gfx] [RFC i-g-t 3/6] tests/gem_create: drop stolen memory related subtest

[Daniele Ceraolo Spurio]

The feature was never merged and there has been no progress in the
last year. The subtest is currently skipping on all platforms by checking
a field in the get_aperture ioctl structure that doesn't exist in the
kernel version of the struct.

Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/gem_create.c | 37 ++---
 1 file changed, 2 insertions(+), 35 deletions(-)

diff --git a/tests/gem_create.c b/tests/gem_create.c
index de7b820..a451816 100644
--- a/tests/gem_create.c
+++ b/tests/gem_create.c
@@ -27,8 +27,7 @@
 
 /** @file gem_create.c
  *
- * This is a test for the extended and old gem_create ioctl, that
- * includes allocation of object from stolen memory and shmem.
+ * This is a test for the gem_create ioctl.
  *
  * The goal is to simply ensure that basics work and invalid input
  * combinations are rejected.
@@ -57,42 +56,13 @@
 #include "drm.h"
 #include "i915_drm.h"
 
-IGT_TEST_DESCRIPTION("This is a test for the extended & old gem_create ioctl,"
-" that includes allocation of object from stolen memory"
-" and shmem.");
+IGT_TEST_DESCRIPTION("This is a test for the gem_create ioctl");
 
 #define CLEAR(s) memset(, 0, sizeof(s))
 #define PAGE_SIZE 4096
 
-struct local_i915_gem_create_v2 {
-   uint64_t size;
-   uint32_t handle;
-   uint32_t pad;
-#define I915_CREATE_PLACEMENT_STOLEN (1<<0)
-   uint32_t flags;
-} create;
-
 #define LOCAL_IOCTL_I915_GEM_CREATE   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_CREATE, struct local_i915_gem_create_v2)
 
-static void invalid_flag_test(int fd)
-{
-   int ret;
-
-   gem_require_stolen_support(fd);
-
-   create.handle = 0;
-   create.size = PAGE_SIZE;
-   create.flags = ~I915_CREATE_PLACEMENT_STOLEN;
-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-
-   igt_assert(ret <= 0);
-
-   create.flags = ~0;
-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, );
-
-   igt_assert(ret <= 0);
-}
-
 static void invalid_size_test(int fd)
 {
int handle;
@@ -152,9 +122,6 @@ igt_main
fd = drm_open_driver(DRIVER_INTEL);
}
 
-   igt_subtest("stolen-invalid-flag")
-   invalid_flag_test(fd);
-
igt_subtest("create-invalid-size")
invalid_size_test(fd);
 
-- 
1.9.1

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

[Intel-gfx] [RFC i-g-t 0/6] Drop tests for object creation from stolen

[Daniele Ceraolo Spurio]

The tests were merged before the feature, which never made it to the
driver; the last update I could find ([1]) is more than a year old.
The tests are using a wrong getparam number and planned extensions
to the gem_create and get_aperture ioctl structures that don't match
what's currently in i915. Due to this all stolen-related subtests are
skipping.
Given the fact that there has been no traction behind the feature for
a long time it doesn't look like we'll need those tests anytime soon
and thus it makes sense to remove them.

The patches didn't revert cleanly and also contained some improvements
that are worth keeping, so instead of a revert I've organized the removal
in a single patch per test file to drop only the unneeded code.

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

Cc: Ankitprasad Sharma 
Cc: Petri Latvala 
Cc: Arkadiusz Hiler 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson  

Daniele Ceraolo Spurio (6):
  tests/gem_pread: drop stolen memory related subtests
  tests/gem_pwrite: drop stolen memory related subtests
  tests/gem_create: drop stolen memory related subtest
  tests/gem_stolen: drop gem_stolen.c
  tests/gem_concurrent_all: drop stolen memory related subtests
  lib/ioctl_wrappers: drop stolen memory related wrappers

 lib/ioctl_wrappers.c   | 119 
 lib/ioctl_wrappers.h   |  16 --
 tests/Makefile.sources |   1 -
 tests/gem_concurrent_all.c |  35 
 tests/gem_create.c |  37 +---
 tests/gem_pread.c  |  95 --
 tests/gem_pwrite.c |  43 -
 tests/gem_stolen.c | 455 -
 8 files changed, 2 insertions(+), 799 deletions(-)
 delete mode 100644 tests/gem_stolen.c

-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.

[Rodrigo Vivi]

On Mon, Oct 02, 2017 at 01:02:28PM +, Jani Nikula wrote:
> On Thu, 28 Sep 2017, Rodrigo Vivi  wrote:
> > Let's organize this in a way that it gets more obvious
> > when looking to the platform colors and in a easier
> > way to get inherited.
> >
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 9b54aafa2a0b..10537dcdd9c1 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -54,6 +54,8 @@
> > .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
> >  #define CHV_COLORS \
> > .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> > +#define GLK_COLORS \
> > +   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> >  
> >  /* Keep in gen based order, and chronological order within a gen */
> >  #define GEN2_FEATURES \
> > @@ -495,7 +497,7 @@ static const struct intel_device_info 
> > intel_geminilake_info __initconst = {
> > GEN9_LP_FEATURES,
> > .platform = INTEL_GEMINILAKE,
> > .ddb_size = 1024,
> > -   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> > +   GLK_COLORS
> 
> Please add he comma at the end.
> 
> >  };
> >  
> >  #define KBL_PLATFORM \
> > @@ -543,7 +545,7 @@ static const struct intel_device_info 
> > intel_coffeelake_gt3_info __initconst = {
> >  #define GEN10_FEATURES \
> > GEN9_FEATURES, \
> > .ddb_size = 1024, \
> > -   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> > +   GLK_COLORS

this one here doesn't compile. it is inside a define...

So, I have a:
"v2: Add comma at the end (Jani), when possible." here

but I'm not sure about that since comma here is not really needed, also it 
wasn't there with the .color
and it is not symmetric anymore...

> 
> Ditto.
> 
> BR,
> Jani.
> 
> >  
> >  static const struct intel_device_info intel_cannonlake_gt2_info 
> > __initconst = {
> > GEN10_FEATURES,
> 
> -- 
> 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.IGT: success for drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC 
size
URL   : https://patchwork.freedesktop.org/series/31284/
State : success

== Summary ==

Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252 +1
Test kms_flip:
Subgroup wf_vblank-vs-dpms-interruptible:
dmesg-warn -> PASS   (shard-hsw)
Subgroup modeset-vs-vblank-race:
pass   -> DMESG-WARN (shard-hsw) fdo#102919

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

shard-hswtotal:2429 pass:1330 dwarn:8   dfail:0   fail:8   skip:1083 
time:10059s

== Logs ==

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

Re: [Intel-gfx] [PATCH 17/21] drm/i915/selftests: huge page tests

[kbuild test robot]

Hi Matthew,

[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v4.14-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matthew-Auld/huge-gtt-pages/20171002-212557
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!

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


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

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

[Rogozhkin, Dmitry V]

Hi Peter, friendly reminder. Could you, please, respond?

-Original Message-
From: Rogozhkin, Dmitry V 
Sent: Wednesday, September 20, 2017 1:15 PM
To: Rogozhkin, Dmitry V ; pet...@infradead.org
Cc: Intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf 
queries

Hi Peter, could you, please, comment on below?

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Rogozhkin, Dmitry V
Sent: Wednesday, September 13, 2017 4:06 PM
To: pet...@infradead.org
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf 
queries

On Tue, 2017-08-29 at 21:21 +0200, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 07:16:31PM +, Rogozhkin, Dmitry V wrote:
> > > Pretty strict, people tend to get fairly upset every time we leak stuff.
> > > In fact Debian and Android carry a perf_event_paranoid patch that 
> > > default disables _everything_ :-(
> > 
> > Can you say more on that for Debian and Android? What exactly they do?
> > What is the value of perf_event_paranoid there? They disable 
> > everything even for root and CAP_SYS_ADMIN? But still they don't 
> > remove this from kernel on compilation stage, right? So users can 
> > explicitly change perf_event_paranoid to the desired value?
> 
> They introduce (and default to) perf_event_paranoid = 3. Which 
> disallows everything for unpriv user, root can still do things IIRC, 
> I'd have to dig out the patch.
> 
> This way apps have no access to the syscall, but you can enable it 
> using ADB by lowering the setting. So developers still have access, 
> but regular apps do not.
> 

Hi, Peter.

How you would feel about the following idea (or close to it):
1. We introduce one more level for perf_event_paranoid=4 (or =3, I am not sure 
whether Debian/Android =3 is considered uAPI) which would mean:
"disallow kernel profiling for unpriv, but let individual kernel modules to 
have their own settings".
2. We will have i915 PMU custom setting
"/sys/module/i915/parameters/perf_event_paranoid" which will be in effect only 
if global perf_event_paranoid=4 (or =3) and prevail over a global setting

Would anything like that be acceptable upstream? This would permit customers to 
configure i915 PMU support for unpriv users separately from the rest of PMU 
subsystem.

Regards,
Dmitry.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC 
size
URL   : https://patchwork.freedesktop.org/series/31284/
State : success

== Summary ==

Series 31284v1 drm/i915/cnl: Do not add an extra page for precaution in the 
Gen10 LRC size
https://patchwork.freedesktop.org/api/1.0/series/31284/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-cfl-s) fdo#103026

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:453s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:472s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:398s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:570s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:290s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:525s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:534s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:541s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:532s
fi-cfl-s total:289  pass:257  dwarn:0   dfail:0   fail:0   skip:32  
time:568s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:617s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:441s
fi-glk-1 total:289  pass:258  dwarn:3   dfail:0   fail:0   skip:28  
time:595s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:439s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:418s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:461s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:474s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:505s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:490s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:536s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:512s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:470s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:583s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:435s
fi-pnv-d510 failed to connect after reboot

14f3207683e165f826d0e5861944fc6f39e8e20f drm-tip: 2017y-10m-02d-20h-23m-38s UTC 
integration manifest
1f2eb31bd161 drm/i915/cnl: Do not add an extra page for precaution in the Gen10 
LRC size

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size

[Oscar Mateo]

BSpec indicates exactly 16750 DWORDs (17 pages), plus one page for PPHWSP.

Suggested-by: Joonas Lahtinen 
Fixes: 7fd0b1a ("drm/i915/cnl: Add Gen10 LRC size")
Signed-off-by: Oscar Mateo 
Cc: Rodrigo Vivi 
Cc: Daniele Ceraolo Spurio 
Cc: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a28e2a8..febbb91 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -39,7 +39,7 @@
 
 #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE)
 #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE)
-#define GEN10_LR_CONTEXT_RENDER_SIZE   (19 * PAGE_SIZE)
+#define GEN10_LR_CONTEXT_RENDER_SIZE   (18 * PAGE_SIZE)
 
 #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE)
 
-- 
1.9.1

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add has_psr-flag to gen9lp

[Rodrigo Vivi]

On Fri, Sep 29, 2017 at 12:32:10PM +, David Weinehall wrote:
> On Thu, Sep 28, 2017 at 08:19:29PM -, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: Add has_psr-flag to gen9lp
> > URL   : https://patchwork.freedesktop.org/series/28488/
> > State : success
> > 
> > == Summary ==
> > 
> > Series 28488v1 drm/i915: Add has_psr-flag to gen9lp
> > https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/
> > 
> > Test kms_psr_sink_crc:
> > Subgroup psr_basic:
> > skip   -> PASS   (fi-glk-1)
> 
> This seems relevant, and promising.

merged to dinq. Thanks for the patch.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

[Patchwork]

== Series Details ==

Series: drm/i915: Replace *_reference/unreference() or *_ref/unref with 
_get/put()
URL   : https://patchwork.freedesktop.org/series/31283/
State : failure

== Summary ==

Series 31283v1 drm/i915: Replace *_reference/unreference() or *_ref/unref with 
_get/put()
https://patchwork.freedesktop.org/api/1.0/series/31283/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-byt-j1900)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:458s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:476s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:396s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:576s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:287s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:531s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:536s
fi-byt-j1900 total:245  pass:214  dwarn:1   dfail:0   fail:0   skip:29 
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:563s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:633s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:431s
fi-glk-1 total:289  pass:257  dwarn:3   dfail:0   fail:0   skip:29  
time:588s
fi-hsw-4770  total:118  pass:100  dwarn:0   dfail:0   fail:0   skip:17 
fi-hsw-4770r total:118  pass:100  dwarn:0   dfail:0   fail:0   skip:17 
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:474s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-ivb-3770  total:118  pass:96   dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:505s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:490s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:595s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:659s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:534s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:578s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:470s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:591s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:434s
fi-byt-n2820 failed to connect after reboot

2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC 
integration manifest
513daac4b852 drm/i915: Replace *_reference/unreference() or *_ref/unref with 
_get/put()

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix DDI PHY init if it was already on

[Rodrigo Vivi]

On Mon, Oct 02, 2017 at 01:53:07PM +, Imre Deak wrote:
> The common lane power down flag of a DPIO PHY has a funky semantic:
> after the initial enabling of the PHY (so from a disabled state) this
> flag will be clear. It will be set only after the PHY will be used for
> the first time (for instance due to enabling the corresponding pipe) and
> then become unused (due to disabling the pipe). During the initial PHY
> enablement we don't know which of the above phases we are in, so move
> the check for the flag where this is known, the HW readout code. This is
> where the rest of lane power down status checks are done anyway.

This makes sense. I just wonder why at first place we were doing that
extra check to see if that was disabled.
I couldn't find anything on spec to justify the previous use of it and
new one is consistent with bit 9 that is very similar, so:

Reviewed-by: Rodrigo Vivi 

> 
> This fixes at least a problem on GLK where after module reloading, the
> common lane power down flag of PHY1 is set, but the PHY is actually
> powered-on and properly set up. The GRC readout code for other PHYs will
> hence think that PHY1 is not powered initially and disable it after the
> GRC readout. This will cause the AUX power well related to PHY1 to get
> disabled in a stuck state, timing out when we try to enable it later.
> 
> Cc: Ville Syrjala 
> Fixes: e93da0a0137b ("drm/i915/bxt: Sanitiy check the PHY lane power down 
> status")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102777
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  |  3 ++-
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 20 
>  2 files changed, 2 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 93cbbcbbc193..65f4b6786791 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1713,7 +1713,8 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> *encoder,
>  out:
>   if (ret && IS_GEN9_LP(dev_priv)) {
>   tmp = I915_READ(BXT_PHY_CTL(port));
> - if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
> + if ((tmp & (BXT_PHY_CMNLANE_POWERDOWN_ACK |
> + BXT_PHY_LANE_POWERDOWN_ACK |
>   BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED)
>   DRM_ERROR("Port %c enabled but PHY powered down? "
> "(PHY_CTL %08x)\n", port_name(port), tmp);
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 09b670929786..de38d014ed39 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -208,12 +208,6 @@ static const struct bxt_ddi_phy_info glk_ddi_phy_info[] 
> = {
>   },
>  };
>  
> -static u32 bxt_phy_port_mask(const struct bxt_ddi_phy_info *phy_info)
> -{
> - return (phy_info->dual_channel * BIT(phy_info->channel[DPIO_CH1].port)) 
> |
> - BIT(phy_info->channel[DPIO_CH0].port);
> -}
> -
>  static const struct bxt_ddi_phy_info *
>  bxt_get_phy_list(struct drm_i915_private *dev_priv, int *count)
>  {
> @@ -313,7 +307,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
> *dev_priv,
>   enum dpio_phy phy)
>  {
>   const struct bxt_ddi_phy_info *phy_info;
> - enum port port;
>  
>   phy_info = bxt_get_phy_info(dev_priv, phy);
>  
> @@ -335,19 +328,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
> *dev_priv,
>   return false;
>   }
>  
> - for_each_port_masked(port, bxt_phy_port_mask(phy_info)) {
> - u32 tmp = I915_READ(BXT_PHY_CTL(port));
> -
> - if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
> - DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
> -  "for port %c powered down "
> -  "(PHY_CTL %08x)\n",
> -  phy, port_name(port), tmp);
> -
> - return false;
> - }
> - }
> -
>   return true;
>  }
>  
> -- 
> 2.13.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Tetsuo Handa]

Tetsuo Handa wrote:
> Michael S. Tsirkin wrote:
> > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote:
> > > Hello.
> > > 
> > > I noticed that virtio_balloon is using register_oom_notifier() and
> > > leak_balloon() from virtballoon_oom_notify() might depend on
> > > __GFP_DIRECT_RECLAIM memory allocation.
> > > 
> > > In leak_balloon(), mutex_lock(>balloon_lock) is called in order to
> > > serialize against fill_balloon(). But in fill_balloon(),
> > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
> > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] 
> > > implies
> > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might
> > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory
> > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation can 
> > > reach
> > > __alloc_pages_may_oom() and hold oom_lock mutex and call out_of_memory().
> > > And leak_balloon() is called by virtballoon_oom_notify() via
> > > blocking_notifier_call_chain() callback when vb->balloon_lock mutex is 
> > > already
> > > held by fill_balloon(). As a result, despite __GFP_NORETRY is specified,
> > > fill_balloon() can indirectly get stuck waiting for vb->balloon_lock mutex
> > > at leak_balloon().
> > 
> > That would be tricky to fix. I guess we'll need to drop the lock
> > while allocating memory - not an easy fix.
> > 
> > > Also, in leak_balloon(), virtqueue_add_outbuf(GFP_KERNEL) is called via
> > > tell_host(). Reaching __alloc_pages_may_oom() from this 
> > > virtqueue_add_outbuf()
> > > request from leak_balloon() from virtballoon_oom_notify() from
> > > blocking_notifier_call_chain() from out_of_memory() leads to OOM lockup
> > > because oom_lock mutex is already held before calling out_of_memory().
> > 
> > I guess we should just do
> > 
> > GFP_KERNEL & ~__GFP_DIRECT_RECLAIM there then?
> 
> Yes, but GFP_KERNEL & ~__GFP_DIRECT_RECLAIM will effectively be GFP_NOWAIT, 
> for
> __GFP_IO and __GFP_FS won't make sense without __GFP_DIRECT_RECLAIM. It might
> significantly increases possibility of memory allocation failure.
> 
> > 
> > 
> > > 
> > > OOM notifier callback should not (directly or indirectly) depend on
> > > __GFP_DIRECT_RECLAIM memory allocation attempt. Can you fix this 
> > > dependency?
> > 
> 
> Another idea would be to use a kernel thread (or workqueue) so that
> virtballoon_oom_notify() can wait with timeout.
> 
> We could offload entire blocking_notifier_call_chain(_notify_list, 0, 
> )
> call to a kernel thread (or workqueue) with timeout if MM folks agree.
> 

Below is a patch which offloads blocking_notifier_call_chain() call. What do 
you think?

[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.

Since oom_notify_list is traversed via blocking_notifier_call_chain(),
it is legal to sleep inside OOM notifier callback function.

However, since oom_notify_list is traversed with oom_lock held,
__GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation attempt cannot
fail when traversing oom_notify_list entries. Therefore, OOM notifier
callback function should not (directly or indirectly) depend on
__GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation attempt.

Currently there are 5 register_oom_notifier() users in the mainline kernel.

  arch/powerpc/platforms/pseries/cmm.c
  arch/s390/mm/cmm.c
  drivers/gpu/drm/i915/i915_gem_shrinker.c
  drivers/virtio/virtio_balloon.c
  kernel/rcu/tree_plugin.h

Among these users, at least virtio_balloon.c has possibility of OOM lockup
because it is using mutex which can depend on GFP_KERNEL memory allocations.
(Both cmm.c seem to be safe as they use spinlocks. I'm not sure about
tree_plugin.h and i915_gem_shrinker.c . Please check.)

But converting such allocations to use GFP_NOWAIT is not only prone to
allocation failures under memory pressure but also difficult to audit
whether all locations are converted to use GFP_NOWAIT.

Therefore, this patch offloads blocking_notifier_call_chain() call to a
dedicated kernel thread and wait for completion with timeout of 5 seconds
so that we can completely forget about possibility of OOM lockup due to
OOM notifier callback function.

(5 seconds is chosen from my guess that blocking_notifier_call_chain()
should not take long, for we are using mutex_trylock(_lock) at
__alloc_pages_may_oom() based on an assumption that out_of_memory() should
reclaim memory shortly.)

The kernel thread is created upon first register_oom_notifier() call.
Thus, those environments which do not use register_oom_notifier() will
not waste resource for the dedicated kernel thread.

Signed-off-by: Tetsuo Handa 
---
 mm/oom_kill.c | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index dee0f75..d9744f7 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -981,9 +981,37 

Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro

[Tobin C. Harding]

On Sun, Oct 01, 2017 at 03:30:38PM -0400, Jérémy Lefaure wrote:
> Hi everyone,
> Using ARRAY_SIZE improves the code readability. I used coccinelle (I
> made a change to the array_size.cocci file [1]) to find several places
> where ARRAY_SIZE could be used instead of other macros or sizeof
> division.
> 
> I tried to divide the changes into a patch per subsystem (excepted for
> staging). If one of the patch should be split into several patches, let
> me know.
> 
> In order to reduce the size of the To: and Cc: lines, each patch of the
> series is sent only to the maintainers and lists concerned by the patch.
> This cover letter is sent to every list concerned by this series.

Why don't you just send individual patches for each subsystem? I'm not a 
maintainer but I don't see
how any one person is going to be able to apply this whole series, it is making 
it hard for
maintainers if they have to pick patches out from among the series (if indeed 
any will bother
doing that).

I get that this will be more work for you but AFAIK we are optimizing for 
maintainers.

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

Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro

[J. Bruce Fields]

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote:
> On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote:
> > On Mon, 2 Oct 2017 09:01:31 +1100
> > "Tobin C. Harding"  wrote:
> > 
> > > > In order to reduce the size of the To: and Cc: lines, each patch of the
> > > > series is sent only to the maintainers and lists concerned by the patch.
> > > > This cover letter is sent to every list concerned by this series.  
> > > 
> > > Why don't you just send individual patches for each subsystem? I'm not a 
> > > maintainer but I don't see
> > > how any one person is going to be able to apply this whole series, it is 
> > > making it hard for
> > > maintainers if they have to pick patches out from among the series (if 
> > > indeed any will bother
> > > doing that).
> > Yeah, maybe it would have been better to send individual patches.
> > 
> > From my point of view it's a series because the patches are related (I
> > did a git format-patch from my local branch). But for the maintainers
> > point of view, they are individual patches.
> 
> And the maintainers view is what matters here, if you wish to get your
> patches reviewed and accepted...

Mainly I'd just like to know which you're asking for.  Do you want me to
apply this, or to ACK it so someone else can?  If it's sent as a series
I tend to assume the latter.

But in this case I'm assuming it's the former, so I'll pick up the nfsd
one

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

[Intel-gfx] [PATCH v2] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

[Harsha Sharma]

Replace instances of drm_framebuffer_reference/unreference() with
*_get/put() suffixes and drm_dev_unref with *_put() suffix
because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
Done with following coccinelle semantic patch

@@ 
expression ex; 
@@ 

( 
-drm_framebuffer_unreference(ex); 
+drm_framebuffer_put(ex); 
| 
-drm_dev_unref(ex); 
+drm_dev_put(ex); 
| 
-drm_framebuffer_reference(ex); 
+drm_framebuffer_get(ex); 
) 


Signed-off-by: Harsha Sharma 
---
Changes in v2:
 -Added coccinelle patch in log message 
 -cc to all driver-specific mailing lists

 drivers/gpu/drm/i915/i915_pci.c|  2 +-
 drivers/gpu/drm/i915/intel_display.c   | 10 +-
 drivers/gpu/drm/i915/intel_fbdev.c |  4 ++--
 drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_request.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
 10 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 09d97e0..2f106cc 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -510,7 +510,7 @@ static void i915_pci_remove(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
 
i915_driver_unload(dev);
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
 }
 
 static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id 
*ent)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f172755..92f8304 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2856,7 +2856,7 @@ static int skl_format_to_fourcc(int format, bool 
rgb_order, bool alpha)
 
if (intel_plane_ggtt_offset(state) == plane_config->base) {
fb = c->primary->fb;
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
goto valid_fb;
}
}
@@ -2887,7 +2887,7 @@ static int skl_format_to_fourcc(int format, bool 
rgb_order, bool alpha)
  intel_crtc->pipe, PTR_ERR(intel_state->vma));
 
intel_state->vma = NULL;
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
return;
}
 
@@ -2908,7 +2908,7 @@ static int skl_format_to_fourcc(int format, bool 
rgb_order, bool alpha)
if (i915_gem_object_is_tiled(obj))
dev_priv->preserve_bios_swizzle = true;
 
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
primary->fb = primary->state->fb = fb;
primary->crtc = primary->state->crtc = _crtc->base;
 
@@ -9847,7 +9847,7 @@ struct drm_framebuffer *
if (obj->base.size < mode->vdisplay * fb->pitches[0])
return NULL;
 
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
return fb;
 #else
return NULL;
@@ -10028,7 +10028,7 @@ int intel_get_load_detect_pipe(struct drm_connector 
*connector,
if (ret)
goto fail;
 
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
 
ret = drm_atomic_set_mode_for_crtc(_state->base, mode);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 262e75c..1ff7149 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -189,7 +189,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
  " releasing it\n",
  intel_fb->base.width, intel_fb->base.height,
  sizes->fb_width, sizes->fb_height);
-   drm_framebuffer_unreference(_fb->base);
+   drm_framebuffer_put(_fb->base);
intel_fb = ifbdev->fb = NULL;
}
if (!intel_fb || WARN_ON(!intel_fb->obj)) {
@@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8;
ifbdev->fb = fb;
 
-   drm_framebuffer_reference(>fb->base);
+   drm_framebuffer_put(>fb->base);
 
/* Final pass to check if any active pipes don't have fbs */
for_each_crtc(dev, crtc) {
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c
index 89dc25a..a7055b1 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c
@@ -389,7 +389,7 @@ int i915_gem_dmabuf_mock_selftests(void)
 
err = 

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Tetsuo Handa]

Michal Hocko wrote:
> [Hmm, I do not see the original patch which this has been a reply to]

urbl.hostedemail.com and b.barracudacentral.org blocked my IP address,
and the rest are "Recipient address rejected: Greylisted" or
"Deferred: 451-4.3.0 Multiple destination domains per transaction is 
unsupported.",
and after all dropped at the servers. Sad...

> 
> On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote:
> > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote:
> > > Tetsuo Handa wrote:
> > > > Michael S. Tsirkin wrote:
> > > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote:
> > > > > > Hello.
> > > > > > 
> > > > > > I noticed that virtio_balloon is using register_oom_notifier() and
> > > > > > leak_balloon() from virtballoon_oom_notify() might depend on
> > > > > > __GFP_DIRECT_RECLAIM memory allocation.
> > > > > > 
> > > > > > In leak_balloon(), mutex_lock(>balloon_lock) is called in order 
> > > > > > to
> > > > > > serialize against fill_balloon(). But in fill_balloon(),
> > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | 
> > > > > > __GFP_NORETRY) is
> > > > > > called with vb->balloon_lock mutex held. Since 
> > > > > > GFP_HIGHUSER[_MOVABLE] implies
> > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt 
> > > > > > might
> > > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY 
> > > > > > memory
> > > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation 
> > > > > > can reach
> > > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call 
> > > > > > out_of_memory().
> > > > > > And leak_balloon() is called by virtballoon_oom_notify() via
> > > > > > blocking_notifier_call_chain() callback when vb->balloon_lock mutex 
> > > > > > is already
> > > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is 
> > > > > > specified,
> > > > > > fill_balloon() can indirectly get stuck waiting for 
> > > > > > vb->balloon_lock mutex
> > > > > > at leak_balloon().
> 
> This is really nasty! And I would argue that this is an abuse of the oom
> notifier interface from the virtio code. OOM notifiers are an ugly hack
> on its own but all its users have to be really careful to not depend on
> any allocation request because that is a straight deadlock situation.

Please describe such warning at
"int register_oom_notifier(struct notifier_block *nb)" definition.

> 
> I do not think that making oom notifier API more complex is the way to
> go. Can we simply change the lock to try_lock?

Using mutex_trylock(>balloon_lock) alone is not sufficient. Inside the
mutex, __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation attempt is used
which will fail to make progress due to oom_lock already held. Therefore,
virtballoon_oom_notify() needs to guarantee that all allocation attempts use
GFP_NOWAIT when called from virtballoon_oom_notify().

virtballoon_oom_notify() can guarantee GFP_NOIO using 
memalloc_noio_{save,restore}()
(which is currently missing because blocking_notifier_call_chain() might be 
called by
GFP_NOIO allocation request (e.g. disk_events_workfn)). But there is no
memalloc_nodirectreclaim_{save,restore}() for guaranteeing GFP_NOWAIT is used.
virtballoon_oom_notify() will need to use some flag and switch GFP_NOWAIT and
GFP_KERNEL based on that flag. I worry that such approach is prone to oversight.

>If the lock is held we
> would simply fall back to the normal OOM handling. As a follow up it
> would be great if virtio could use some other form of aging e.g.
> shrinker.
> -- 
> Michal Hocko
> SUSE Labs
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/glk, cnl: Implement WaDisableScalarClockGating

[Rodrigo Vivi]

On Mon, Oct 02, 2017 at 07:55:57AM +, Imre Deak wrote:
> On GLK and CNL enabling a pipe with its pipe scaler enabled will result
> in a FIFO underrun. This happens only once after driver loading or
> system/runtime resume, more specifically after power well 1 gets
> enabled; subsequent modesets seem to be free of underruns. The BSpec
> workaround for this is to disable the pipe scaler clock gating for the
> duration of modeset. Based on my tests disabling clock gating must be
> done before enabling pipe scaling and we can re-enable it after the pipe
> is enabled and one vblank has passed.
> 
> For consistency I also checked if plane scaling would cause the same
> problem, but that doesn't seem to trigger this problem.
> 
> The patch is based on an earlier version from Ander.
> 
> v2 (Rodrigo):
> - Set also CLKGATE_DIS_PSL bits 8 and 9.
> - Add also the BSpec workaround ID.

Thanks for this and for the explanation around the places where
we need to protect.
They make sense.

> 
> Cc: Ander Conselvan de Oliveira 
> Cc: Rodrigo Vivi 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100302
> Signed-off-by: Imre Deak 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 10 ++
>  drivers/gpu/drm/i915/intel_display.c | 26 ++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ee0d4f14ac98..39ad9327e2a0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3819,6 +3819,16 @@ enum {
>  #define   PWM2_GATING_DIS(1 << 14)
>  #define   PWM1_GATING_DIS(1 << 13)
>  
> +#define _CLKGATE_DIS_PSL_A   0x46520
> +#define _CLKGATE_DIS_PSL_B   0x46524
> +#define _CLKGATE_DIS_PSL_C   0x46528
> +#define   DPF_GATING_DIS (1 << 10)
> +#define   DPF_RAM_GATING_DIS (1 << 9)
> +#define   DPFR_GATING_DIS(1 << 8)
> +
> +#define CLKGATE_DIS_PSL(pipe) \
> + _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B)
> +
>  /*
>   * GEN10 clock gating regs
>   */
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c4b224a3a0ee..b7a6ddc6a66d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5459,6 +5459,20 @@ static bool hsw_crtc_supports_ips(struct intel_crtc 
> *crtc)
>   return HAS_IPS(to_i915(crtc->base.dev)) && crtc->pipe == PIPE_A;
>  }
>  
> +static void glk_pipe_scaler_clock_gating_wa(struct drm_i915_private 
> *dev_priv,
> + enum pipe pipe, bool apply)
> +{
> + u32 val = I915_READ(CLKGATE_DIS_PSL(pipe));
> + u32 mask = DPF_GATING_DIS | DPF_RAM_GATING_DIS | DPFR_GATING_DIS;
> +
> + if (apply)
> + val |= mask;
> + else
> + val &= ~mask;
> +
> + I915_WRITE(CLKGATE_DIS_PSL(pipe), val);
> +}
> +
>  static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
>   struct drm_atomic_state *old_state)
>  {
> @@ -5469,6 +5483,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
>   struct intel_atomic_state *old_intel_state =
>   to_intel_atomic_state(old_state);
> + bool psl_clkgate_wa;
>  
>   if (WARN_ON(intel_crtc->active))
>   return;
> @@ -5522,6 +5537,12 @@ static void haswell_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   if (!transcoder_is_dsi(cpu_transcoder))
>   intel_ddi_enable_pipe_clock(pipe_config);
>  
> + /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
> + psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> +  intel_crtc->config->pch_pfit.enabled;
> + if (psl_clkgate_wa)
> + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
> +
>   if (INTEL_GEN(dev_priv) >= 9)
>   skylake_pfit_enable(intel_crtc);
>   else
> @@ -,6 +5576,11 @@ static void haswell_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>  
>   intel_encoders_enable(crtc, pipe_config, old_state);
>  
> + if (psl_clkgate_wa) {
> + intel_wait_for_vblank(dev_priv, pipe);
> + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false);
> + }
> +
>   if (intel_crtc->config->has_pch_encoder) {
>   intel_wait_for_vblank(dev_priv, pipe);
>   intel_wait_for_vblank(dev_priv, pipe);
> -- 
> 2.13.2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH] dim: Add helpers to move fixes branches up.

[Rodrigo Vivi]

One of main doubts I had when starting maintaining the
fixes branches was when to move them, but also how, to-where,
and when avoid moving and stay on the current one.

So this scripts aims to avoid doubts and mistakes on fixes
maintainance besides making all bases more clear and
standardized.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
---
 dim | 50 ++
 dim.rst | 13 +
 2 files changed, 63 insertions(+)

diff --git a/dim b/dim
index fc16d114632f..8643bafcd2a5 100755
--- a/dim
+++ b/dim
@@ -918,6 +918,56 @@ function dim_apply_pull
return $rv
 }
 
+function rebase_branch
+{
+   local branch newbase
+
+   branch=${1:?$usage}
+   shift
+   newbase=${1:?$usage}
+   shift
+
+   assert_branch $branch
+   assert_repo_clean
+
+   $DRY git rebase $newbase "$@"
+}
+
+dim_alias_rf=rebase-fixes
+function dim_rebase_fixes
+{
+   local tag commit
+
+   commit=$(git rev-list --tags --max-count=1 --remotes=$DIM_DRM_INTEL)
+   tag=$(git describe --tags $commit)
+
+   if [[ $tag != *"-rc"* ]]; then
+   echoerr "Tag $tag is not an -rc one."
+   return 1;
+   fi
+
+   rebase_branch drm-intel-fixes $tag "$@"
+
+   if [ $DRY ]; then
+   return 0;
+   fi
+
+   if [ $(git rev-parse HEAD) != $commit ]; then
+   git reset --hard $DIM_DRM_INTEL_REMOTE/drm-intel-fixes
+   echoerr "ERROR: fixes didn't fully propagated yet, aborting"
+   fi
+}
+
+dim_alias_rnf=rebase-next-fixes
+function dim_rebase_next_fixes
+{
+   local dim_drm_upstream_remote
+
+   dim_drm_upstream_remote=$(url_to_remote $drm_upstream_git)
+
+   rebase_branch drm-intel-next-fixes $dim_drm_upstream_remote/drm-next 
"$@"
+}
+
 function dim_backmerge
 {
local branch upstream patch_file
diff --git a/dim.rst b/dim.rst
index 65e652e8bc75..a53ef8aa67e2 100644
--- a/dim.rst
+++ b/dim.rst
@@ -376,6 +376,19 @@ apply-pull *branch*
 ---
 Reads a pull request mail from stdin and merges it into the given *branch*.
 
+rebase-fixes
+
+Rebases drm-intel-fixes to latest Linus tag.
+This command is to be used following a Linus "-rc" tag, in order to move
+drm-intel-fixes branch up.
+It fails if tag is not an -rc tag.
+It fails if your current fixes didn't fully propagated yet.
+
+rebase-fixes-next
+-
+Rebases drm-intel-next queued into drm-next.
+This command is to be used after drm-next is closed for new features.
+
 backmerge *branch* *upstream*
 -
 
-- 
2.13.5

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

Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro

[Zhi Wang]

Thanks for the patch! :)

2017-10-01 22:30 GMT+03:00 Jérémy Lefaure :

> Hi everyone,
> Using ARRAY_SIZE improves the code readability. I used coccinelle (I
> made a change to the array_size.cocci file [1]) to find several places
> where ARRAY_SIZE could be used instead of other macros or sizeof
> division.
>
> I tried to divide the changes into a patch per subsystem (excepted for
> staging). If one of the patch should be split into several patches, let
> me know.
>
> In order to reduce the size of the To: and Cc: lines, each patch of the
> series is sent only to the maintainers and lists concerned by the patch.
> This cover letter is sent to every list concerned by this series.
>
> This series is based on linux-next next-20170929. Each patch has been
> tested by building the relevant files with W=1.
>
> This series contains the following patches:
> [PATCH 01/18] sound: use ARRAY_SIZE
> [PATCH 02/18] tracing/filter: use ARRAY_SIZE
> [PATCH 03/18] media: use ARRAY_SIZE
> [PATCH 04/18] IB/mlx5: Use ARRAY_SIZE
> [PATCH 05/18] net: use ARRAY_SIZE
> [PATCH 06/18] drm: use ARRAY_SIZE
> [PATCH 07/18] scsi: bfa: use ARRAY_SIZE
> [PATCH 08/18] ecryptfs: use ARRAY_SIZE
> [PATCH 09/18] nfsd: use ARRAY_SIZE
> [PATCH 10/18] orangefs: use ARRAY_SIZE
> [PATCH 11/18] dm space map metadata: use ARRAY_SIZE
> [PATCH 12/18] x86: use ARRAY_SIZE
> [PATCH 13/18] tpm: use ARRAY_SIZE
> [PATCH 14/18] ipmi: use ARRAY_SIZE
> [PATCH 15/18] acpi: use ARRAY_SIZE
> [PATCH 16/18] media: staging: atomisp: use ARRAY_SIZE
> [PATCH 17/18] staging: rtl8723bs: use ARRAY_SIZE
> [PATCH 18/18] staging: rtlwifi: use ARRAY_SIZE
>
>
> [1]: https://lkml.org/lkml/2017/9/13/689
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro

[Mauro Carvalho Chehab]

Em Sun, 1 Oct 2017 20:52:20 -0400
Jérémy Lefaure  escreveu:

> Anyway, I can tell to each maintainer that they can apply the patches
> they're concerned about and next time I may send individual patches.

In the case of media, we'll handle it as if they were individual ones.

Thanks,
Mauro
___
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: Fix DDI PHY init if it was already on

[Patchwork]

== Series Details ==

Series: drm/i915: Fix DDI PHY init if it was already on
URL   : https://patchwork.freedesktop.org/series/31265/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252 +1
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test prime_self_import:
Subgroup reimport-vs-gem_close-race:
fail   -> PASS   (shard-hsw) fdo#102655

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102655 https://bugs.freedesktop.org/show_bug.cgi?id=102655

shard-hswtotal:2429 pass:1332 dwarn:5   dfail:0   fail:9   skip:1083 
time:10107s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Guc code reorg

[Patchwork]

== Series Details ==

Series: drm/i915: Guc code reorg
URL   : https://patchwork.freedesktop.org/series/31266/
State : failure

== Summary ==

Series 31266v1 drm/i915: Guc code reorg
https://patchwork.freedesktop.org/api/1.0/series/31266/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default:
pass   -> INCOMPLETE (fi-cnl-y)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (fi-cfl-s) fdo#102673

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:457s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:475s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:392s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:564s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:287s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:528s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:529s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:539s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:535s
fi-cfl-s total:289  pass:255  dwarn:1   dfail:0   fail:1   skip:32  
time:547s
fi-cnl-y total:31   pass:21   dwarn:0   dfail:0   fail:0   skip:9  
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:440s
fi-glk-1 total:289  pass:257  dwarn:3   dfail:0   fail:0   skip:29  
time:592s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:442s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:422s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:462s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:500s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:506s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:578s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:491s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:590s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:658s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:525s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:523s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:473s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:582s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:442s

2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC 
integration manifest
5865a7ce87af drm/i915/guc: Move GuC declarations and functions into dedicated 
files
324ea799d3a0 drm/i915/guc: Move Guc early init into own function
b4dba4d4e843 drm/i915/huc: Move HuC declarations into dedicated header
aa0e401af78b drm/i915/uc: Create intel_uc_init_mmio
1569c70765ba drm/i915/uc: Move uC fw helper code into dedicated files
1d29ef25f7af drm/i915/uc: Drop unnecessary forward declaration

== Logs ==

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

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Michal Hocko]

On Mon 02-10-17 17:29:47, Michael S. Tsirkin wrote:
> On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote:
> > On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote:
> > > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote:
> > [...]
> > > > and some
> > > > other call path is allocating while holding the lock. But you seem to be
> > > > right and
> > > > leak_balloon
> > > >   tell_host
> > > > virtqueue_add_outbuf
> > > >   virtqueue_add
> > > > 
> > > > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should
> > > > try to allocate while we are in the OOM path. Michael, is there any way
> > > > to drop this?
> > > 
> > > Yes - in practice it won't ever allocate - that path is never taken
> > > with add_outbuf - it is for add_sgs only.
> > > 
> > > IMHO the issue is balloon inflation which needs to allocate
> > > memory. It does it under a mutex, and oom handler tries to take the
> > > same mutex.
> > 
> > try_lock for the oom notifier path should heal the problem then, righ?
> > At least for as a quick fix.
> 
> IMHO it definitely fixes the deadlock. But it does not fix the bug
> that balloon isn't sometimes deflated on oom even though the deflate on
> oom flag is set.

Yes, that would require a more sophisticated fix. And I would argue that
would require to drop oom handler and move deflate logic to a shrinker
to better scale with the memory pressure rather than act on the very
last moment.
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Michael S. Tsirkin]

On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote:
> On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote:
> > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote:
> [...]
> > > and some
> > > other call path is allocating while holding the lock. But you seem to be
> > > right and
> > > leak_balloon
> > >   tell_host
> > > virtqueue_add_outbuf
> > >   virtqueue_add
> > > 
> > > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should
> > > try to allocate while we are in the OOM path. Michael, is there any way
> > > to drop this?
> > 
> > Yes - in practice it won't ever allocate - that path is never taken
> > with add_outbuf - it is for add_sgs only.
> > 
> > IMHO the issue is balloon inflation which needs to allocate
> > memory. It does it under a mutex, and oom handler tries to take the
> > same mutex.
> 
> try_lock for the oom notifier path should heal the problem then, righ?
> At least for as a quick fix.

IMHO it definitely fixes the deadlock. But it does not fix the bug
that balloon isn't sometimes deflated on oom even though the deflate on
oom flag is set.

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

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Michal Hocko]

On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote:
> On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote:
[...]
> > and some
> > other call path is allocating while holding the lock. But you seem to be
> > right and
> > leak_balloon
> >   tell_host
> > virtqueue_add_outbuf
> >   virtqueue_add
> > 
> > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should
> > try to allocate while we are in the OOM path. Michael, is there any way
> > to drop this?
> 
> Yes - in practice it won't ever allocate - that path is never taken
> with add_outbuf - it is for add_sgs only.
> 
> IMHO the issue is balloon inflation which needs to allocate
> memory. It does it under a mutex, and oom handler tries to take the
> same mutex.

try_lock for the oom notifier path should heal the problem then, righ?
At least for as a quick fix.
-- 
Michal Hocko
SUSE Labs
___
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 DDI PHY init if it was already on

[Patchwork]

== Series Details ==

Series: drm/i915: Fix DDI PHY init if it was already on
URL   : https://patchwork.freedesktop.org/series/31265/
State : success

== Summary ==

Series 31265v1 drm/i915: Fix DDI PHY init if it was already on
https://patchwork.freedesktop.org/api/1.0/series/31265/revisions/1/mbox/

Test chamelium:
Subgroup hdmi-crc-fast:
pass   -> DMESG-WARN (fi-skl-6700k) fdo#103019
Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (fi-glk-1) fdo#102777 +2

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:459s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:476s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:393s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:578s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:289s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:537s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:542s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:549s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:528s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:565s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:636s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:442s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:592s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:438s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:424s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:470s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:508s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:583s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:501s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:592s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:654s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-6700k total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:533s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:529s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:475s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:585s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:437s

2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC 
integration manifest
2ae7aaa119a9 drm/i915: Fix DDI PHY init if it was already on

== Logs ==

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

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Michael S. Tsirkin]

On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote:
> On Mon 02-10-17 20:33:52, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > [Hmm, I do not see the original patch which this has been a reply to]
> > 
> > urbl.hostedemail.com and b.barracudacentral.org blocked my IP address,
> > and the rest are "Recipient address rejected: Greylisted" or
> > "Deferred: 451-4.3.0 Multiple destination domains per transaction is 
> > unsupported.",
> > and after all dropped at the servers. Sad...
> > 
> > > 
> > > On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote:
> > > > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote:
> > > > > Tetsuo Handa wrote:
> > > > > > Michael S. Tsirkin wrote:
> > > > > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote:
> > > > > > > > Hello.
> > > > > > > > 
> > > > > > > > I noticed that virtio_balloon is using register_oom_notifier() 
> > > > > > > > and
> > > > > > > > leak_balloon() from virtballoon_oom_notify() might depend on
> > > > > > > > __GFP_DIRECT_RECLAIM memory allocation.
> > > > > > > > 
> > > > > > > > In leak_balloon(), mutex_lock(>balloon_lock) is called in 
> > > > > > > > order to
> > > > > > > > serialize against fill_balloon(). But in fill_balloon(),
> > > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | 
> > > > > > > > __GFP_NORETRY) is
> > > > > > > > called with vb->balloon_lock mutex held. Since 
> > > > > > > > GFP_HIGHUSER[_MOVABLE] implies
> > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation 
> > > > > > > > attempt might
> > > > > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY 
> > > > > > > > memory
> > > > > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY 
> > > > > > > > allocation can reach
> > > > > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call 
> > > > > > > > out_of_memory().
> > > > > > > > And leak_balloon() is called by virtballoon_oom_notify() via
> > > > > > > > blocking_notifier_call_chain() callback when vb->balloon_lock 
> > > > > > > > mutex is already
> > > > > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is 
> > > > > > > > specified,
> > > > > > > > fill_balloon() can indirectly get stuck waiting for 
> > > > > > > > vb->balloon_lock mutex
> > > > > > > > at leak_balloon().
> > > 
> > > This is really nasty! And I would argue that this is an abuse of the oom
> > > notifier interface from the virtio code. OOM notifiers are an ugly hack
> > > on its own but all its users have to be really careful to not depend on
> > > any allocation request because that is a straight deadlock situation.
> > 
> > Please describe such warning at
> > "int register_oom_notifier(struct notifier_block *nb)" definition.
> 
> Yes, we can and should do that. Although I would prefer to simply
> document this API as deprecated. Care to send a patch? I am quite busy
> with other stuff.
> 
> > > I do not think that making oom notifier API more complex is the way to
> > > go. Can we simply change the lock to try_lock?
> > 
> > Using mutex_trylock(>balloon_lock) alone is not sufficient. Inside the
> > mutex, __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation attempt is used
> > which will fail to make progress due to oom_lock already held. Therefore,
> > virtballoon_oom_notify() needs to guarantee that all allocation attempts use
> > GFP_NOWAIT when called from virtballoon_oom_notify().
> 
> Ohh, I missed your point and thought the dependency is indirect

I do think this is the case. See below.


> and some
> other call path is allocating while holding the lock. But you seem to be
> right and
> leak_balloon
>   tell_host
> virtqueue_add_outbuf
>   virtqueue_add
> 
> can do GFP_KERNEL allocation and this is clearly wrong. Nobody should
> try to allocate while we are in the OOM path. Michael, is there any way
> to drop this?

Yes - in practice it won't ever allocate - that path is never taken
with add_outbuf - it is for add_sgs only.

IMHO the issue is balloon inflation which needs to allocate
memory. It does it under a mutex, and oom handler tries to take the
same mutex.


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

Re: [Intel-gfx] [PATCH 2/2] dim: sign pull-request tags if the GPG key is configured

[Jani Nikula]

On Mon, 02 Oct 2017, Jani Nikula  wrote:
> On Mon, 11 Sep 2017, Sean Paul  wrote:
>> On Mon, Sep 11, 2017 at 9:16 AM, Jani Nikula  wrote:
>>> Add new environment variable $DIM_GPG_KEYID for configuring the GPG key
>>> ID of the key to use for signing tags for pull requests. The tags will
>>> be signed if the key ID is set, otherwise annotated tags will be used
>>> like before.
>>>
>>> The drm-intel-testing tags are left unsigned, at least for now.
>>>
>>> Cc: Daniel Vetter 
>>> Cc: Joonas Lahtinen 
>>> Cc: Rodrigo Vivi 
>>> Cc: Sean Paul 
>>> Signed-off-by: Jani Nikula 
>>>
>>> ---
>>>
>>> BEWARE OF THE LEOPARD! I didn't actually test this. I will try it when I
>>> need to tag something next.
>>>
>>
>> Just comment out git push and test this?
>
> Finally got around to trying this out, works fine:
> https://cgit.freedesktop.org/drm-intel/tag/?id=drm-intel-next-2017-09-29
>
> The only snag is that now prep_pull_mail_overview() picks up the
> signature from the tag object to the overview too.
>
> Ack on merging these two out of the way, and fixing that separately (a
> tiny bit of sed)?

I pushed these two and the sed bit to strip signatures with Daniel's
acks.

You can now add

DIM_GPG_KEYID=

to ~/.dimrc to have dim sign the tags.

BR,
Jani.


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

[Intel-gfx] [PATCH v2 0/6] drm/i915: Guc code reorg

[Michal Wajdeczko]

Other pending series will try to fix current GuC code.
Lets move some functions to dedicated files now to
make place for these changes and preserve history.

v2: move guc files in one step (Joonas)
don't rename dev_priv (Joonas)
uc_init_mmio (Sagar)

Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Sagar Arun Kamble 

Michal Wajdeczko (5):
  drm/i915/uc: Drop unnecessary forward declaration
  drm/i915/uc: Move uC fw helper code into dedicated files
  drm/i915/huc: Move HuC declarations into dedicated header
  drm/i915/guc: Move Guc early init into own function
  drm/i915/guc: Move GuC declarations and functions into dedicated files

Sagar Arun Kamble (1):
  drm/i915/uc: Create intel_uc_init_mmio

 drivers/gpu/drm/i915/Makefile  |   2 +
 drivers/gpu/drm/i915/i915_drv.c|   2 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  94 -
 drivers/gpu/drm/i915/intel_guc.c   | 262 +
 drivers/gpu/drm/i915/intel_guc.h   | 178 +
 drivers/gpu/drm/i915/intel_huc.h   |  38 
 drivers/gpu/drm/i915/intel_uc.c| 301 +
 drivers/gpu/drm/i915/intel_uc.h| 229 +-
 drivers/gpu/drm/i915/intel_uc_fw.c | 178 +
 drivers/gpu/drm/i915/intel_uc_fw.h |  95 +
 10 files changed, 766 insertions(+), 613 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.c
 create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.h

-- 
2.7.4

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

[Intel-gfx] [PATCH v2 3/6] drm/i915/uc: Create intel_uc_init_mmio

[Michal Wajdeczko]

From: Sagar Arun Kamble 

This patch adds new function intel_uc_init_mmio which will initialize
MMIO access related variables prior to uc load/init.

v2: Removed unnecessary export of guc_send_init_regs. Created
intel_uc_init_mmio that currently wraps guc_init_send_regs. (Michal)

Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 ++
 drivers/gpu/drm/i915/intel_uc.c | 7 +--
 drivers/gpu/drm/i915/intel_uc.h | 1 +
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5cc2434..74a456f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1007,6 +1007,8 @@ static int i915_driver_init_mmio(struct drm_i915_private 
*dev_priv)
 
intel_uncore_init(dev_priv);
 
+   intel_uc_init_mmio(dev_priv);
+
ret = intel_engines_init_mmio(dev_priv);
if (ret)
goto err_uncore;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 201d23e..d921509 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -137,6 +137,11 @@ static void guc_init_send_regs(struct intel_guc *guc)
guc->send_regs.fw_domains = fw_domains;
 }
 
+void intel_uc_init_mmio(struct drm_i915_private *dev_priv)
+{
+   guc_init_send_regs(_priv->guc);
+}
+
 static void guc_capture_load_err_log(struct intel_guc *guc)
 {
if (!guc->log.vma || i915_modparams.guc_log_level < 0)
@@ -158,8 +163,6 @@ static int guc_enable_communication(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
-   guc_init_send_regs(guc);
-
if (HAS_GUC_CT(dev_priv))
return intel_guc_enable_ct(guc);
 
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index d111f79..f0d5a3f 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -137,6 +137,7 @@ struct intel_huc {
 /* intel_uc.c */
 void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
+void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
 void intel_uc_init_fw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 5/6] drm/i915/guc: Move Guc early init into own function

[Michal Wajdeczko]

We don't want to make aggregate uc functions to be too detailed.
This will also make future patch easier.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index d921509..616e0f1 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -88,10 +88,8 @@ static void gen8_guc_raise_irq(struct intel_guc *guc)
I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
 }
 
-void intel_uc_init_early(struct drm_i915_private *dev_priv)
+static void guc_init_early(struct intel_guc *guc)
 {
-   struct intel_guc *guc = _priv->guc;
-
intel_guc_ct_init_early(>ct);
 
mutex_init(>send_mutex);
@@ -99,6 +97,11 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
guc->notify = gen8_guc_raise_irq;
 }
 
+void intel_uc_init_early(struct drm_i915_private *dev_priv)
+{
+   guc_init_early(_priv->guc);
+}
+
 void intel_uc_init_fw(struct drm_i915_private *dev_priv)
 {
i915_fetch_uc_fw(dev_priv, _priv->huc.fw);
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 6/6] drm/i915/guc: Move GuC declarations and functions into dedicated files

[Michal Wajdeczko]

We want to keep GuC specific code in separated files.

v2: move all functions in single patch (Joonas)
fix old checkpatch issues (Sagar)

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble  #1
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  94 ---
 drivers/gpu/drm/i915/intel_guc.c   | 262 +
 drivers/gpu/drm/i915/intel_guc.h   | 178 
 drivers/gpu/drm/i915/intel_uc.c| 146 +---
 drivers/gpu/drm/i915/intel_uc.h| 146 +---
 6 files changed, 444 insertions(+), 383 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4850f26..51d0d29 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -60,6 +60,7 @@ i915-y += i915_cmd_parser.o \
 # general-purpose microcontroller (GuC) support
 i915-y += intel_uc.o \
  intel_uc_fw.o \
+ intel_guc.o \
  intel_guc_ct.o \
  intel_guc_log.o \
  intel_guc_loader.o \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 04f1281..89e2a9c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -643,48 +643,6 @@ static void i915_guc_irq_handler(unsigned long data)
  * path of i915_guc_submit() above.
  */
 
-/**
- * intel_guc_allocate_vma() - Allocate a GGTT VMA for GuC usage
- * @guc:   the guc
- * @size:  size of area to allocate (both virtual space and memory)
- *
- * This is a wrapper to create an object for use with the GuC. In order to
- * use it inside the GuC, an object needs to be pinned lifetime, so we allocate
- * both some backing storage and a range inside the Global GTT. We must pin
- * it in the GGTT somewhere other than than [0, GUC_WOPCM_TOP) because that
- * range is reserved inside GuC.
- *
- * Return: A i915_vma if successful, otherwise an ERR_PTR.
- */
-struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size)
-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   struct drm_i915_gem_object *obj;
-   struct i915_vma *vma;
-   int ret;
-
-   obj = i915_gem_object_create(dev_priv, size);
-   if (IS_ERR(obj))
-   return ERR_CAST(obj);
-
-   vma = i915_vma_instance(obj, _priv->ggtt.base, NULL);
-   if (IS_ERR(vma))
-   goto err;
-
-   ret = i915_vma_pin(vma, 0, PAGE_SIZE,
-  PIN_GLOBAL | PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
-   if (ret) {
-   vma = ERR_PTR(ret);
-   goto err;
-   }
-
-   return vma;
-
-err:
-   i915_gem_object_put(obj);
-   return vma;
-}
-
 /* Check that a doorbell register is in the expected state */
 static bool doorbell_ok(struct intel_guc *guc, u16 db_id)
 {
@@ -1212,55 +1170,3 @@ void i915_guc_submission_disable(struct drm_i915_private 
*dev_priv)
guc_client_free(guc->execbuf_client);
guc->execbuf_client = NULL;
 }
-
-/**
- * intel_guc_suspend() - notify GuC entering suspend state
- * @dev_priv:  i915 device private
- */
-int intel_guc_suspend(struct drm_i915_private *dev_priv)
-{
-   struct intel_guc *guc = _priv->guc;
-   struct i915_gem_context *ctx;
-   u32 data[3];
-
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
-   return 0;
-
-   gen9_disable_guc_interrupts(dev_priv);
-
-   ctx = dev_priv->kernel_context;
-
-   data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
-   /* any value greater than GUC_POWER_D0 */
-   data[1] = GUC_POWER_D1;
-   /* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
-
-   return intel_guc_send(guc, data, ARRAY_SIZE(data));
-}
-
-/**
- * intel_guc_resume() - notify GuC resuming from suspend state
- * @dev_priv:  i915 device private
- */
-int intel_guc_resume(struct drm_i915_private *dev_priv)
-{
-   struct intel_guc *guc = _priv->guc;
-   struct i915_gem_context *ctx;
-   u32 data[3];
-
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
-   return 0;
-
-   if (i915_modparams.guc_log_level >= 0)
-   gen9_enable_guc_interrupts(dev_priv);
-
-   ctx = dev_priv->kernel_context;
-
-   data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
-   data[1] = GUC_POWER_D0;
-   /* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
-
-   return intel_guc_send(guc, data, ARRAY_SIZE(data));
-}

[Intel-gfx] [PATCH v2 4/6] drm/i915/huc: Move HuC declarations into dedicated header

[Michal Wajdeczko]

We want to keep each uC specific code in separate files.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_huc.h | 38 ++
 drivers/gpu/drm/i915/intel_uc.h  | 13 +
 2 files changed, 39 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h

diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
new file mode 100644
index 000..998912e
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright © 2014-2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+#ifndef _INTEL_HUC_H_
+#define _INTEL_HUC_H_
+
+struct intel_huc {
+   /* Generic uC firmware management */
+   struct intel_uc_fw fw;
+
+   /* HuC-specific additions */
+};
+
+void intel_huc_select_fw(struct intel_huc *huc);
+void intel_huc_init_hw(struct intel_huc *huc);
+void intel_huc_auth(struct intel_huc *huc);
+
+#endif
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f0d5a3f..4fa091e 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -30,6 +30,7 @@
 #include "intel_ringbuffer.h"
 #include "intel_guc_ct.h"
 #include "i915_vma.h"
+#include "intel_huc.h"
 
 /*
  * This structure primarily describes the GEM object shared with the GuC.
@@ -127,13 +128,6 @@ struct intel_guc {
void (*notify)(struct intel_guc *guc);
 };
 
-struct intel_huc {
-   /* Generic uC firmware management */
-   struct intel_uc_fw fw;
-
-   /* HuC-specific additions */
-};
-
 /* intel_uc.c */
 void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
@@ -186,9 +180,4 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
return offset;
 }
 
-/* intel_huc.c */
-void intel_huc_select_fw(struct intel_huc *huc);
-void intel_huc_init_hw(struct intel_huc *huc);
-void intel_huc_auth(struct intel_huc *huc);
-
 #endif
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 2/6] drm/i915/uc: Move uC fw helper code into dedicated files

[Michal Wajdeczko]

This is a prerequisite to unblock next steps.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/intel_uc.c| 159 +
 drivers/gpu/drm/i915/intel_uc.h|  67 +-
 drivers/gpu/drm/i915/intel_uc_fw.c | 178 +
 drivers/gpu/drm/i915/intel_uc_fw.h |  95 
 5 files changed, 279 insertions(+), 221 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.c
 create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5182e3d..4850f26 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -59,6 +59,7 @@ i915-y += i915_cmd_parser.o \
 
 # general-purpose microcontroller (GuC) support
 i915-y += intel_uc.o \
+ intel_uc_fw.o \
  intel_guc_ct.o \
  intel_guc_log.o \
  intel_guc_loader.o \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2774778..201d23e 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -26,19 +26,6 @@
 #include "intel_uc.h"
 #include 
 
-/* Cleans up uC firmware by releasing the firmware GEM obj.
- */
-static void __intel_uc_fw_fini(struct intel_uc_fw *uc_fw)
-{
-   struct drm_i915_gem_object *obj;
-
-   obj = fetch_and_zero(_fw->obj);
-   if (obj)
-   i915_gem_object_put(obj);
-
-   uc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE;
-}
-
 /* Reset GuC providing us with fresh state for both GuC and HuC.
  */
 static int __intel_uc_reset_hw(struct drm_i915_private *dev_priv)
@@ -112,154 +99,16 @@ void intel_uc_init_early(struct drm_i915_private 
*dev_priv)
guc->notify = gen8_guc_raise_irq;
 }
 
-static void fetch_uc_fw(struct drm_i915_private *dev_priv,
-   struct intel_uc_fw *uc_fw)
-{
-   struct pci_dev *pdev = dev_priv->drm.pdev;
-   struct drm_i915_gem_object *obj;
-   const struct firmware *fw = NULL;
-   struct uc_css_header *css;
-   size_t size;
-   int err;
-
-   if (!uc_fw->path)
-   return;
-
-   uc_fw->fetch_status = INTEL_UC_FIRMWARE_PENDING;
-
-   DRM_DEBUG_DRIVER("before requesting firmware: uC fw fetch status %s\n",
-intel_uc_fw_status_repr(uc_fw->fetch_status));
-
-   err = request_firmware(, uc_fw->path, >dev);
-   if (err)
-   goto fail;
-   if (!fw)
-   goto fail;
-
-   DRM_DEBUG_DRIVER("fetch uC fw from %s succeeded, fw %p\n",
-uc_fw->path, fw);
-
-   /* Check the size of the blob before examining buffer contents */
-   if (fw->size < sizeof(struct uc_css_header)) {
-   DRM_NOTE("Firmware header is missing\n");
-   goto fail;
-   }
-
-   css = (struct uc_css_header *)fw->data;
-
-   /* Firmware bits always start from header */
-   uc_fw->header_offset = 0;
-   uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
- css->key_size_dw - css->exponent_size_dw) * 
sizeof(u32);
-
-   if (uc_fw->header_size != sizeof(struct uc_css_header)) {
-   DRM_NOTE("CSS header definition mismatch\n");
-   goto fail;
-   }
-
-   /* then, uCode */
-   uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
-   uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
-
-   /* now RSA */
-   if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_NOTE("RSA key size is bad\n");
-   goto fail;
-   }
-   uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size;
-   uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
-
-   /* At least, it should have header, uCode and RSA. Size of all three. */
-   size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
-   if (fw->size < size) {
-   DRM_NOTE("Missing firmware components\n");
-   goto fail;
-   }
-
-   /*
-* The GuC firmware image has the version number embedded at a
-* well-known offset within the firmware blob; note that major / minor
-* version are TWO bytes each (i.e. u16), although all pointers and
-* offsets are defined in terms of bytes (u8).
-*/
-   switch (uc_fw->type) {
-   case INTEL_UC_FW_TYPE_GUC:
-   /* Header and uCode will be loaded to WOPCM. Size of the two. */
-   size = uc_fw->header_size + uc_fw->ucode_size;
-
-   /* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
-   if (size > 

[Intel-gfx] [PATCH v2 1/6] drm/i915/uc: Drop unnecessary forward declaration

[Michal Wajdeczko]

We don't need it here.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 6966349..38ec880 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -30,8 +30,6 @@
 #include "intel_guc_ct.h"
 #include "i915_vma.h"
 
-struct drm_i915_gem_request;
-
 /*
  * This structure primarily describes the GEM object shared with the GuC.
  * The specs sometimes refer to this object as a "GuC context", but we use
-- 
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: Fix DDI PHY init if it was already on

[Imre Deak]

The common lane power down flag of a DPIO PHY has a funky semantic:
after the initial enabling of the PHY (so from a disabled state) this
flag will be clear. It will be set only after the PHY will be used for
the first time (for instance due to enabling the corresponding pipe) and
then become unused (due to disabling the pipe). During the initial PHY
enablement we don't know which of the above phases we are in, so move
the check for the flag where this is known, the HW readout code. This is
where the rest of lane power down status checks are done anyway.

This fixes at least a problem on GLK where after module reloading, the
common lane power down flag of PHY1 is set, but the PHY is actually
powered-on and properly set up. The GRC readout code for other PHYs will
hence think that PHY1 is not powered initially and disable it after the
GRC readout. This will cause the AUX power well related to PHY1 to get
disabled in a stuck state, timing out when we try to enable it later.

Cc: Ville Syrjala 
Fixes: e93da0a0137b ("drm/i915/bxt: Sanitiy check the PHY lane power down 
status")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102777
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_ddi.c  |  3 ++-
 drivers/gpu/drm/i915/intel_dpio_phy.c | 20 
 2 files changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 93cbbcbbc193..65f4b6786791 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1713,7 +1713,8 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
 out:
if (ret && IS_GEN9_LP(dev_priv)) {
tmp = I915_READ(BXT_PHY_CTL(port));
-   if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
+   if ((tmp & (BXT_PHY_CMNLANE_POWERDOWN_ACK |
+   BXT_PHY_LANE_POWERDOWN_ACK |
BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED)
DRM_ERROR("Port %c enabled but PHY powered down? "
  "(PHY_CTL %08x)\n", port_name(port), tmp);
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 09b670929786..de38d014ed39 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -208,12 +208,6 @@ static const struct bxt_ddi_phy_info glk_ddi_phy_info[] = {
},
 };
 
-static u32 bxt_phy_port_mask(const struct bxt_ddi_phy_info *phy_info)
-{
-   return (phy_info->dual_channel * BIT(phy_info->channel[DPIO_CH1].port)) 
|
-   BIT(phy_info->channel[DPIO_CH0].port);
-}
-
 static const struct bxt_ddi_phy_info *
 bxt_get_phy_list(struct drm_i915_private *dev_priv, int *count)
 {
@@ -313,7 +307,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
enum dpio_phy phy)
 {
const struct bxt_ddi_phy_info *phy_info;
-   enum port port;
 
phy_info = bxt_get_phy_info(dev_priv, phy);
 
@@ -335,19 +328,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
return false;
}
 
-   for_each_port_masked(port, bxt_phy_port_mask(phy_info)) {
-   u32 tmp = I915_READ(BXT_PHY_CTL(port));
-
-   if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
-   DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
-"for port %c powered down "
-"(PHY_CTL %08x)\n",
-phy, port_name(port), tmp);
-
-   return false;
-   }
-   }
-
return true;
 }
 
-- 
2.13.2

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

Re: [Intel-gfx] [PATCH 11/21] drm/i915: disable GTT cache for 2M pages

[Matthew Auld]

On 2 October 2017 at 13:31, Joonas Lahtinen
 wrote:
> On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
>> When SW enables the use of 2M/1G pages, it must disable the GTT cache.
>>
>> v2: don't disable for Cherryview which doesn't even support 48b PPGTT!
>>
>> v3: explicitly check that the system does support 2M/1G pages
>>
>> Signed-off-by: Matthew Auld 
>> Cc: Joonas Lahtinen 
>> Cc: Chris Wilson 
>> Cc: Mika Kuoppala 
>> Reviewed-by: Mika Kuoppala 
>
> 
>
>> @@ -8483,10 +8483,11 @@ static void bdw_init_clock_gating(struct 
>> drm_i915_private *dev_priv)
>>
>>   /*
>>* WaGttCachingOffByDefault:bdw
>> -  * GTT cache may not work with big pages, so if those
>> -  * are ever enabled GTT cache may need to be disabled.
>> +  * The GTT cache must be disabled if the system is using 2M/1G pages.
>>*/
>> - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
>> + I915_WRITE(HSW_GTT_CACHE_EN,
>> +HAS_PAGE_SIZES(dev_priv, I915_GTT_PAGE_SIZE_2M) ? 0 :
>> +GTT_CACHE_EN_ALL);
>
> Umm, this is mixing a known W/A with decision logic.
>
> bool can_use_gtt_cache = !HAS_PAGE_SIZES(dev_priv, 
> I915_GTT_PAGE_SIZE_2M);
>
> /* WaGttCachingOffByDefault:bdw */
> I915_WRITE(HSW_GTT_CACHE_EN, can_use_gtt_cache ? GTT_CACHE_EN_ALL : 
> 0);
>
> The big question is that if everyone else has GTT caching enabled by
> default, should not we actively be disabling it on other code paths?

AFAIK it's *disabled* by default, bdw and chv are the only platforms
which seek to enable it. I don't know why other platforms don't also
follow suit...

That WA is literally just: "WA to enable the caching if off by
defaultboth at driver init and Resume".

> I'm also feeling 'init_clock_gating' is not the best home for the code.
>
> We can find a new home later, but do separate the decision logic from
> the W/A.
>
> Also, do 1G pages imply 2M page support? It's bit on the theoritical
> side of science of course.

I just assume not, since it doesn't explicitly state that anywhere.

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

Re: [Intel-gfx] [PATCH 1/2] dim: use prep_pull_mail_overview for drm-intel-testing

[Jani Nikula]

On Mon, 02 Oct 2017, Daniel Vetter  wrote:
> On Mon, Oct 02, 2017 at 12:45:19PM +0300, Jani Nikula wrote:
>> It's not perfect or exactly the same, but prefer fewer lines of special
>> casing anyway.
>> 
>> Signed-off-by: Jani Nikula 
>
> Ack on both patches in this series.

Pushed, thanks.

BR,
Jani.

> -Daniel
>> ---
>>  dim | 8 ++--
>>  1 file changed, 2 insertions(+), 6 deletions(-)
>> 
>> diff --git a/dim b/dim
>> index bfa6ef010806..866a420d4ef6 100755
>> --- a/dim
>> +++ b/dim
>> @@ -1615,12 +1615,8 @@ function dim_update_next_continue
>>  The following changes tagged $tag_testing:
>>  
>>  HERE
>> -obj=$(git rev-parse $tag)
>> -if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then
>> -git cat-file -p $obj | tail -n+6 >> $req_file
>> -else
>> -echo "*** CHANGELOG OVERVIEW HERE ***" >> $req_file
>> -fi
>> +
>> +prep_pull_mail_overview "$tag" >> $req_file
>>  prep_pull_mail_signature >> $req_file
>>  
>>  $DRY $DIM_MUA -s "Updated drm-intel-testing" \
>> -- 
>> 2.11.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

Re: [Intel-gfx] [PATCH 1/2] dim: use prep_pull_mail_overview for drm-intel-testing

[Daniel Vetter]

On Mon, Oct 02, 2017 at 12:45:19PM +0300, Jani Nikula wrote:
> It's not perfect or exactly the same, but prefer fewer lines of special
> casing anyway.
> 
> Signed-off-by: Jani Nikula 

Ack on both patches in this series.
-Daniel
> ---
>  dim | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/dim b/dim
> index bfa6ef010806..866a420d4ef6 100755
> --- a/dim
> +++ b/dim
> @@ -1615,12 +1615,8 @@ function dim_update_next_continue
>   The following changes tagged $tag_testing:
>  
>   HERE
> - obj=$(git rev-parse $tag)
> - if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then
> - git cat-file -p $obj | tail -n+6 >> $req_file
> - else
> - echo "*** CHANGELOG OVERVIEW HERE ***" >> $req_file
> - fi
> +
> + prep_pull_mail_overview "$tag" >> $req_file
>   prep_pull_mail_signature >> $req_file
>  
>   $DRY $DIM_MUA -s "Updated drm-intel-testing" \
> -- 
> 2.11.0
> 

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

Re: [Intel-gfx] [PATCH i-g-t] meson: Follow suit with the renaming of kms_pipe_color

[Arkadiusz Hiler]

On Mon, Oct 02, 2017 at 01:50:05PM +0300, Petri Latvala wrote:
> CC: Maarten Lankhorst 
> Signed-off-by: Petri Latvala 
Reviewed-by: Arkadiusz Hiler 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.

[Jani Nikula]

On Thu, 28 Sep 2017, Rodrigo Vivi  wrote:
> Let's organize this in a way that it gets more obvious
> when looking to the platform colors and in a easier
> way to get inherited.
>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 9b54aafa2a0b..10537dcdd9c1 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -54,6 +54,8 @@
>   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
>  #define CHV_COLORS \
>   .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> +#define GLK_COLORS \
> + .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
>  
>  /* Keep in gen based order, and chronological order within a gen */
>  #define GEN2_FEATURES \
> @@ -495,7 +497,7 @@ static const struct intel_device_info 
> intel_geminilake_info __initconst = {
>   GEN9_LP_FEATURES,
>   .platform = INTEL_GEMINILAKE,
>   .ddb_size = 1024,
> - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> + GLK_COLORS

Please add he comma at the end.

>  };
>  
>  #define KBL_PLATFORM \
> @@ -543,7 +545,7 @@ static const struct intel_device_info 
> intel_coffeelake_gt3_info __initconst = {
>  #define GEN10_FEATURES \
>   GEN9_FEATURES, \
>   .ddb_size = 1024, \
> - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> + GLK_COLORS

Ditto.

BR,
Jani.

>  
>  static const struct intel_device_info intel_cannonlake_gt2_info __initconst 
> = {
>   GEN10_FEATURES,

-- 
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.IGT: success for meson: Follow suit with the renaming of kms_pipe_color

[Patchwork]

== Series Details ==

Series: meson: Follow suit with the renaming of kms_pipe_color
URL   : https://patchwork.freedesktop.org/series/31264/
State : success

== Summary ==

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> DMESG-WARN (shard-hsw) fdo#102886 +1
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

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

shard-hswtotal:2429 pass:1331 dwarn:5   dfail:0   fail:10  skip:1083 
time:10111s

== Logs ==

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

Re: [Intel-gfx] [PATCH 11/21] drm/i915: disable GTT cache for 2M pages

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
> When SW enables the use of 2M/1G pages, it must disable the GTT cache.
> 
> v2: don't disable for Cherryview which doesn't even support 48b PPGTT!
> 
> v3: explicitly check that the system does support 2M/1G pages
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Reviewed-by: Mika Kuoppala 



> @@ -8483,10 +8483,11 @@ static void bdw_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>  
>   /*
>* WaGttCachingOffByDefault:bdw
> -  * GTT cache may not work with big pages, so if those
> -  * are ever enabled GTT cache may need to be disabled.
> +  * The GTT cache must be disabled if the system is using 2M/1G pages.
>*/
> - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
> + I915_WRITE(HSW_GTT_CACHE_EN,
> +HAS_PAGE_SIZES(dev_priv, I915_GTT_PAGE_SIZE_2M) ? 0 :
> +GTT_CACHE_EN_ALL);

Umm, this is mixing a known W/A with decision logic.

bool can_use_gtt_cache = !HAS_PAGE_SIZES(dev_priv, 
I915_GTT_PAGE_SIZE_2M);

/* WaGttCachingOffByDefault:bdw */
I915_WRITE(HSW_GTT_CACHE_EN, can_use_gtt_cache ? GTT_CACHE_EN_ALL : 0);

The big question is that if everyone else has GTT caching enabled by
default, should not we actively be disabling it on other code paths?
I'm also feeling 'init_clock_gating' is not the best home for the code.

We can find a new home later, but do separate the decision logic from
the W/A.

Also, do 1G pages imply 2M page support? It's bit on the theoritical
side of science of course.

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

Re: [Intel-gfx] [PATCH 10/21] drm/i915: enable IPS bit for 64K pages

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
> Before we can enable 64K pages through the IPS bit, we must first enable
> it through MMIO, otherwise the page-walker will simply ignore it.
> 
> v2: add comment mentioning that 64K is BDW+
> 
> v3: move to more suitable home
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Reviewed-by: Mika Kuoppala 

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH i-g-t v4 4/7] lib/igt_kms: Rework connector properties to be more atomic, v2.

[Mika Kahola]

On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote:
> In the future I want to allow tests to commit more properties,
> but for this to work I have to fix all properties to work better
> with atomic commit. Instead of special casing each
> property make a bitmask for all property changed flags, and try to
> commit all properties.
> 
> Changs since v1:
> - Mention which properties we set to what.
> - Assert the property to be set is valid.
> 
> Signed-off-by: Maarten Lankhorst 
Reviewed-by: Mika Kahola 

> ---
>  lib/igt_kms.c| 44 +++---
> --
>  lib/igt_kms.h| 35 +++---
> --
>  tests/kms_atomic_interruptible.c |  4 ++--
>  tests/kms_panel_fitting.c|  2 +-
>  4 files changed, 45 insertions(+), 40 deletions(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index d25090b05c70..07d2074c2b1a 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -248,7 +248,7 @@ igt_atomic_fill_connector_props(igt_display_t
> *display, igt_output_t *output,
>   if (strcmp(prop->name, conn_prop_names[j])
> != 0)
>   continue;
>  
> - output->config.atomic_props_connector[j] =
> props->props[i];
> + output->props[j] = props->props[i];
>   break;
>   }
>  
> @@ -1834,7 +1834,7 @@ void igt_display_init(igt_display_t *display,
> int drm_fd)
>  
>   igt_output_refresh(output);
>  
> - output->config.pipe_changed = true;
> + igt_output_set_prop_changed(output,
> IGT_CONNECTOR_CRTC_ID);
>   }
>  
>   drmModeFreePlaneResources(plane_resources);
> @@ -2514,23 +2514,24 @@ static void
> igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe
>  static void igt_atomic_prepare_connector_commit(igt_output_t
> *output, drmModeAtomicReq *req)
>  {
>  
> - struct kmstest_connector_config *config = >config;
> + int i;
>  
> - if (config->connector_scaling_mode_changed)
> - igt_atomic_populate_connector_req(req, output,
> IGT_CONNECTOR_SCALING_MODE, config->connector_scaling_mode);
> + for (i = 0; i < IGT_NUM_CONNECTOR_PROPS; i++) {
> + if (!igt_output_is_prop_changed(output, i))
> + continue;
>  
> - if (config->pipe_changed) {
> - uint32_t crtc_id = 0;
> + /* it's an error to try an unsupported feature */
> + igt_assert(output->props[i]);
>  
> - if (output->config.pipe != PIPE_NONE)
> - crtc_id = output->config.crtc->crtc_id;
> + igt_debug("%s: Setting property \"%s\" to
> 0x%"PRIx64"/%"PRIi64"\n",
> +   igt_output_name(output),
> igt_connector_prop_names[i],
> +   output->values[i], output->values[i]);
>  
> - igt_atomic_populate_connector_req(req, output,
> IGT_CONNECTOR_CRTC_ID, crtc_id);
> + igt_assert_lt(0, drmModeAtomicAddProperty(req,
> +   output->config.connector-
> >connector_id,
> +   output->props[i],
> +   output->values[i]));
>   }
> - /*
> -  *  TODO: Add all other connector level properties
> here
> -  */
> -
>  }
>  
>  /*
> @@ -2625,11 +2626,10 @@ display_commit_changed(igt_display_t
> *display, enum igt_commit_style s)
>   for (i = 0; i < display->n_outputs; i++) {
>   igt_output_t *output = >outputs[i];
>  
> - if (s != COMMIT_UNIVERSAL)
> - output->config.pipe_changed = false;
> -
>   if (s == COMMIT_ATOMIC)
> - output-
> >config.connector_scaling_mode_changed = false;
> + output->changed = 0;
> + else if (s != COMMIT_UNIVERSAL)
> + igt_output_clear_prop_changed(output,
> IGT_CONNECTOR_CRTC_ID);
>   }
>  }
>  
> @@ -2873,18 +2873,16 @@ void igt_output_set_pipe(igt_output_t
> *output, enum pipe pipe)
>   if (pipe != PIPE_NONE)
>   display->pipes[pipe].mode_changed = true;
>  
> - output->config.pipe_changed = true;
> + igt_output_set_prop_value(output, IGT_CONNECTOR_CRTC_ID,
> pipe == PIPE_NONE ? 0 : display->pipes[pipe].crtc_id);
>  
>   igt_output_refresh(output);
>  }
>  
>  void igt_output_set_scaling_mode(igt_output_t *output, uint64_t
> scaling_mode)
>  {
> - output->config.connector_scaling_mode_changed = true;
> -
> - output->config.connector_scaling_mode = scaling_mode;
> + igt_output_set_prop_value(output,
> IGT_CONNECTOR_SCALING_MODE, scaling_mode);
>  
> - igt_require(output-
> >config.atomic_props_connector[IGT_CONNECTOR_SCALING_MODE]);
> + igt_require(output->props[IGT_CONNECTOR_SCALING_MODE]);
>  }
>  
>  igt_plane_t *igt_output_get_plane(igt_output_t 

Re: [Intel-gfx] [PATCH 09/21] drm/i915: align 64K objects to 2M

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
> We can't mix 64K and 4K pte's in the same page-table, so for now we
> align 64K objects to 2M to avoid any potential mixing. This is
> potentially wasteful but in reality shouldn't be too bad since this only
> applies to the virtual address space of a 48b PPGTT.
> 
> v2: don't separate logically connected ops
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 



> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -501,9 +501,18 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> alignment, u64 flags)
>   if (upper_32_bits(end) &&
>   vma->page_sizes.sg > I915_GTT_PAGE_SIZE) {

Here. See below.

>   u64 page_alignment =
> - rounddown_pow_of_two(vma->page_sizes.sg);
> + rounddown_pow_of_two(vma->page_sizes.sg |
> +  I915_GTT_PAGE_SIZE_2M);
>  
>   alignment = max(alignment, page_alignment);
> +
> + /*
> +  * We can't mix 64K and 4K PTEs in the same page-table 
> (2M
> +  * block), and so to avoid the ugliness and complexity 
> of
> +  * coloring we opt for just aligning 64K objects to 2M.
> +  */

This is about size, the alignment is happening above, I'd lift the
comment there.

> + if (vma->page_sizes.sg & I915_GTT_PAGE_SIZE_64K)
> + size = round_up(size, I915_GTT_PAGE_SIZE_2M);
>   }

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 08/21] drm/i915: align the vma start to the largest gtt page size

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
> For the 48b PPGTT try to align the vma start address to the required
> page size boundary to guarantee we use said page size in the gtt. If we
> are dealing with multiple page sizes, we can't guarantee anything and
> just align to the largest. For soft pinning and objects which need to be
> tightly packed into the lower 32bits we don't force any alignment.
> 
> v2: various improvements suggested by Chris
> 
> v3: use set_pages and better placement of page_sizes
> 
> v4: prefer upper_32_bits()
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 



> @@ -238,6 +241,8 @@ static void clear_pages(struct i915_vma *vma)
>   kfree(vma->pages);
>   }
>   vma->pages = NULL;
> +
> + memset(>page_sizes, 0, sizeof(struct i915_page_sizes));

sizeof(vma->page_sizes)

> @@ -2538,6 +2543,9 @@ static int ggtt_set_pages(struct i915_vma *vma)
>   if (ret)
>   return ret;
>  
> + vma->page_sizes.phys = vma->obj->mm.page_sizes.phys;
> + vma->page_sizes.sg = vma->obj->mm.page_sizes.sg;

Hmm, are we not able to assign vma->page_sizes =
vma->obj->mm.page_sizes?

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 07/21] drm/i915: introduce vm set_pages/clear_pages

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
> Move the setting/clearing of the vma->pages to a vm operation. Doing so
> neatens things up a little, but more importantly gives us a sane place
> to also set/clear the vma->pages_sizes, which we introduce later in
> preparation for supporting huge-pages.
> 
> v2: remove redundant vma->pages check
> 
> v3: GEM_BUG_ON(vma->pages) following i915_vma_remove
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 03/21] drm/i915/gemfs: enable THP

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
> Enable transparent-huge-pages through gemfs by mounting with
> huge=within_size.
> 
> v2: sprinkle within_size comment
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gemfs.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gemfs.c 
> b/drivers/gpu/drm/i915/i915_gemfs.c
> index 168d0bd98f60..b1b4d13d8f97 100644
> --- a/drivers/gpu/drm/i915/i915_gemfs.c
> +++ b/drivers/gpu/drm/i915/i915_gemfs.c
> @@ -24,6 +24,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "i915_drv.h"
>  #include "i915_gemfs.h"
> @@ -41,6 +42,26 @@ int i915_gemfs_init(struct drm_i915_private *i915)
>   if (IS_ERR(gemfs))
>   return PTR_ERR(gemfs);
>  
> + /*
> +  * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
> +  * likely 2M. Note that within_size may overallocate huge-pages, if say
> +  * we allocate an object of size 2M + 4K, but under memory pressure

Maybe append after "2M + 4K" "we may get 2M + 2M", to complete the
sentence.

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 02/21] drm/i915: introduce simple gemfs

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote:
> Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
> moves us away from the shmemfs shm_mnt, and gives us the much needed
> flexibility to do things like set our own mount options, namely huge=
> which should allow us to enable the use of transparent-huge-pages for
> our shmem backed objects.
> 
> v2: various improvements suggested by Joonas
> 
> v3: move gemfs instance to i915.mm and simplify now that we have
> file_setup_with_mnt
> 
> v4: fallback to tmpfs shm_mnt upon failure to setup gemfs
> 
> v5: make tmpfs fallback kinder
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Dave Hansen 
> Cc: Kirill A. Shutemov 
> Cc: Hugh Dickins 
> Cc: linux...@kvack.org



> @@ -4251,6 +4252,29 @@ static const struct drm_i915_gem_object_ops 
> i915_gem_object_ops = {
>   .pwrite = i915_gem_object_pwrite_gtt,
>  };
>  
> +static int i915_gem_object_create_shmem(struct drm_device *dev,
> + struct drm_gem_object *obj,
> + size_t size)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct file *filp;
> +
> + drm_gem_private_object_init(dev, obj, size);
> +
> + if (i915->mm.gemfs)
> + filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size,
> +  VM_NORESERVE);
> + else
> + filp = shmem_file_setup("i915", size, VM_NORESERVE);

Put that VM_NORESERVE to 'flags' variable.

> @@ -4915,6 +4939,9 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
>  
>   spin_lock_init(_priv->fb_tracking.lock);
>  
> + if (i915_gemfs_init(dev_priv))
> + DRM_NOTE("Unable to create a private tmpfs mountpoint, hugepage 
> support will be disabled.\n");

s/mountpoint/mount/, as we're not creating a directory. Maybe also
include the returned error for easier post-mortem?

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Michal Hocko]

On Mon 02-10-17 20:33:52, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > [Hmm, I do not see the original patch which this has been a reply to]
> 
> urbl.hostedemail.com and b.barracudacentral.org blocked my IP address,
> and the rest are "Recipient address rejected: Greylisted" or
> "Deferred: 451-4.3.0 Multiple destination domains per transaction is 
> unsupported.",
> and after all dropped at the servers. Sad...
> 
> > 
> > On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote:
> > > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote:
> > > > Tetsuo Handa wrote:
> > > > > Michael S. Tsirkin wrote:
> > > > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote:
> > > > > > > Hello.
> > > > > > > 
> > > > > > > I noticed that virtio_balloon is using register_oom_notifier() and
> > > > > > > leak_balloon() from virtballoon_oom_notify() might depend on
> > > > > > > __GFP_DIRECT_RECLAIM memory allocation.
> > > > > > > 
> > > > > > > In leak_balloon(), mutex_lock(>balloon_lock) is called in 
> > > > > > > order to
> > > > > > > serialize against fill_balloon(). But in fill_balloon(),
> > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | 
> > > > > > > __GFP_NORETRY) is
> > > > > > > called with vb->balloon_lock mutex held. Since 
> > > > > > > GFP_HIGHUSER[_MOVABLE] implies
> > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation 
> > > > > > > attempt might
> > > > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY 
> > > > > > > memory
> > > > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation 
> > > > > > > can reach
> > > > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call 
> > > > > > > out_of_memory().
> > > > > > > And leak_balloon() is called by virtballoon_oom_notify() via
> > > > > > > blocking_notifier_call_chain() callback when vb->balloon_lock 
> > > > > > > mutex is already
> > > > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is 
> > > > > > > specified,
> > > > > > > fill_balloon() can indirectly get stuck waiting for 
> > > > > > > vb->balloon_lock mutex
> > > > > > > at leak_balloon().
> > 
> > This is really nasty! And I would argue that this is an abuse of the oom
> > notifier interface from the virtio code. OOM notifiers are an ugly hack
> > on its own but all its users have to be really careful to not depend on
> > any allocation request because that is a straight deadlock situation.
> 
> Please describe such warning at
> "int register_oom_notifier(struct notifier_block *nb)" definition.

Yes, we can and should do that. Although I would prefer to simply
document this API as deprecated. Care to send a patch? I am quite busy
with other stuff.

> > I do not think that making oom notifier API more complex is the way to
> > go. Can we simply change the lock to try_lock?
> 
> Using mutex_trylock(>balloon_lock) alone is not sufficient. Inside the
> mutex, __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation attempt is used
> which will fail to make progress due to oom_lock already held. Therefore,
> virtballoon_oom_notify() needs to guarantee that all allocation attempts use
> GFP_NOWAIT when called from virtballoon_oom_notify().

Ohh, I missed your point and thought the dependency is indirect and some
other call path is allocating while holding the lock. But you seem to be
right and
leak_balloon
  tell_host
virtqueue_add_outbuf
  virtqueue_add

can do GFP_KERNEL allocation and this is clearly wrong. Nobody should
try to allocate while we are in the OOM path. Michael, is there any way
to drop this?
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for meson: Follow suit with the renaming of kms_pipe_color

[Patchwork]

== Series Details ==

Series: meson: Follow suit with the renaming of kms_pipe_color
URL   : https://patchwork.freedesktop.org/series/31264/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
1e99f8b8d2563d7f5c4e82932bab15abc5eacaef meson: Distribute meson build system 
files

with latest DRM-Tip kernel build CI_DRM_3162
2f14e319a2fd drm-tip: 2017y-10m-02d-09h-23m-23s UTC integration manifest

No testlist changes.

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:457s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:474s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:394s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:581s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:292s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:532s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:537s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:549s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:537s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:561s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:631s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:441s
fi-glk-1 total:289  pass:257  dwarn:3   dfail:0   fail:0   skip:29  
time:596s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:442s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:419s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:468s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:485s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:498s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:583s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:503s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:587s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:664s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:533s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:525s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:473s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:588s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:438s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Silence compiler warning for hsw_power_well_enable()

[Imre Deak]

On Mon, Oct 02, 2017 at 11:04:16AM +0100, Chris Wilson wrote:
> Not all compilers are able to determine that pg is guarded by wait_fuses
> and so may think that pg is used uninitialized.
> 
> Reported-by: Geert Uytterhoeven 
> Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute")
> Signed-off-by: Chris Wilson 
> Cc: Imre Deak 
> Cc: Arkadiusz Hiler 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 7933d1bc6a1c..de207c93c063 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -368,7 +368,7 @@ static void hsw_power_well_enable(struct drm_i915_private 
> *dev_priv,
>  {
>   enum i915_power_well_id id = power_well->id;
>   bool wait_fuses = power_well->hsw.has_fuses;
> - enum skl_power_gate pg;
> + enum skl_power_gate uninitialized_var(pg);
>   u32 val;
>  
>   if (wait_fuses) {
> -- 
> 2.14.2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM

[Joonas Lahtinen]

On Mon, 2017-10-02 at 11:23 +0100, Chris Wilson wrote:
> Quoting Joonas Lahtinen (2017-10-02 11:03:30)
> > On Sat, 2017-09-30 at 13:57 +0800, Weinan Li wrote:
> > > Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all
> > > the host support this feature, need to check the BIT(3) of caps in PVINFO.
> > > 
> > > Signed-off-by: Weinan Li 
> > > Cc: Chris Wilson 
> > 
> > 
> > 
> > > @@ -396,6 +393,12 @@ static bool csb_force_mmio(struct drm_i915_private 
> > > *i915)
> > >   if (intel_vtd_active())
> > >   return true;
> > >  
> > > + /* GVT emulation depends upon host kernel implementation, check
> > > +  * support capbility by reading PV INFO before access HWSP.
> > > +  */
> > 
> > The comment can be dropped completely, the code is self-descriptive.
> > 
> > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > @@ -722,7 +722,12 @@ static void intel_lrc_irq_handler(unsigned long data)
> > >   
> > > >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> > >   unsigned int head, tail;
> > >  
> > > - /* However GVT emulation depends upon intercepting CSB mmio 
> > > */
> > > + /* However GVT-g emulation depends upon host kernel
> > > +  * implementation, need to check support capbility by 
> > > reading PV
> > > +  * INFO before access HWSP. Beside from this, another 
> > > special
> > > +  * configuration may also need to force use mmio, like IOMMU
> > > +  * enabled.
> > > +  */
> > 
> > s/capbility/capability/ and please rephrase this to be a kerneldoc for
> > csb_use_mmio at the declaration.
> 
> This is not a description of how to use the function or even on how
> csb_use_mmio work, this is why we want certain logic paths. Just a regular
> old comment.

That's why I asked to "rephrase" :) Anyway, it seems like there already
is kerneldoc for the csb_use_mmio, so this comment can be dropped.

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

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_sequence: Add tests for new CRTC get/queue sequence ioctls

[Petri Latvala]

On Sat, Sep 30, 2017 at 12:35:33PM -0700, kei...@keithp.com wrote:
> From: Keith Packard 
> 
> These ioctls replace drmWaitVBlank and add ns time resolution and
> 64-bit sequence numbers to comply with the Vulkan API specifications.
> 
> The tests were derived from the existing kms_vblank tests with the
> 'wait' variant elided as the new API doesn't provide a mechanism for
> blocking in the kernel.
> 
> Signed-off-by: Keith Packard 
> ---
>  lib/igt_kms.c  |   2 +-
>  lib/igt_kms.h  |   1 +
>  tests/Makefile.sources |   1 +
>  tests/kms_sequence.c   | 289 
> +
>  tests/meson.build  |   1 +
>  5 files changed, 293 insertions(+), 1 deletion(-)
>  create mode 100644 tests/kms_sequence.c
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 7bcafc07..61ecb1f2 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1983,7 +1983,7 @@ report_dup:
>   }
>  }
>  
> -static igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output)
> +igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output)
>  {


Some documentation for this function is in order if it's made non-static.


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

Re: [Intel-gfx] [PATCH i-g-t v4 3/7] lib/igt_kms: Commit primary plane when a modeset is forced on a pipe

[Mika Kahola]

On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote:
> In between tests, some tests can do the following sequence:
> 
> (pipe C configured with FB)
> igt_plane_set_fb(primary (pipe C), NULL);
> /* Clear rotation property first */
> igt_display_commit2(display, COMMIT_UNIVERSAL);
> 
> /* disable pipe */
> igt_display_commit2(display, COMMIT_LEGACY);
> 
> This would result in PIPE_C not being properly disabled, which
> will cause an error on the next mode. This can be seen when running
> the full kms_rotation_crc testcase without --subtest, it will fail
> on exhaust-fences because the bad-tiling subtest wasn't able to
> disable pipe C correctly.
> 
> Testcase: kms_rotation_crc
> Signed-off-by: Maarten Lankhorst 
Reviewed-by: Mika Kahola 

> ---
>  lib/igt_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index a5db6bc493c2..d25090b05c70 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -2332,7 +2332,7 @@ static int
> igt_primary_plane_commit_legacy(igt_plane_t *primary,
>   igt_assert(!primary->rotation_changed);
>  
>   if (!primary->fb_changed && !primary->position_changed &&
> - !primary->size_changed)
> + !primary->size_changed && !primary->pipe->mode_changed)
>   return 0;
>  
>   crtc_id = pipe->crtc_id;
-- 
Mika Kahola - Intel OTC

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

[Intel-gfx] [PATCH i-g-t] meson: Follow suit with the renaming of kms_pipe_color

[Petri Latvala]

CC: Maarten Lankhorst 
Signed-off-by: Petri Latvala 
---
 tests/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/meson.build b/tests/meson.build
index 53d02d13..6cb3584a 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -157,6 +157,7 @@ test_progs = [
'kms_busy',
'kms_ccs',
'kms_chv_cursor_fail',
+   'kms_color',
'kms_concurrent',
'kms_crtc_background_color',
'kms_cursor_crc',
@@ -177,7 +178,6 @@ test_progs = [
'kms_mmio_vs_cs_flip',
'kms_panel_fitting',
'kms_pipe_b_c_ivb',
-   'kms_pipe_color',
'kms_pipe_crc_basic',
'kms_plane',
'kms_plane_lowres',
-- 
2.14.1

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Silence compiler warning for hsw_power_well_enable()

[Patchwork]

== Series Details ==

Series: drm/i915: Silence compiler warning for hsw_power_well_enable()
URL   : https://patchwork.freedesktop.org/series/31260/
State : warning

== Summary ==

Series 31260v1 drm/i915: Silence compiler warning for hsw_power_well_enable()
https://patchwork.freedesktop.org/api/1.0/series/31260/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-snb-2600)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:463s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:473s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:392s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:570s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:292s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:528s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:532s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:540s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:531s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:555s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:623s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:443s
fi-glk-1 total:289  pass:257  dwarn:3   dfail:0   fail:0   skip:29  
time:593s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:442s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:418s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:467s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:478s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:506s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:573s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:486s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:591s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:659s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:534s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:589s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:478s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:586s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:436s

2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC 
integration manifest
bb31ea157693 drm/i915: Silence compiler warning for hsw_power_well_enable()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5868/
___
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/glk, cnl: Implement WaDisableScalarClockGating (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating (rev2)
URL   : https://patchwork.freedesktop.org/series/31094/
State : success

== Summary ==

Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

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

shard-hswtotal:2429 pass:1329 dwarn:7   dfail:0   fail:10  skip:1083 
time:10165s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM

[Chris Wilson]

Quoting Joonas Lahtinen (2017-10-02 11:03:30)
> On Sat, 2017-09-30 at 13:57 +0800, Weinan Li wrote:
> > Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all
> > the host support this feature, need to check the BIT(3) of caps in PVINFO.
> > 
> > Signed-off-by: Weinan Li 
> > Cc: Chris Wilson 
> 
> 
> 
> > @@ -396,6 +393,12 @@ static bool csb_force_mmio(struct drm_i915_private 
> > *i915)
> >   if (intel_vtd_active())
> >   return true;
> >  
> > + /* GVT emulation depends upon host kernel implementation, check
> > +  * support capbility by reading PV INFO before access HWSP.
> > +  */
> 
> The comment can be dropped completely, the code is self-descriptive.
> 
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -722,7 +722,12 @@ static void intel_lrc_irq_handler(unsigned long data)
> >   
> > >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> >   unsigned int head, tail;
> >  
> > - /* However GVT emulation depends upon intercepting CSB mmio */
> > + /* However GVT-g emulation depends upon host kernel
> > +  * implementation, need to check support capbility by reading 
> > PV
> > +  * INFO before access HWSP. Beside from this, another special
> > +  * configuration may also need to force use mmio, like IOMMU
> > +  * enabled.
> > +  */
> 
> s/capbility/capability/ and please rephrase this to be a kerneldoc for
> csb_use_mmio at the declaration.

This is not a description of how to use the function or even on how
csb_use_mmio work, this is why we want certain logic paths. Just a regular
old comment.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v4 2/7] lib/igt_kms: Change output->pending_crtc_idx_mask to output->pending_pipe

[Mika Kahola]

On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote:
> igt_output_set_pipe with PIPE_ANY used to mean that we bind the
> output
> to any pipe, but this is now a deprecated alias for PIPE_NONE, and
> means the output will be unbound.
> 
> Because of this it's better to change output->pending_crtc_idx_mask
> to
> an enum pipe, because only a single choice may be given for a pipe.
> 
> Signed-off-by: Maarten Lankhorst 
Reviewed-by: Mika Kahola 

> ---
>  lib/igt_kms.c | 46 -
> --
>  lib/igt_kms.h |  2 +-
>  tests/kms_atomic_transition.c |  4 ++--
>  tests/kms_busy.c  |  2 +-
>  tests/kms_cursor_legacy.c |  2 +-
>  5 files changed, 26 insertions(+), 30 deletions(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 7bcafc072f70..a5db6bc493c2 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1561,9 +1561,10 @@ static void
> igt_display_log_shift(igt_display_t *display, int shift)
>  static void igt_output_refresh(igt_output_t *output)
>  {
>   igt_display_t *display = output->display;
> - unsigned long crtc_idx_mask;
> + unsigned long crtc_idx_mask = 0;
>  
> - crtc_idx_mask = output->pending_crtc_idx_mask;
> + if (output->pending_pipe != PIPE_NONE)
> + crtc_idx_mask = 1 << output->pending_pipe;
>  
>   kmstest_free_connector_config(>config);
>  
> @@ -1587,11 +1588,8 @@ static void igt_output_refresh(igt_output_t
> *output)
>   BROADCAST_RGB_FU
> LL);
>   }
>  
> - if (output->config.pipe == PIPE_NONE)
> - return;
> -
>   LOG(display, "%s: Selecting pipe %s\n", output->name,
> - kmstest_pipe_name(output->config.pipe));
> + kmstest_pipe_name(output->pending_pipe));
>  }
>  
>  static bool
> @@ -1830,7 +1828,7 @@ void igt_display_init(igt_display_t *display,
> int drm_fd)
>    * a pipe is set with igt_output_set_pipe().
>    */
>   output->force_reprobe = true;
> - output->pending_crtc_idx_mask = 0;
> + output->pending_pipe = PIPE_NONE;
>   output->id = resources->connectors[i];
>   output->display = display;
>  
> @@ -1960,10 +1958,12 @@ static void igt_display_refresh(igt_display_t
> *display)
>   for (i = 0; i < display->n_outputs; i++) {
>   output = >outputs[i];
>  
> - if (pipes_in_use & output->pending_crtc_idx_mask)
> - goto report_dup;
> + if (output->pending_pipe != PIPE_NONE) {
> + if (pipes_in_use & (1 << output-
> >pending_pipe))
> + goto report_dup;
>  
> - pipes_in_use |= output->pending_crtc_idx_mask;
> + pipes_in_use |= 1 << output->pending_pipe;
> + }
>  
>   if (output->force_reprobe)
>   igt_output_refresh(output);
> @@ -1975,11 +1975,11 @@ report_dup:
>   for (; i > 0; i--) {
>   igt_output_t *b = >outputs[i - 1];
>  
> - igt_assert_f(output->pending_crtc_idx_mask !=
> -  b->pending_crtc_idx_mask,
> + igt_assert_f(output->pending_pipe !=
> +  b->pending_pipe,
>    "%s and %s are both trying to use pipe
> %s\n",
>    igt_output_name(output),
> igt_output_name(b),
> -  kmstest_pipe_name(ffs(b-
> >pending_crtc_idx_mask) - 1));
> +  kmstest_pipe_name(output-
> >pending_pipe));
>   }
>  }
>  
> @@ -1988,7 +1988,7 @@ static igt_pipe_t
> *igt_output_get_driving_pipe(igt_output_t *output)
>   igt_display_t *display = output->display;
>   enum pipe pipe;
>  
> - if (!output->pending_crtc_idx_mask) {
> + if (output->pending_pipe == PIPE_NONE) {
>   /*
>    * The user hasn't specified a pipe to use, return
> none.
>    */
> @@ -1998,7 +1998,7 @@ static igt_pipe_t
> *igt_output_get_driving_pipe(igt_output_t *output)
>    * Otherwise, return the pending pipe (ie the pipe
> that should
>    * drive this output after the commit()
>    */
> - pipe = ffs(output->pending_crtc_idx_mask) - 1;
> + pipe = output->pending_pipe;
>   }
>  
>   igt_assert(pipe >= 0 && pipe < display->n_pipes);
> @@ -2051,7 +2051,7 @@ static igt_output_t
> *igt_pipe_get_output(igt_pipe_t *pipe)
>   for (i = 0; i < display->n_outputs; i++) {
>   igt_output_t *output = >outputs[i];
>  
> - if (output->pending_crtc_idx_mask == (1 << pipe-
> >pipe))
> + if (output->pending_pipe == pipe->pipe)
>   return output;
>   }
>  
> @@ -2860,22 +2860,18 @@ void igt_output_set_pipe(igt_output_t
> *output, enum pipe pipe)
>  
>   

[Intel-gfx] [PATCH] drm/i915: Silence compiler warning for hsw_power_well_enable()

[Chris Wilson]

Not all compilers are able to determine that pg is guarded by wait_fuses
and so may think that pg is used uninitialized.

Reported-by: Geert Uytterhoeven 
Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute")
Signed-off-by: Chris Wilson 
Cc: Imre Deak 
Cc: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 7933d1bc6a1c..de207c93c063 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -368,7 +368,7 @@ static void hsw_power_well_enable(struct drm_i915_private 
*dev_priv,
 {
enum i915_power_well_id id = power_well->id;
bool wait_fuses = power_well->hsw.has_fuses;
-   enum skl_power_gate pg;
+   enum skl_power_gate uninitialized_var(pg);
u32 val;
 
if (wait_fuses) {
-- 
2.14.2

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM

[Joonas Lahtinen]

On Sat, 2017-09-30 at 13:57 +0800, Weinan Li wrote:
> Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all
> the host support this feature, need to check the BIT(3) of caps in PVINFO.
> 
> Signed-off-by: Weinan Li 
> Cc: Chris Wilson 



> @@ -396,6 +393,12 @@ static bool csb_force_mmio(struct drm_i915_private *i915)
>   if (intel_vtd_active())
>   return true;
>  
> + /* GVT emulation depends upon host kernel implementation, check
> +  * support capbility by reading PV INFO before access HWSP.
> +  */

The comment can be dropped completely, the code is self-descriptive.

> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -722,7 +722,12 @@ static void intel_lrc_irq_handler(unsigned long data)
>   >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>   unsigned int head, tail;
>  
> - /* However GVT emulation depends upon intercepting CSB mmio */
> + /* However GVT-g emulation depends upon host kernel
> +  * implementation, need to check support capbility by reading PV
> +  * INFO before access HWSP. Beside from this, another special
> +  * configuration may also need to force use mmio, like IOMMU
> +  * enabled.
> +  */

s/capbility/capability/ and please rephrase this to be a kerneldoc for
csb_use_mmio at the declaration.

>   if (unlikely(execlists->csb_use_mmio)) {
>   buf = (u32 * __force)
>   (dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));

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

[Intel-gfx] [PATCH 1/2] dim: use prep_pull_mail_overview for drm-intel-testing

[Jani Nikula]

It's not perfect or exactly the same, but prefer fewer lines of special
casing anyway.

Signed-off-by: Jani Nikula 
---
 dim | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/dim b/dim
index bfa6ef010806..866a420d4ef6 100755
--- a/dim
+++ b/dim
@@ -1615,12 +1615,8 @@ function dim_update_next_continue
The following changes tagged $tag_testing:
 
HERE
-   obj=$(git rev-parse $tag)
-   if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then
-   git cat-file -p $obj | tail -n+6 >> $req_file
-   else
-   echo "*** CHANGELOG OVERVIEW HERE ***" >> $req_file
-   fi
+
+   prep_pull_mail_overview "$tag" >> $req_file
prep_pull_mail_signature >> $req_file
 
$DRY $DIM_MUA -s "Updated drm-intel-testing" \
-- 
2.11.0

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

[Intel-gfx] [PATCH 2/2] dim: strip signatures out of the pull mail overviews

[Jani Nikula]

Signed tags have the signature at the end. Strip them out when preparing
pull mail overviews.

Signed-off-by: Jani Nikula 
---
 dim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dim b/dim
index 866a420d4ef6..fc16d114632f 100755
--- a/dim
+++ b/dim
@@ -1483,7 +1483,7 @@ function prep_pull_mail_overview
obj=$(git rev-parse $tag)
if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then
echo $tag:
-   git cat-file -p $obj | tail -n+6
+   git cat-file -p $obj | tail -n+6 | sed -n 
'/^-BEGIN PGP SIGNATURE-$/q;p'
fi
done
fi
-- 
2.11.0

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

Re: [Intel-gfx] [dim PATCH] dim: use git ls-files file matching instead of grep

[Joonas Lahtinen]

On Mon, 2017-10-02 at 12:23 +0300, Jani Nikula wrote:
> Avoid extra pipelines for no good reason.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [dim PATCH] dim: note the testing tag in the drm-intel-testing mail

[Joonas Lahtinen]

On Mon, 2017-10-02 at 12:24 +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula 

Yay :)

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH i-g-t v4 1/7] tests: Stop looking at plane private members

[Maarten Lankhorst]

Op 29-09-17 om 15:13 schreef Mika Kahola:
> On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote:
>> Most of these tests have no reason to look at those members,
>> so try other ways of getting the information.
>>
>> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Mika Kahola 
Thanks, patch 1 & 7 pushed. :)

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen8+: Init/reset display interrupts only if i915 IRQs are enabled

[Imre Deak]

On Thu, Sep 28, 2017 at 11:44:52AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/gen8+: Init/reset display interrupts only if i915 IRQs are 
> enabled
> URL   : https://patchwork.freedesktop.org/series/31058/
> State : warning
> 
> == Summary ==
> 
> Series 31058v1 drm/i915/gen8+: Init/reset display interrupts only if i915 
> IRQs are enabled
> https://patchwork.freedesktop.org/api/1.0/series/31058/revisions/1/mbox/
> 
> Test chamelium:
> Subgroup hdmi-crc-fast:
> pass   -> DMESG-WARN (fi-skl-6700k) fdo#103019
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> DMESG-WARN (fi-cfl-s)

[  208.434941] ==
[  208.434941] WARNING: possible circular locking dependency detected
[  208.434942] 4.14.0-rc2-CI-Patchwork_5846+ #1 Tainted: G U 
[  208.434943] --
[  208.434944] rtcwake/3287 is trying to acquire lock:
[  208.434944]  ((complete)>done){+.+.}, at: [] 
wait_for_completion+0x1d/0x20
[  208.434948] 
   but task is already holding lock:
[  208.434948]  (sparse_irq_lock){+.+.}, at: [] 
irq_lock_sparse+0x17/0x20

looks like
https://bugs.freedesktop.org/show_bug.cgi?id=103026

The rest look like independent pre-existing issues based on the fdo links.

Thanks for the review, I pushed the patch to -dinq.


> Subgroup basic-s4-devices:
> dmesg-warn -> PASS   (fi-cfl-s) fdo#102294 +20
> Test kms_frontbuffer_tracking:
> Subgroup basic:
> dmesg-warn -> PASS   (fi-cfl-s) fdo#102374
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-c:
> incomplete -> SKIP   (fi-cfl-s) fdo#103022
> Test drv_module_reload:
> Subgroup basic-reload:
> pass   -> DMESG-WARN (fi-glk-1) fdo#102777
> 
> fdo#103019 https://bugs.freedesktop.org/show_bug.cgi?id=103019
> fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294
> fdo#102374 https://bugs.freedesktop.org/show_bug.cgi?id=102374
> fdo#103022 https://bugs.freedesktop.org/show_bug.cgi?id=103022
> fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777
> 
> fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
> time:443s
> fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
> time:475s
> fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
> time:425s
> fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
> time:519s
> fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
> time:280s
> fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
> time:505s
> fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
> time:509s
> fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
> time:503s
> fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
> time:546s
> fi-cnl-y total:289  pass:259  dwarn:0   dfail:0   fail:3   skip:27  
> time:671s
> fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
> time:420s
> fi-glk-1 total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
> time:568s
> fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
> time:425s
> fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
> time:405s
> fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
> time:440s
> fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
> time:495s
> fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
> time:469s
> fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
> time:471s
> fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
> time:582s
> fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
> time:589s
> fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
> time:554s
> fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
> time:455s
> fi-skl-6700k total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
> time:756s
> fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
> time:494s
> fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
> time:476s
> fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
> time:570s
> fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
> time:429s
> 
> c1ed501217782b35094792696924a1d22ee83c0f drm-tip: 2017y-09m-28d-04h-52m-47s 
> UTC integration manifest
> 3b58c2e42208 drm/i915/gen8+: Init/reset display interrupts only if i915 IRQs 
> are enabled
> 
> == Logs ==
> 
> For more details see: 

[Intel-gfx] [dim PATCH] dim: note the testing tag in the drm-intel-testing mail

[Jani Nikula]

Signed-off-by: Jani Nikula 
---
 dim | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dim b/dim
index d2f165893161..bfa6ef010806 100755
--- a/dim
+++ b/dim
@@ -1612,6 +1612,8 @@ function dim_update_next_continue
cat > $req_file <<-HERE
Hi all,
 
+   The following changes tagged $tag_testing:
+
HERE
obj=$(git rev-parse $tag)
if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then
-- 
2.11.0

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

[Intel-gfx] [dim PATCH] dim: use git ls-files file matching instead of grep

[Jani Nikula]

Avoid extra pipelines for no good reason.

Signed-off-by: Jani Nikula 
---
 dim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dim b/dim
index 678f34d5f7bd..d2f165893161 100755
--- a/dim
+++ b/dim
@@ -602,7 +602,7 @@ function commit_rerere_cache
return 1
fi
git add ./*.patch >& /dev/null || true
-   for file  in $(git ls-files | grep ^rr-cache); do
+   for file  in $(git ls-files -- rr-cache); do
if ! git log --since="60 days ago" --name-only -- $file 
| grep $file &> /dev/null; then
git rm $file &> /dev/null || true
fi
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 2/2] dim: sign pull-request tags if the GPG key is configured

[Jani Nikula]

On Mon, 11 Sep 2017, Sean Paul  wrote:
> On Mon, Sep 11, 2017 at 9:16 AM, Jani Nikula  wrote:
>> Add new environment variable $DIM_GPG_KEYID for configuring the GPG key
>> ID of the key to use for signing tags for pull requests. The tags will
>> be signed if the key ID is set, otherwise annotated tags will be used
>> like before.
>>
>> The drm-intel-testing tags are left unsigned, at least for now.
>>
>> Cc: Daniel Vetter 
>> Cc: Joonas Lahtinen 
>> Cc: Rodrigo Vivi 
>> Cc: Sean Paul 
>> Signed-off-by: Jani Nikula 
>>
>> ---
>>
>> BEWARE OF THE LEOPARD! I didn't actually test this. I will try it when I
>> need to tag something next.
>>
>
> Just comment out git push and test this?

Finally got around to trying this out, works fine:
https://cgit.freedesktop.org/drm-intel/tag/?id=drm-intel-next-2017-09-29

The only snag is that now prep_pull_mail_overview() picks up the
signature from the tag object to the overview too.

Ack on merging these two out of the way, and fixing that separately (a
tiny bit of sed)?


BR,
Jani.



>
> Sean
>
>> We should probably also add verification to dim apply-pull.
>> ---
>>  dim |  9 ++---
>>  dim.rst | 11 +++
>>  2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/dim b/dim
>> index 23dfccb5513d..4d7864d8f450 100755
>> --- a/dim
>> +++ b/dim
>> @@ -70,6 +70,9 @@ 
>> DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-$HOME/.dim.template.signature}
>>  # dim pull-request tag summary template
>>  
>> DIM_TEMPLATE_TAG_SUMMARY=${DIM_TEMPLATE_TAG_SUMMARY:-$HOME/.dim.template.tagsummary}
>>
>> +# GPG key id for signing tags. If unset, don't sign.
>> +DIM_GPG_KEYID=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
>> +
>>  #
>>  # Internal configuration.
>>  #
>> @@ -1549,7 +1552,7 @@ function dim_update_next_continue
>> tag_testing="drm-intel-testing-$today-$((++suffix))"
>> done
>>
>> -   $DRY git tag -a $tag $DIM_DRM_INTEL_REMOTE/drm-intel-next
>> +   $DRY git tag -a $DIM_GPG_KEYID $tag 
>> $DIM_DRM_INTEL_REMOTE/drm-intel-next
>> git push $DRY_RUN $DIM_DRM_INTEL_REMOTE $tag
>>
>> echo "Updating drm-intel-testing to latest drm-tip"
>> @@ -1589,7 +1592,7 @@ function dim_tag_next
>> tag="drm-intel-next-$today-$((++suffix))"
>> done
>>
>> -   $DRY git tag -a $tag $DIM_DRM_INTEL_REMOTE/drm-intel-next
>> +   $DRY git tag -a $DIM_GPG_KEYID $tag 
>> $DIM_DRM_INTEL_REMOTE/drm-intel-next
>> git push $DRY_RUN $DIM_DRM_INTEL_REMOTE $tag
>> else
>> echo "drm-intel-next not up-to-date, aborting"
>> @@ -1650,7 +1653,7 @@ function dim_pull_request
>> done
>> gitk "$branch@{upstream}" ^$upstream &
>> prep_pull_tag_summary | $DRY git tag -F- $tag 
>> "$branch@{upstream}"
>> -   $DRY git tag -a -f $tag
>> +   $DRY git tag -a $DIM_GPG_KEYID -f $tag
>> $DRY git push $remote $tag
>> prep_pull_mail $req_file $tag
>>
>> diff --git a/dim.rst b/dim.rst
>> index 7aacc4e776e2..65e652e8bc75 100644
>> --- a/dim.rst
>> +++ b/dim.rst
>> @@ -349,6 +349,8 @@ recipients already set.
>>  Since the tag for the *branch* is date based, the pull request can be
>>  regenerated with the same commands if something goes wrong.
>>
>> +The tag will be signed using the key specified by \$DIM_GPG_KEYID, if set.
>> +
>>  pull-request-fixes [*upstream*]
>>  ---
>>  **pull-request** shorthand for *drm-intel-fixes* as the branch and
>> @@ -391,6 +393,8 @@ opened.
>>  Also checks that the drm-intel-fixes|-next-queued are fully
>>  merged into drm-tip to avoid operator error.
>>
>> +The tag will be signed using the key specified by \$DIM_GPG_KEYID, if set.
>> +
>>  update-next-continue
>>  
>>
>> @@ -405,6 +409,8 @@ remote is up-to-date. Useful if drm-intel-next has been 
>> changed since the last
>>  run of the update-next command (e.g. to apply a hotfix before sending out 
>> the
>>  pull request).
>>
>> +The tag will be signed using the key specified by \$DIM_GPG_KEYID, if set.
>> +
>>  DIM HELP COMMANDS
>>  =
>>
>> @@ -498,6 +504,11 @@ DIM_TEMPLATE_TAG_SUMMARY
>>  -
>>  Path to a file containing the template for dim pull-request tag summaries.
>>
>> +DIM_GPG_KEYID
>> +-
>> +GPG key ID to use for signing tags. If set, tags will be signed. If unset, 
>> the
>> +default, tags will not be signed.
>> +
>>  dim_alias_
>>  -
>>  Make  an alias for the subcommand defined as the value. For 
>> example,
>> --
>> 2.11.0
>>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9+: Set same power state before hibernation image save/restore

[Imre Deak]

On Wed, Aug 16, 2017 at 04:50:01PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/gen9+: Set same power state before hibernation image 
> save/restore
> URL   : https://patchwork.freedesktop.org/series/28873/
> State : success

Thanks for the review, pushed it to -dinq.

> 
> == Summary ==
> 
> Series 28873v1 drm/i915/gen9+: Set same power state before hibernation image 
> save/restore
> https://patchwork.freedesktop.org/api/1.0/series/28873/revisions/1/mbox/
> 
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-atomic:
> pass   -> FAIL   (fi-snb-2600) fdo#100215
> 
> fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
> 
> fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
> time:453s
> fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
> time:434s
> fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
> time:363s
> fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
> time:559s
> fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
> time:522s
> fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
> time:538s
> fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
> time:517s
> fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
> time:609s
> fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
> time:447s
> fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
> time:421s
> fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
> time:429s
> fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:508s
> fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:478s
> fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:482s
> fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
> time:597s
> fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:599s
> fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
> time:527s
> fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
> time:477s
> fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
> time:477s
> fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
> time:491s
> fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
> time:445s
> fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
> time:481s
> fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
> time:542s
> fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
> time:405s
> 
> ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s 
> UTC integration manifest
> 58aa054f582c drm/i915/gen9+: Set same power state before hibernation image 
> save/restore
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5416/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] tests: add slice power programming test

[Joonas Lahtinen]

On Fri, 2017-09-22 at 16:11 +0100, Lionel Landwerlin wrote:
> Verifies that the kernel programs slices correctly based by reading
> the value of PWR_CLK_STATE register.
> 
> v2: Add subslice tests (Lionel)
> Use MI_SET_PREDICATE for further verification when available (Lionel)
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  tests/Makefile.sources |   1 +
>  tests/ctx_rpcs.c   | 453 
> +

This should definitely be 'gem_ctx_rpcs' :)

Unless I missed it, this test only checks that the registers are
written to and get read. It doesn't functionally validate that the
hardware actually performs differently based on what you set? 

Maybe under benchmarks/ it would be appropriate to compare the effect
on processing power, and make sure performance improves with additional
slices (except when it doesn't :P)

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

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

[Michal Hocko]

[Hmm, I do not see the original patch which this has been a reply to]

On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote:
> On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote:
> > Tetsuo Handa wrote:
> > > Michael S. Tsirkin wrote:
> > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote:
> > > > > Hello.
> > > > > 
> > > > > I noticed that virtio_balloon is using register_oom_notifier() and
> > > > > leak_balloon() from virtballoon_oom_notify() might depend on
> > > > > __GFP_DIRECT_RECLAIM memory allocation.
> > > > > 
> > > > > In leak_balloon(), mutex_lock(>balloon_lock) is called in order to
> > > > > serialize against fill_balloon(). But in fill_balloon(),
> > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) 
> > > > > is
> > > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] 
> > > > > implies
> > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt 
> > > > > might
> > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory
> > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation can 
> > > > > reach
> > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call 
> > > > > out_of_memory().
> > > > > And leak_balloon() is called by virtballoon_oom_notify() via
> > > > > blocking_notifier_call_chain() callback when vb->balloon_lock mutex 
> > > > > is already
> > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is 
> > > > > specified,
> > > > > fill_balloon() can indirectly get stuck waiting for vb->balloon_lock 
> > > > > mutex
> > > > > at leak_balloon().

This is really nasty! And I would argue that this is an abuse of the oom
notifier interface from the virtio code. OOM notifiers are an ugly hack
on its own but all its users have to be really careful to not depend on
any allocation request because that is a straight deadlock situation.

I do not think that making oom notifier API more complex is the way to
go. Can we simply change the lock to try_lock? If the lock is held we
would simply fall back to the normal OOM handling. As a follow up it
would be great if virtio could use some other form of aging e.g.
shrinker.
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] drm/i915: Enhanced for initialize partially filled pagetables

[Joonas Lahtinen]

+ Zhenyu and Zhi

On Sat, 2017-09-30 at 02:58 +, Zhang, Xiaolin wrote:
> On 09/28/2017 10:25 PM, Joonas Lahtinen wrote:
> > On Thu, 2017-09-28 at 10:09 +0800, Xiaolin Zhang wrote:
> > > if vgpu active, the page table entry should be initialized after
> > > allocation and then the hypersivor can ping pages succesuffly,
> > > otherwise hypervisor will ping pages failed and the host will
> > > print
> > > a lot of annoying errors such as “ERROR gvt: guest page write
> > > error -22,
> > > gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 1” when create linux
> > > guest.
> > > 
> > > Signed-off-by: Xiaolin Zhang 
> > 
> > Why does the hypervisor try to access the entries prior to them
> > being
> > made valid for hardware?
> > 
> > Regards, Joonas
> 
> Hi Joonas,
> thanks your comment. 
> I think what you ask is the point we got the error message in gvt since the 
> current gvt
> implementation is that page under write protection and trapped should be 
> valid 
> with correct shadow page setup and p2m translation.

My question is that if the hardware doesn't care about them being
uninitialized at this point, how can GVT? If the GVT implementation
relies heavily on how the i915 driver currently happens to behave, not
on what contracts it has with the hardware, these breakages are bound
to happen repeatedly. The code is being transformed and optimized on
daily basis, how it currently behaves is not a solid foundation for
implementing the host side virtualization.

> Actually, to work with 
> “initialize partially filled pagetables" , there is a certain refine work to 
> do in gvt side
> (maybe less or maybe large). but before refine work done, this patch is 
> trying to bring back 
> gvt behavior as before “initialize partially filled pagetables"patch. 

We should first minimize and then keep the vgpu specific checks to
minimum. So this would need to be fixed on the GVT side of code.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk, cnl: Implement WaDisableScalarClockGating (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating (rev2)
URL   : https://patchwork.freedesktop.org/series/31094/
State : success

== Summary ==

Series 31094v2 drm/i915/glk, cnl: Implement WaDisableScalarClockGating
https://patchwork.freedesktop.org/api/1.0/series/31094/revisions/2/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:458s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:471s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:392s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:575s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:289s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:535s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:532s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:542s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:534s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:564s
fi-cnl-y total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:620s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:435s
fi-glk-1 total:289  pass:257  dwarn:3   dfail:0   fail:0   skip:29  
time:593s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:440s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:426s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:467s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:507s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:583s
fi-kbl-7567u total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  
time:485s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:589s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:657s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:543s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:591s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:473s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:584s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:433s

b89a3b1a69f77be194ad4786906048a5e02b9975 drm-tip: 2017y-10m-02d-08h-07m-17s UTC 
integration manifest
27ae0ed67a28 drm/i915/glk, cnl: Implement WaDisableScalarClockGating

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 0/7] Dist cleanups

[Daniel Vetter]

On Fri, Sep 29, 2017 at 03:59:45PM +0300, Petri Latvala wrote:
> Distribute files that should be, remove files that shouldn't be even
> in git.
> 
> Notable inclusion: Meson build system files added to dist. With this
> series, both a git checkout and tarball distribution build the same
> results with either autotools or meson. Meson support looks to be
> mature enough to get tarballed up.

On the entire series:

Acked-by: Daniel Vetter 
> 
> Petri Latvala (7):
>   benchmarks: Add wsim files to dist
>   benchmarks: Add ezbench.d files to dist
>   demos: Remove final file
>   lib: Remove media_fill.c
>   lib: Handle intel_aub.h like the other stub files
>   docs: Distribute audio.txt and chamelium.txt
>   meson: Distribute meson build system files
> 
>  Makefile.am  |  5 +
>  assembler/Makefile.am|  1 +
>  benchmarks/Makefile.am   |  7 ++-
>  benchmarks/ezbench.d/Makefile.am | 16 
>  benchmarks/wsim/Makefile.am  | 31 +++
>  configure.ac |  2 ++
>  demos/Makefile.am| 12 
>  docs/Makefile.am |  5 +
>  lib/Makefile.am  |  6 ++
>  lib/media_fill.c | 16 
>  lib/tests/Makefile.am|  4 
>  man/Makefile.am  |  8 +++-
>  overlay/Makefile.am  |  5 -
>  tests/Makefile.am|  7 ++-
>  tools/Makefile.am|  3 +++
>  tools/null_state_gen/Makefile.am |  4 
>  16 files changed, 100 insertions(+), 32 deletions(-)
>  create mode 100644 benchmarks/ezbench.d/Makefile.am
>  create mode 100644 benchmarks/wsim/Makefile.am
>  delete mode 100644 demos/Makefile.am
>  delete mode 100644 lib/media_fill.c
> 
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH i-g-t 3/3] lib: Reduce dependency on glib

[Daniel Vetter]

On Fri, Sep 29, 2017 at 03:09:02PM +0300, Arkadiusz Hiler wrote:
> On Fri, Sep 29, 2017 at 01:51:59PM +0300, Petri Latvala wrote:
> > In commit ebd6eb69f57b ("Make igtrc configuration common, with
> > configurable suspend/resume delay") .igtrc handling was moved to
> > igt_core from igt_chamelium. That made everything in IGT depend on
> > GLIB by accident.
> > 
> > In short, igt_core.h declared a variable of type GKeyFile*, requiring
> > glib.h. Everything that tried to #include igt_core.h required glib.h
> > to be available, by use of GLIB_CFLAGS. This "worked" so far because
> > CAIRO_CFLAGS contained GLIB_CFLAGS.
> > 
> > As the variable is only used by other stuff in lib/, stuff it in its
> > own header file to leave igt_core.h without a dependency to glib.h.
> > 
> > Also add a couple of missing #ifdef HAVE_GLIBs around.
> > 
> > Reported-by: Felipe De Jesus Ruiz Garcia 
> > 
> > Signed-off-by: Petri Latvala 
> Reviewed-by: Arkadiusz Hiler 
> 
> The whole igtrc implementation has plenty of other issues (using asserts
> in a wrong scope, etc).
> 
> I have a bigger rework on my TODO list...

Imo biggest is inversion of control, the core igtrc does all the parsing
for all the other bits in igt, which means we leak all the submodule stuff
into igt_core.c. Which isn't cool.

Is there a JIRA or similar for this already where I could bikeshed?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v12 06/11] drm/i915/guc: Make GuC related disable/destroy functions not depend on i915.enable_guc_submission

[Joonas Lahtinen]

On Sat, 2017-09-30 at 13:52 +0530, Sagar Arun Kamble wrote:
> 
> On 9/29/2017 5:57 PM, Joonas Lahtinen wrote:
> > On Thu, 2017-09-28 at 12:18 +0530, Sagar Arun Kamble wrote:
> > > During GuC load/enable, state is setup by driver that can be looked at
> > > while disabling. So remove the check for i915.enable_guc_submission
> > > parameter in those functions.
> > > 
> > > Suggested-by: Chris Wilson 
> > > Signed-off-by: Sagar Arun Kamble 
> > > Cc: Michal Wajdeczko 
> > > Cc: Michał Winiarski 
> > 
> > 
> > 
> > > @@ -1002,7 +1002,8 @@ static int guc_ads_create(struct intel_guc *guc)
> > >   
> > >   static void guc_ads_destroy(struct intel_guc *guc)
> > >   {
> > > - i915_vma_unpin_and_release(>ads_vma);
> > > + if (guc->ads_vma)
> > 
> > GEM_BUG_ON(!guc->ads_vma);
> 
> This check was unnecessary. Suggestion from Chris was to make these 
> destroys be self-check based instead of invoking
> based on module parameters like enable_guc_submission/loading. In my new 
> patch I have removed these checks.
> https://patchwork.freedesktop.org/patch/179683/

I pinged Chris about this. I do prefer the symmetry, and I think we
could have guc->enable_submission variable based on which
i915_guc_submission_init/fini() would be executed on. No conditionals
in the _init/_fini themselves. You can of course do the
enable_submission check at the beginning of i915_guc_submission_init
and _fini too, if that feels clearer for the upper level code flow.

If _init is called and succeeds, _fini needs to be called. If _init
fails, _fini is to never be called. The check outside or inside will
both adhere to that.

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

Re: [Intel-gfx] [PATCH i-g-t] igt_command_line.sh: Fix bashism

[Daniel Vetter]

On Fri, Sep 29, 2017 at 12:34:48PM +0300, Joonas Lahtinen wrote:
> On Tue, 2017-09-26 at 14:01 +0200, Daniel Vetter wrote:
> > On Mon, Sep 25, 2017 at 02:48:41PM +0300, Jani Nikula wrote:
> > > On Mon, 25 Sep 2017, Petri Latvala  wrote:
> > > > [[ a != b ]] is a bashism. As it's just comparing $1 to an empty
> > > > string, use -n with a normal [ ].
> > > > 
> > > > /bin/sh is dash in CI.
> > > 
> > > There's probably /bin/bash around anyway, but I'm tired of fighting the
> > > fight. So never mind about that.
> > 
> > Yeah, let's just switch to /bin/bash and stop bothering with dash. At
> > least I don't see any value in trying to be posix compliant, we're not
> > going to run on anything that doesn't have bash anyway.
> 
> I'm actively running I-G-T with busybox sh, so please cut with the
> /bin/bash stuff, it's not that hard to be POSIX compliant.

Is that a machine which doesn't have any bash at all, or is busysbox
simply your /bin/sh?

And yes it's imo not justified to be posix compliant if there's no
use-case for it, afaiui we haven't ever made a decision for igt to be
posix compliant when building (running might be a different thing, with
android and all that). And this is a build-time script here.
-Daniel

> 
> Original patch is;
> 
> Reviewed-by: Joonas Lahtinen 
> 
> Regards, Joonas
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation

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

Re: [Intel-gfx] [PATCH 0/9] drm/i915: Guc code reorg

[Joonas Lahtinen]

On Fri, 2017-09-29 at 17:41 +, Michal Wajdeczko wrote:
> Other pending series will try to fix current GuC code.
> Lets move some functions to dedicated files now to
> make place for these changes and preserve history.
> 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Sagar Arun Kamble 
> 
> Michal Wajdeczko (9):
>   drm/i915: Drop unnecessary forward declaration
>   drm/i915: Move uC fw helper code into dedicated files
>   drm/i915: Move HuC declarations into dedicated header
>   drm/i915: Move GuC declarations into dedicated header
>   drm/i915: Move core GuC functions into dedicated file

If these are new header files, then patch per new header would be good
granularity.

>   drm/i915: Move intel_guc_sample_forcewake to guc.c
>   drm/i915: Move intel_guc_auth_huc to guc.c
>   drm/i915: Move intel_guc_suspend/resume to guc.c
>   drm/i915: Move intel_guc_allocate_vma to guc.c

When you're moving functions to same file .c, you can do it in a single
patch. There're no hard rules, just trying to keep the amount of
patches reasonable vs. having enough GIT history of what was done.

Then, don't do the s/dev_priv/i915/ together with the code motion even
if it may feel convenient. Will be harder to notice from the GIT
history that a mass s/dev_priv/i915/ was done and also the reviewer has
to go through all the code that was moved to check for possible errors
(in indent for example). Always think of the reviewer, and send code
motion in front, so that can be reviewed based on what was moved where,
then any changes so they can be reviewed for correctness.

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