Re: [Intel-gfx] [PATCH v2] drm/i915/skl+: ddb allocation algorithm optimization

2018-07-02 Thread Kumar, Mahesh

Hi,


On 7/3/2018 4:56 AM, Rodrigo Vivi wrote:

On Fri, Jun 29, 2018 at 03:13:35PM +0530, Mahesh Kumar wrote:

This patch implements new DDB allocation algorithm as per HW team
recommendation. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each

Usually "It also" in a commit message is a good indication that we should
be doing more than one patch.
Enabling same watermark level for each plane in CRTC is byproduct of 
this algorithm.

But Agree will rework on patch and try to break it as much as possible.
I think I should Add old cover letter as well to explain what is new 
algo optimization all about.



plane in crtc, for efficient power saving.
This algorithm uses fixed ddb allocation for cursor planes.

Ealier version of this patch reverted due to regression. And it was root
caused to following:
New algorithm required more DDB for cursor plane but as cursor plane has
fixed allocation it's DDB was not sufficient and WM level-0 was getting
disabled, resulting in blank screen. Now we use old DDB allocation logic
only for cursor plane.

I really don't see on spec old and new DDB allocation logics.
Actually now spec have 2 method for DDB allocation (Added based on our 
request). So new Algorithm is nothing but second method of allocation logic.




Only thing different for cursor that I see there is that a workaround on
watermark calculation where "For each plane, except cursor..."

"Number of planes, except cursor..."

This is not what I see in this patch, but maybe because the patch is too big.
so for each plane we first calculate WM then try to find maximum level 
that can be enabled with available DDB for pipe and distribute DDB 
accordingly.
but for cursor Now I'm allocating DDB first (8block or 32 blocks based 
on number of CRTC similar to old method) that is the difference from 
previous version of patch.



Changes:
  - add reason for revert in commit msg (Maarten)
  - Fix checkpatch checks

Testcase: igt/kms_plane_multiple
Signed-off-by: Mahesh Kumar 
Cc: Rodrigo Vivi 

Well, since I'm on cc and I was the one that reverted that because I noticed
on my own machine I opened this patch for review many times here already,
but I gave up completely every time because this patch is hard to review.
Agree, My bad, will try to split this patch but I'm afraid main patch 
still be lengthy please bare with me.


So this time I won't fully give up and at least put some comments...

So, overall it is hard to match the spec differences because this patch
is trying to do all at once. Smaller patches should be better.


---
  drivers/gpu/drm/i915/i915_drv.h |   5 +-
  drivers/gpu/drm/i915/intel_pm.c | 376 +++-
  2 files changed, 219 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b684f431c60..f5d636a6d121 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1212,8 +1212,9 @@ struct skl_ddb_values {
  
  struct skl_wm_level {

bool plane_en;
-   uint16_t plane_res_b;
-   uint8_t plane_res_l;
+   u16 plane_res_b;
+   u8 plane_res_l;
+   u16 min_dbuf_req;
  };
  
  /* Stores plane specific WM parameters */

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 533e6886..d1564a08a202 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3802,17 +3802,37 @@ static unsigned int intel_get_ddb_size(struct 
drm_i915_private *dev_priv,
return ddb_size;
  }
  
+static int

+skl_get_num_pipes_active(struct drm_i915_private *dev_priv,
+const struct intel_crtc_state *cstate)
+{
+   struct drm_atomic_state *state = cstate->base.state;
+   const struct intel_atomic_state *intel_state;
+   int num_active;
+
+   if (WARN_ON(!state) || !cstate->base.active)
+   return hweight32(dev_priv->active_crtcs);
+
+   intel_state = to_intel_atomic_state(state);
+
+   if (intel_state->active_pipe_changes)
+   num_active = hweight32(intel_state->active_crtcs);
+   else
+   num_active = hweight32(dev_priv->active_crtcs);
+
+   return num_active;
+}

This entire function here is something that should come in a separated patch.
This is new change in this version. I should have created separate 
patch. will do so.



+
  static void
-skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
+skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv,
   const struct intel_crtc_state *cstate,
   const unsigned int total_data_rate,
   struct skl_ddb_allocation *ddb,
-  struct skl_ddb_entry *alloc, /* out */
-

[Intel-gfx] [PULL] gvt-fixes for 4.18

2018-07-02 Thread Zhenyu Wang

Hi,

Here's two gvt fixes for 4.18. One is for guest warning to change
virtual transcoder mode for DVI to align with our virtual display,
and one to fix possible partial GGTT entry update from guest.

thanks
--
The following changes since commit 7a3727f385dc64773db1c144f6b15c1e9d4735bb:

  drm/i915: Enable provoking vertex fix on Gen9 systems. (2018-06-19 15:48:24 
+0300)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-07-03

for you to fetch changes up to a4cae23cc05ccec749c2fc70fa9d8cda7c582319:

  drm/i915/gvt: changed DDI mode emulation type (2018-07-02 11:09:59 +0800)


gvt-fixes-2018-07-03

- replace virtual transcoder mode as DVI to fix guest warning (Xiaolin)
- fix partial GGTT entry write (Yan)


Xiaolin Zhang (1):
  drm/i915/gvt: changed DDI mode emulation type

Zhao Yan (1):
  drm/i915/gvt: fix a bug of partially write ggtt enties

 drivers/gpu/drm/i915/gvt/display.c |  6 ++--
 drivers/gpu/drm/i915/gvt/gtt.c | 58 ++
 drivers/gpu/drm/i915/gvt/gtt.h |  2 ++
 3 files changed, 63 insertions(+), 3 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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


Re: [Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: expect setting bad source to fail

2018-07-02 Thread Kumar, Mahesh

Hi,


On 7/2/2018 4:57 PM, Maarten Lankhorst wrote:

Op 02-07-18 om 13:16 schreef Mahesh Kumar:

Now crc-core framework verifies the source string passed by the user.
So setting bad-source will fail. Expect file write to fail in bad-source
subtest of kms_pipe_crc_basic.

Signed-off-by: Mahesh Kumar 
---
  tests/kms_pipe_crc_basic.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index 235fdc38..2d4dfee8 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -48,8 +48,7 @@ static struct {
  
  static void test_bad_source(data_t *data)

  {
-   igt_assert(igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo"));
-   igt_assert(openat(data->debugfs, "crtc-0/crc/data", O_WRONLY) == -1);
+   igt_assert(!igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo"));
  }
  
  #define N_CRCS	3

New behavior makes more sense.

Reviewed-by: Maarten Lankhorst 

Do you have igt commit rights?

thanks for review.
I don't have commit rights
-Mahesh

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


Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled

2018-07-02 Thread Kumar, Abhay
Hi Ville,
 
  Can we please get this merged to DINQ?

Regards,
Abhay

-Original Message-
From: Du, Wenkai 
Sent: Thursday, June 21, 2018 1:16 PM
To: Kumar, Abhay ; intel-gfx@lists.freedesktop.org; 
Syrjala, Ville 
Cc: Nikula, Jani 
Subject: Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl 
when audio power is enabled



On 6/21/2018 11:43 AM, Kumar, Abhay wrote:
> + Wenkai
> 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On 
> Behalf Of Abhay Kumar
> Sent: Tuesday, June 19, 2018 3:01 PM
> To: intel-gfx@lists.freedesktop.org; Syrjala, Ville 
> 
> Cc: Nikula, Jani 
> Subject: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on 
> glk/cnl when audio power is enabled
> 
> From: Ville Syrjälä 
> 
> CDCLK has to be at least twice the BLCK regardless of audio. Audio driver has 
> to probe using this hook and increase the clock even in absence of any 
> display.
> 
> v2: Use atomic refcount for get_power, put_power so that we can
>  call each once(Abhay).
> v3: Reset power well 2 to avoid any transaction on iDisp link
>  during cdclk change(Abhay).
> v4: Remove Power well 2 reset workaround(Ville).
> v5: Remove unwanted Power well 2 register defined in v4(Abhay).
> 
> Signed-off-by: Ville Syrjälä 
> Signed-off-by: Abhay Kumar 
Tested-by: Wenkai Du 
> ---
>   drivers/gpu/drm/i915/i915_drv.h  |  3 ++
>   drivers/gpu/drm/i915/intel_audio.c   | 67 
> +---
>   drivers/gpu/drm/i915/intel_cdclk.c   | 29 +---
>   drivers/gpu/drm/i915/intel_display.c |  7 +++-
>   drivers/gpu/drm/i915/intel_drv.h |  2 ++
>   5 files changed, 83 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> b/drivers/gpu/drm/i915/i915_drv.h index 6104d7115054..a4a386a5db69 
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1702,6 +1702,7 @@ struct drm_i915_private {
>   unsigned int hpll_freq;
>   unsigned int fdi_pll_freq;
>   unsigned int czclk_freq;
> + u32 get_put_refcount;
>   
>   struct {
>   /*
> @@ -1719,6 +1720,8 @@ struct drm_i915_private {
>   struct intel_cdclk_state actual;
>   /* The current hardware cdclk state */
>   struct intel_cdclk_state hw;
> +
> + int force_min_cdclk;
>   } cdclk;
>   
>   /**
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 3ea566f99450..ca8f04c7cbb3 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder 
> *encoder,
>   
>   if (!connector->eld[0])
>   return;
> -
>   DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>connector->base.id,
>connector->name,
> @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private 
> *dev_priv)
>   }
>   }
>   
> +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
> + bool enable)
> +{
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + int ret;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> + state = drm_atomic_state_alloc(&dev_priv->drm);
> + if (WARN_ON(!state))
> + return;
> +
> + state->acquire_ctx = &ctx;
> +
> +retry:
> + to_intel_atomic_state(state)->modeset = true;
> + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
> + enable ? 2 * 96000 : 0;
> +
> + /*
> +  * Protects dev_priv->cdclk.force_min_cdclk
> +  * Need to lock this here in case we have no active pipes
> +  * and thus wouldn't lock it during the commit otherwise.
> +  */
> + ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex, 
> &ctx);
> + if (!ret)
> + ret = drm_atomic_commit(state);
> +
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + }
> +
> + WARN_ON(ret);
> +
> + drm_atomic_state_put(state);
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +}
> +
>   static void i915_audio_component_get_power(struct device *kdev)  {
> - intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
> + struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> +
> + dev_priv->get_put_refcount++;
> +
> + /* Force cdclk to 2*BCLK during first time get power call */
> + if (dev_priv->get_put_refcount == 1)
> + if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> + glk_force_audio_cdclk(dev_priv, true);
> +
> + intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
>   }
>   
>   static void i915_audio_component_put_power(struct device *kdev)  {
> - intel_displa

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Optimize the read/write fence_reg on SNB+

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Optimize the read/write fence_reg on SNB+
URL   : https://patchwork.freedesktop.org/series/45801/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4417_full -> Patchwork_9503_full =

== Summary - WARNING ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

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

igt@kms_cursor_legacy@cursor-vs-flip-legacy:
  shard-snb:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-glk:  PASS -> INCOMPLETE (fdo#107094)

igt@drv_selftest@mock_scatterlist:
  shard-kbl:  NOTRUN -> DMESG-WARN (fdo#103667)

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

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#103822, fdo#104724)

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


 Possible fixes 

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
  shard-glk:  FAIL (fdo#105454, fdo#106509) -> PASS

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

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

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#103822, fdo#104724) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509
  fdo#107094 https://bugs.freedesktop.org/show_bug.cgi?id=107094
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4417 -> Patchwork_9503

  CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9503: e8b6a25966721c297a1d15b6c0749775bcc086cb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: write fence reg only once on VGPU

2018-07-02 Thread kbuild test robot
Hi Zhao,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.18-rc3 next-20180702]
[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/Zhao-Yakui/drm-i915-the-Read-Write-optimization-of-fence-reg/20180703-102412
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x073-201826 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu/drm/i915/i915_gem_fence_reg.c:24:
   drivers/gpu/drm/i915/i915_gem_fence_reg.c: In function 
'i965_write_fence_reg':
   drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: error: 'i915' undeclared 
(first use in this function); did you mean 'to_i915'?
  if (intel_vgpu_active(i915))
^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:3: note: in expansion of macro 
>> 'if'
  if (intel_vgpu_active(i915))
  ^~
   drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: note: each undeclared 
identifier is reported only once for each function it appears in
  if (intel_vgpu_active(i915))
^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:3: note: in expansion of macro 
>> 'if'
  if (intel_vgpu_active(i915))
  ^~

vim +/if +98 drivers/gpu/drm/i915/i915_gem_fence_reg.c

  > 24  #include 
25  #include 
26  #include "i915_drv.h"
27  
28  /**
29   * DOC: fence register handling
30   *
31   * Important to avoid confusions: "fences" in the i915 driver are not 
execution
32   * fences used to track command completion but hardware detiler objects 
which
33   * wrap a given range of the global GTT. Each platform has only a 
fairly limited
34   * set of these objects.
35   *
36   * Fences are used to detile GTT memory mappings. They're also 
connected to the
37   * hardware frontbuffer render tracking and hence interact with 
frontbuffer
38   * compression. Furthermore on older platforms fences are required for 
tiled
39   * objects used by the display engine. They can also be used by the 
render
40   * engine - they're required for blitter commands and are optional for 
render
41   * commands. But on gen4+ both display (with the exception of fbc) and 
rendering
42   * have their own tiling state bits and don't need fences.
43   *
44   * Also note that fences only support X and Y tiling and hence can't be 
used for
45   * the fancier new tiling formats like W, Ys and Yf.
46   *
47   * Finally note that because fences are such a restricted resource 
they're
48   * dynamically associated with objects. Furthermore fence state is 
committed to
49   * the hardware lazily to avoid unnecessary stalls on gen2/3. Therefore 
code must
50   * explicitly call i915_gem_object_get_fence() to synchronize fencing 
status
51   * for cpu access. Also note that some code wants an unfenced view, for 
those
52   * cases the fence can be removed forcefully with 
i915_gem_object_put_fence().
53   *
54   * Internally these functions will synchronize with userspace access by 
removing
55   * CPU ptes into GTT mmaps (not the GTT ptes themselves) as needed.
56   */
57  
58  #define pipelined 0
59  
60  static void i965_write_fence_reg(struct drm_i915_fence_reg *fence,
61   struct i915_vma *vma)
62  {
63  i915_reg_t fence_reg_lo, fence_reg_hi;
64  int fence_pitch_shift;
65  u64 val;
66  struct drm_i915_private *dev_priv = fence->i915;
67  
68  if (INTEL_GEN(fence->i915) >= 6) {
69  fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
70  fence_reg_hi = FENCE_REG_GEN6_HI(fence->id);
71  fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT;
72  
73  } else {
74  fence_reg_lo = FENCE_REG_965_LO(fence->id);
75  fenc

Re: [Intel-gfx] [PATCH 2/2] drm/i915: write fence reg only once on VGPU

2018-07-02 Thread kbuild test robot
Hi Zhao,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.18-rc3 next-20180702]
[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/Zhao-Yakui/drm-i915-the-Read-Write-optimization-of-fence-reg/20180703-102412
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x074-201826 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/i915_gem_fence_reg.c: In function 
'i965_write_fence_reg':
>> drivers/gpu//drm/i915/i915_gem_fence_reg.c:98:25: error: 'i915' undeclared 
>> (first use in this function); did you mean 'to_i915'?
  if (intel_vgpu_active(i915))
^~~~
to_i915
   drivers/gpu//drm/i915/i915_gem_fence_reg.c:98:25: note: each undeclared 
identifier is reported only once for each function it appears in

vim +98 drivers/gpu//drm/i915/i915_gem_fence_reg.c

59  
60  static void i965_write_fence_reg(struct drm_i915_fence_reg *fence,
61   struct i915_vma *vma)
62  {
63  i915_reg_t fence_reg_lo, fence_reg_hi;
64  int fence_pitch_shift;
65  u64 val;
66  struct drm_i915_private *dev_priv = fence->i915;
67  
68  if (INTEL_GEN(fence->i915) >= 6) {
69  fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
70  fence_reg_hi = FENCE_REG_GEN6_HI(fence->id);
71  fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT;
72  
73  } else {
74  fence_reg_lo = FENCE_REG_965_LO(fence->id);
75  fence_reg_hi = FENCE_REG_965_HI(fence->id);
76  fence_pitch_shift = I965_FENCE_PITCH_SHIFT;
77  }
78  
79  val = 0;
80  if (vma) {
81  unsigned int stride = 
i915_gem_object_get_stride(vma->obj);
82  
83  GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
84  GEM_BUG_ON(!IS_ALIGNED(vma->node.start, 
I965_FENCE_PAGE));
85  GEM_BUG_ON(!IS_ALIGNED(vma->fence_size, 
I965_FENCE_PAGE));
86  GEM_BUG_ON(!IS_ALIGNED(stride, 128));
87  
88  val = (vma->node.start + vma->fence_size - 
I965_FENCE_PAGE) << 32;
89  val |= vma->node.start;
90  val |= (u64)((stride / 128) - 1) << fence_pitch_shift;
91  if (i915_gem_object_get_tiling(vma->obj) == 
I915_TILING_Y)
92  val |= BIT(I965_FENCE_TILING_Y_SHIFT);
93  val |= I965_FENCE_REG_VALID;
94  }
95  
96  if (INTEL_GEN(fence->i915) >= 6) {
97  /* Use the 64-bit RW to read/write fence reg on SNB+ */
  > 98  if (intel_vgpu_active(i915))
99  I915_WRITE64_FW(fence_reg_lo, val);
   100  else {
   101  I915_WRITE64_FW(fence_reg_lo, 0);
   102  I915_READ64(fence_reg_lo);
   103  
   104  I915_WRITE64_FW(fence_reg_lo, val);
   105  I915_READ64(fence_reg_lo);
   106  }
   107  } else {
   108  /* To w/a incoherency with non-atomic 64-bit register 
updates,
   109   * we split the 64-bit update into two 32-bit writes. 
In order
   110   * for a partial fence not to be evaluated between 
writes, we
   111   * precede the update with write to turn off the fence 
register,
   112   * and only enable the fence as the last step.
   113   *
   114   * For extra levels of paranoia, we make sure each step 
lands
   115   * before applying the next step.
   116   */
   117  I915_WRITE(fence_reg_lo, 0);
   118  POSTING_READ(fence_reg_lo);
   119  
   120  I915_WRITE(fence_reg_hi, upper_32_bits(val));
   121  I915_WRITE(fence_reg_lo, lower_32_bits(val));
   122  POSTING_READ(fence_reg_lo);
   123  }
   124  }
   125  

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Optimize the read/write fence_reg on SNB+

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Optimize the read/write fence_reg on SNB+
URL   : https://patchwork.freedesktop.org/series/45801/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4417 -> Patchwork_9503 =

== Summary - WARNING ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS


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


== Participating hosts (45 -> 40) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4417 -> Patchwork_9503

  CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9503: e8b6a25966721c297a1d15b6c0749775bcc086cb @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e8b6a2596672 drm/i915: write fence reg only once on VGPU
51157a4ce265 drm/i915: Use 64-bit to Read/Write fence reg on SNB+

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Optimize the read/write fence_reg on SNB+

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Optimize the read/write fence_reg on SNB+
URL   : https://patchwork.freedesktop.org/series/45801/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
51157a4ce265 drm/i915: Use 64-bit to Read/Write fence reg on SNB+
e8b6a2596672 drm/i915: write fence reg only once on VGPU
-:30: CHECK:BRACES: Unbalanced braces around else statement
#30: FILE: drivers/gpu/drm/i915/i915_gem_fence_reg.c:100:
+   else {

total: 0 errors, 0 warnings, 1 checks, 20 lines checked

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


[Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on VGPU

2018-07-02 Thread Zhao Yakui
On VGPU scenario the read/write operation of fence_reg will be trapped
by the GVT-g. And then gvt-g follows the HW spec to write the fence_reg.
So it is unnecessary to read/write fence reg several times. This will help
to reduce the unnecessary trap of fence_reg mmio operation.

V1->V2: Fix one typo error of parameter when calling intel_vgpu_active

Signed-off-by: Zhao Yakui 
---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index d92fe03..9c97976 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -95,11 +95,15 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg 
*fence,
 
if (INTEL_GEN(fence->i915) >= 6) {
/* Use the 64-bit RW to read/write fence reg on SNB+ */
-   I915_WRITE64_FW(fence_reg_lo, 0);
-   I915_READ64(fence_reg_lo);
-
-   I915_WRITE64_FW(fence_reg_lo, val);
-   I915_READ64(fence_reg_lo);
+   if (intel_vgpu_active(dev_priv))
+   I915_WRITE64_FW(fence_reg_lo, val);
+   else {
+   I915_WRITE64_FW(fence_reg_lo, 0);
+   I915_READ64(fence_reg_lo);
+
+   I915_WRITE64_FW(fence_reg_lo, val);
+   I915_READ64(fence_reg_lo);
+   }
} else {
/* To w/a incoherency with non-atomic 64-bit register updates,
 * we split the 64-bit update into two 32-bit writes. In order
-- 
2.7.4

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


[Intel-gfx] [PATCH v2 0/2] drm/i915: Optimize the read/write fence_reg on SNB+

2018-07-02 Thread Zhao Yakui
V1->V2: Fix one typo error.

Zhao Yakui (2):
  drm/i915: Use 64-bit to Read/Write fence reg on SNB+
  drm/i915: write fence reg only once on VGPU

 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH v2 1/2] drm/i915: Use 64-bit to Read/Write fence reg on SNB+

2018-07-02 Thread Zhao Yakui
Based on HW spec the fence reg on SNB+ is defined as 64-bit. Just follow
the b-spec to  use 64-bit read/write mode.

Signed-off-by: Zhao Yakui 
---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index d548ac0..d92fe03 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -63,6 +63,7 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg 
*fence,
i915_reg_t fence_reg_lo, fence_reg_hi;
int fence_pitch_shift;
u64 val;
+   struct drm_i915_private *dev_priv = fence->i915;
 
if (INTEL_GEN(fence->i915) >= 6) {
fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
@@ -92,9 +93,14 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg 
*fence,
val |= I965_FENCE_REG_VALID;
}
 
-   if (!pipelined) {
-   struct drm_i915_private *dev_priv = fence->i915;
+   if (INTEL_GEN(fence->i915) >= 6) {
+   /* Use the 64-bit RW to read/write fence reg on SNB+ */
+   I915_WRITE64_FW(fence_reg_lo, 0);
+   I915_READ64(fence_reg_lo);
 
+   I915_WRITE64_FW(fence_reg_lo, val);
+   I915_READ64(fence_reg_lo);
+   } else {
/* To w/a incoherency with non-atomic 64-bit register updates,
 * we split the 64-bit update into two 32-bit writes. In order
 * for a partial fence not to be evaluated between writes, we
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: write fence reg only once on VGPU

2018-07-02 Thread Zhao, Yakui


>-Original Message-
>From: Zhao, Yakui
>Sent: Tuesday, July 3, 2018 10:22 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: zhen...@linux.intel.com; Zhao, Yakui 
>Subject: [PATCH 2/2] drm/i915: write fence reg only once on VGPU
>
>On VGPU scenario the read/write operation of fence_reg will be trapped by
>the GVT-g. And then gvt-g follows the HW spec to write the fence_reg.
>So it is unnecessary to read/write fence reg several times. This will help to
>reduce the unnecessary trap of fence_reg mmio operation.
>

Sorry for one typo. The V2 will be sent.

>Signed-off-by: Zhao Yakui 
>---
> drivers/gpu/drm/i915/i915_gem_fence_reg.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
>b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
>index d92fe03..55bf6d9 100644
>--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
>+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
>@@ -95,11 +95,15 @@ static void i965_write_fence_reg(struct
>drm_i915_fence_reg *fence,
>
>   if (INTEL_GEN(fence->i915) >= 6) {
>   /* Use the 64-bit RW to read/write fence reg on SNB+ */
>-  I915_WRITE64_FW(fence_reg_lo, 0);
>-  I915_READ64(fence_reg_lo);
>-
>-  I915_WRITE64_FW(fence_reg_lo, val);
>-  I915_READ64(fence_reg_lo);
>+  if (intel_vgpu_active(i915))
>+  I915_WRITE64_FW(fence_reg_lo, val);
>+  else {
>+  I915_WRITE64_FW(fence_reg_lo, 0);
>+  I915_READ64(fence_reg_lo);
>+
>+  I915_WRITE64_FW(fence_reg_lo, val);
>+  I915_READ64(fence_reg_lo);
>+  }
>   } else {
>   /* To w/a incoherency with non-atomic 64-bit register updates,
>* we split the 64-bit update into two 32-bit writes. In order
>--
>2.7.4

___
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: the Read/Write optimization of fence reg

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: the Read/Write optimization of fence reg
URL   : https://patchwork.freedesktop.org/series/45800/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/i915_gem_fence_reg.o
drivers/gpu/drm/i915/i915_gem_fence_reg.c: In function ‘i965_write_fence_reg’:
drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: error: ‘i915’ undeclared 
(first use in this function); did you mean ‘to_i915’?
   if (intel_vgpu_active(i915))
 ^~~~
 to_i915
drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: note: each undeclared 
identifier is reported only once for each function it appears in
scripts/Makefile.build:317: recipe for target 
'drivers/gpu/drm/i915/i915_gem_fence_reg.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_fence_reg.o] Error 1
scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:558: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1034: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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


[Intel-gfx] [PATCH 2/2] drm/i915: write fence reg only once on VGPU

2018-07-02 Thread Zhao Yakui
On VGPU scenario the read/write operation of fence_reg will be trapped
by the GVT-g. And then gvt-g follows the HW spec to write the fence_reg.
So it is unnecessary to read/write fence reg several times. This will help
to reduce the unnecessary trap of fence_reg mmio operation.

Signed-off-by: Zhao Yakui 
---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index d92fe03..55bf6d9 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -95,11 +95,15 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg 
*fence,
 
if (INTEL_GEN(fence->i915) >= 6) {
/* Use the 64-bit RW to read/write fence reg on SNB+ */
-   I915_WRITE64_FW(fence_reg_lo, 0);
-   I915_READ64(fence_reg_lo);
-
-   I915_WRITE64_FW(fence_reg_lo, val);
-   I915_READ64(fence_reg_lo);
+   if (intel_vgpu_active(i915))
+   I915_WRITE64_FW(fence_reg_lo, val);
+   else {
+   I915_WRITE64_FW(fence_reg_lo, 0);
+   I915_READ64(fence_reg_lo);
+
+   I915_WRITE64_FW(fence_reg_lo, val);
+   I915_READ64(fence_reg_lo);
+   }
} else {
/* To w/a incoherency with non-atomic 64-bit register updates,
 * we split the 64-bit update into two 32-bit writes. In order
-- 
2.7.4

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


[Intel-gfx] [PATCH 0/2] drm/i915: the Read/Write optimization of fence reg

2018-07-02 Thread Zhao Yakui

Zhao Yakui (2):
  drm/i915: Use 64-bit to Read/Write fence reg on SNB+
  drm/i915: write fence reg only once on VGPU

 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH 1/2] drm/i915: Use 64-bit to Read/Write fence reg on SNB+

2018-07-02 Thread Zhao Yakui
Based on HW spec the fence reg on SNB+ is defined as 64-bit. Just follow
the b-spec to  use 64-bit read/write mode.

Signed-off-by: Zhao Yakui 
---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index d548ac0..d92fe03 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -63,6 +63,7 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg 
*fence,
i915_reg_t fence_reg_lo, fence_reg_hi;
int fence_pitch_shift;
u64 val;
+   struct drm_i915_private *dev_priv = fence->i915;
 
if (INTEL_GEN(fence->i915) >= 6) {
fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
@@ -92,9 +93,14 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg 
*fence,
val |= I965_FENCE_REG_VALID;
}
 
-   if (!pipelined) {
-   struct drm_i915_private *dev_priv = fence->i915;
+   if (INTEL_GEN(fence->i915) >= 6) {
+   /* Use the 64-bit RW to read/write fence reg on SNB+ */
+   I915_WRITE64_FW(fence_reg_lo, 0);
+   I915_READ64(fence_reg_lo);
 
+   I915_WRITE64_FW(fence_reg_lo, val);
+   I915_READ64(fence_reg_lo);
+   } else {
/* To w/a incoherency with non-atomic 64-bit register updates,
 * we split the 64-bit update into two 32-bit writes. In order
 * for a partial fence not to be evaluated between writes, we
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v2] drm/i915/skl+: ddb allocation algorithm optimization

2018-07-02 Thread Rodrigo Vivi
On Fri, Jun 29, 2018 at 03:13:35PM +0530, Mahesh Kumar wrote:
> This patch implements new DDB allocation algorithm as per HW team
> recommendation. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to work.
> It also takes care of enabling same watermark level for each

Usually "It also" in a commit message is a good indication that we should
be doing more than one patch.

> plane in crtc, for efficient power saving.
> This algorithm uses fixed ddb allocation for cursor planes.
> 
> Ealier version of this patch reverted due to regression. And it was root
> caused to following:
> New algorithm required more DDB for cursor plane but as cursor plane has
> fixed allocation it's DDB was not sufficient and WM level-0 was getting
> disabled, resulting in blank screen. Now we use old DDB allocation logic
> only for cursor plane.

I really don't see on spec old and new DDB allocation logics.

Only thing different for cursor that I see there is that a workaround on
watermark calculation where "For each plane, except cursor..."

"Number of planes, except cursor..."

This is not what I see in this patch, but maybe because the patch is too big.

> 
> Changes:
>  - add reason for revert in commit msg (Maarten)
>  - Fix checkpatch checks
> 
> Testcase: igt/kms_plane_multiple
> Signed-off-by: Mahesh Kumar 
> Cc: Rodrigo Vivi 

Well, since I'm on cc and I was the one that reverted that because I noticed
on my own machine I opened this patch for review many times here already,
but I gave up completely every time because this patch is hard to review.

So this time I won't fully give up and at least put some comments...

So, overall it is hard to match the spec differences because this patch
is trying to do all at once. Smaller patches should be better.

> ---
>  drivers/gpu/drm/i915/i915_drv.h |   5 +-
>  drivers/gpu/drm/i915/intel_pm.c | 376 
> +++-
>  2 files changed, 219 insertions(+), 162 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b684f431c60..f5d636a6d121 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1212,8 +1212,9 @@ struct skl_ddb_values {
>  
>  struct skl_wm_level {
>   bool plane_en;
> - uint16_t plane_res_b;
> - uint8_t plane_res_l;
> + u16 plane_res_b;
> + u8 plane_res_l;
> + u16 min_dbuf_req;
>  };
>  
>  /* Stores plane specific WM parameters */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 533e6886..d1564a08a202 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3802,17 +3802,37 @@ static unsigned int intel_get_ddb_size(struct 
> drm_i915_private *dev_priv,
>   return ddb_size;
>  }
>  
> +static int
> +skl_get_num_pipes_active(struct drm_i915_private *dev_priv,
> +  const struct intel_crtc_state *cstate)
> +{
> + struct drm_atomic_state *state = cstate->base.state;
> + const struct intel_atomic_state *intel_state;
> + int num_active;
> +
> + if (WARN_ON(!state) || !cstate->base.active)
> + return hweight32(dev_priv->active_crtcs);
> +
> + intel_state = to_intel_atomic_state(state);
> +
> + if (intel_state->active_pipe_changes)
> + num_active = hweight32(intel_state->active_crtcs);
> + else
> + num_active = hweight32(dev_priv->active_crtcs);
> +
> + return num_active;
> +}

This entire function here is something that should come in a separated patch.

> +
>  static void
> -skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
> +skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv,
>  const struct intel_crtc_state *cstate,
>  const unsigned int total_data_rate,
>  struct skl_ddb_allocation *ddb,
> -struct skl_ddb_entry *alloc, /* out */
> -int *num_active /* out */)
> +int num_active,
> +struct skl_ddb_entry *alloc /* out */)

you don't need to invert the order when removing the pointer...

but again, all this num_active seems to be in a separated patch

>  {
>   struct drm_atomic_state *state = cstate->base.state;
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> - struct drm_i915_private *dev_priv = to_i915(dev);
>   struct drm_crtc *for_crtc = cstate->base.crtc;
>   unsigned int pipe_size, ddb_size;
>   int nth_active_pipe;
> @@ -3820,17 +3840,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   if (WARN_ON(!state) || !cstate->base.active) {
>   alloc->start = 0;
>   alloc->end = 0;
> - *num_active = hweight32(dev_priv->active_

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show who pinned the pages when a leak is hit (rev3)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev3)
URL   : https://patchwork.freedesktop.org/series/45770/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4417_full -> Patchwork_9501_full =

== Summary - FAILURE ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@kms_universal_plane@cursor-fb-leak-pipe-b:
  shard-apl:  PASS -> FAIL


 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-kbl:  NOTRUN -> INCOMPLETE (fdo#103665)
  shard-glk:  PASS -> INCOMPLETE (k.org#198133, fdo#103359)
  shard-apl:  PASS -> INCOMPLETE (fdo#103927)

igt@drv_selftest@mock_scatterlist:
  shard-kbl:  NOTRUN -> DMESG-WARN (fdo#103667)

igt@gem_exec_schedule@pi-ringfull-render:
  shard-kbl:  NOTRUN -> FAIL (fdo#103158)

igt@gem_workarounds@suspend-resume-context:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_cursor_legacy@cursorb-vs-flipb-varying-size:
  shard-glk:  PASS -> DMESG-WARN (fdo#105763) +1

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

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


 Possible fixes 

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  FAIL (fdo#105703) -> PASS

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

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

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

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#103822, fdo#104724) -> PASS +1


  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4417 -> Patchwork_9501

  CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9501: 5b98af961955ee65cce7cc3a70892d3809240398 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show who pinned the pages when a leak is hit (rev3)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev3)
URL   : https://patchwork.freedesktop.org/series/45770/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4417 -> Patchwork_9501 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)


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


== Participating hosts (45 -> 40) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4417 -> Patchwork_9501

  CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9501: 5b98af961955ee65cce7cc3a70892d3809240398 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5b98af961955 drm/i915: Show who pinned the pages when a leak is hit

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Show who pinned the pages when a leak is hit (rev3)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev3)
URL   : https://patchwork.freedesktop.org/series/45770/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Show who pinned the pages when a leak is hit
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3666:16: warning: expression 
using sizeof(void)

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Show who pinned the pages when a leak is hit (rev3)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev3)
URL   : https://patchwork.freedesktop.org/series/45770/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5b98af961955 drm/i915: Show who pinned the pages when a leak is hit
-:209: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#209: FILE: drivers/gpu/drm/i915/i915_gem_object.h:253:
+   spinlock_t debug_lock;

total: 0 errors, 0 warnings, 1 checks, 200 lines checked

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


[Intel-gfx] [PATCH] drm/i915: Show who pinned the pages when a leak is hit

2018-07-02 Thread Chris Wilson
Currently, we emit a warning when freeing an object if we do so with the
pages still pinned (presumably as they are still in use somewhere). This
only tells us that there is a problem, but doesn't tell us anything
about the object or who might be pinning them and so provides no clue as
to track down the problem.

Let's try tracking everyone who pins the pages to see if we strike it
lucky and catch the culprit red handed.

v2: Suppress oom warnings, they will happen given sufficient abuse.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105360
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Kconfig.debug |   1 +
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_gem.c|   5 +-
 drivers/gpu/drm/i915/i915_gem_object.c | 109 +
 drivers/gpu/drm/i915/i915_gem_object.h |  34 
 5 files changed, 150 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 9de8b1c51a5c..84052becb279 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -43,6 +43,7 @@ config DRM_I915_DEBUG_GEM
 bool "Insert extra checks into the GEM internals"
 default n
 depends on DRM_I915_WERROR
+select STACKDEPOT
 help
   Enable extra sanity checks (including BUGs) along the GEM driver
   paths that may slow the system down and if hit hang the machine.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2cefe4c30f88..cc334a0fc91d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2990,6 +2990,8 @@ i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
 {
might_lock(&obj->mm.lock);
 
+   track_i915_gem_object_pin_pages(obj);
+
if (atomic_inc_not_zero(&obj->mm.pages_pin_count))
return 0;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 048b722cf27c..749f5f5a31f8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2465,6 +2465,7 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
 
+   untrack_i915_gem_object_pin_pages(obj);
 unlock:
mutex_unlock(&obj->mm.lock);
 }
@@ -4876,8 +4877,10 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
if (obj->ops->release)
obj->ops->release(obj);
 
-   if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
+   if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) {
+   show_i915_gem_object_pin_pages(obj);
atomic_set(&obj->mm.pages_pin_count, 0);
+   }
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
 
diff --git a/drivers/gpu/drm/i915/i915_gem_object.c 
b/drivers/gpu/drm/i915/i915_gem_object.c
index aab8cdd80e6d..39b1e84bf494 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/i915_gem_object.c
@@ -25,6 +25,115 @@
 #include "i915_drv.h"
 #include "i915_gem_object.h"
 
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+
+#include 
+
+#define STACKDEPTH 12
+
+void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+   unsigned long entries[STACKDEPTH];
+   struct stack_trace trace = {
+   .entries = entries,
+   .max_entries = ARRAY_SIZE(entries),
+   .skip = 1
+   };
+   unsigned long flags;
+   depot_stack_handle_t stack, *stacks;
+
+   save_stack_trace(&trace);
+   if (trace.nr_entries &&
+   trace.entries[trace.nr_entries - 1] == ULONG_MAX)
+   trace.nr_entries--;
+
+   stack = depot_save_stack(&trace, GFP_KERNEL | __GFP_NOWARN);
+   if (!stack)
+   return;
+
+   spin_lock_irqsave(&obj->mm.debug_lock, flags);
+   stacks = krealloc(obj->mm.debug_owners,
+ (obj->mm.debug_count + 1) * sizeof(*stacks),
+ GFP_NOWAIT | __GFP_NOWARN);
+   if (stacks) {
+   stacks[obj->mm.debug_count++] = stack;
+   obj->mm.debug_owners = stacks;
+   }
+   spin_unlock_irqrestore(&obj->mm.debug_lock, flags);
+}
+
+void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+   depot_stack_handle_t *stacks;
+   unsigned long flags;
+
+   spin_lock_irqsave(&obj->mm.debug_lock, flags);
+   stacks = fetch_and_zero(&obj->mm.debug_owners);
+   obj->mm.debug_count = 0;
+   spin_unlock_irqrestore(&obj->mm.debug_lock, flags);
+
+   kfree(stacks);
+}
+
+static int cmphandle(const void *_a, const void *_b)
+{
+   const depot_stack_handle_t * const a = _a, * const b = _b;
+
+   if (*a < *b)
+   return -1;
+   else if (*a > *b)

Re: [Intel-gfx] [PATCH] usb/icl: Work around ACPI boottime crash

2018-07-02 Thread Chris Wilson
Quoting Imre Deak (2018-07-02 14:57:56)
> Work around the following boot time crash:
> 
> [   10.456056] CPU: 1 PID: 220 Comm: systemd-udevd Tainted: GW
>  4.17.0-rc7-CI-CI_DRM_4040+ #182
> [   10.465828] Hardware name: Intel Corporation Ice Lake Client 
> Platform/IceLake U DDR4 SODIMM PD RVP, BIOS
> +ICLSFWR1.R00.2204.A00.1805172221 05/17/2018
> [   10.479168] RIP: 0010:acpi_ps_complete_this_op+0xa7/0x22a
> [   10.484627] RSP: 0018:c93a7578 EFLAGS: 00010202
> [   10.489881] RAX: 6b6b6b6b6b6b6b6b RBX: 8804abeda9c8 RCX: 
> 0020
> [   10.497045] RDX:  RSI: 88049e604a68 RDI: 
> 
> [   10.504213] RBP:  R08: 8804abeda9c8 R09: 
> 
> [   10.511376] R10:  R11:  R12: 
> 000e
> [   10.518542] R13: 88049e604a68 R14: 88049e604a68 R15: 
> a00263c2
> [   10.525713] FS:  7ff6d85f18c0() GS:8804be88() 
> knlGS:
> [   10.533839] CS:  0010 DS:  ES:  CR0: 80050033
> [   10.539616] CR2: 7ff6d73cff40 CR3: 00049f794001 CR4: 
> 00760ee0
> [   10.546783] DR0:  DR1:  DR2: 
> 
> [   10.553949] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   10.561112] PKRU: 5554
> [   10.563849] Call Trace:
> [   10.566323]  acpi_ps_complete_op+0x49/0x3f1
> [   10.570537]  acpi_ps_parse_loop+0x94c/0x9bb
> [   10.574754]  ? acpi_ds_delete_walk_state+0x113/0x131
> [   10.579750]  acpi_ps_parse_aml+0x1a2/0x4af
> [   10.583875]  acpi_ps_execute_method+0x1e9/0x2a5
> [   10.588435]  acpi_ns_evaluate+0x2e4/0x42c
> [   10.592473]  acpi_evaluate_object+0x1fd/0x3a8
> [   10.596873]  usb_acpi_find_companion+0xee/0x1f0 [usbcore]
> [   10.602319]  acpi_platform_notify+0x33/0xa0
> [   10.606532]  device_add+0x197/0x600
> [   10.610048]  ? __init_waitqueue_head+0x36/0x50
> [   10.614529]  usb_hub_create_port_device+0x11d/0x340 [usbcore]
> [   10.620314]  hub_probe+0x9a5/0x1010 [usbcore]
> [   10.624701]  ? _raw_spin_unlock_irqrestore+0x51/0x60
> [   10.629730]  usb_probe_interface+0x13f/0x300 [usbcore]
> [   10.634900]  driver_probe_device+0x302/0x470
> [   10.639198]  ? __driver_attach+0xe0/0xe0
> [   10.643147]  bus_for_each_drv+0x59/0x90
> [   10.647013]  __device_attach+0xb7/0x130
> [   10.650878]  bus_probe_device+0x9c/0xb0
> [   10.654745]  device_add+0x3c5/0x600
> [   10.658270]  usb_set_configuration+0x540/0x880 [usbcore]
> [   10.663621]  generic_probe+0x28/0x80 [usbcore]
> [   10.668097]  driver_probe_device+0x302/0x470
> [   10.672393]  ? __driver_attach+0xe0/0xe0
> [   10.676346]  bus_for_each_drv+0x59/0x90
> [   10.680211]  __device_attach+0xb7/0x130
> [   10.684076]  bus_probe_device+0x9c/0xb0
> [   10.687940]  device_add+0x3c5/0x600
> [   10.691464]  usb_new_device+0x269/0x490 [usbcore]
> [   10.696206]  usb_add_hcd+0x558/0x850 [usbcore]
> [   10.700682]  xhci_pci_probe+0x13d/0x240 [xhci_pci]
> [   10.705534]  pci_device_probe+0xa1/0x130
> [   10.709484]  driver_probe_device+0x302/0x470
> [   10.713784]  __driver_attach+0xb9/0xe0
> [   10.717562]  ? driver_probe_device+0x470/0x470
> [   10.722033]  ? driver_probe_device+0x470/0x470
> [   10.726505]  bus_for_each_dev+0x64/0x90
> [   10.730370]  ? preempt_count_sub+0x92/0xd0
> [   10.734495]  bus_add_driver+0x164/0x260
> [   10.738362]  ? 0xa004e000
> [   10.741704]  driver_register+0x57/0xc0
> [   10.745482]  ? 0xa004e000
> [   10.748824]  do_one_initcall+0x4a/0x350
> [   10.752690]  ? do_init_module+0x22/0x20a
> [   10.756643]  ? rcu_read_lock_sched_held+0x74/0x80
> [   10.761377]  ? kmem_cache_alloc_trace+0x284/0x2e0
> [   10.766114]  do_init_module+0x5b/0x20a
> [   10.769895]  load_module+0x250d/0x2b20
> [   10.773678]  ? kernel_read+0x2c/0x40
> [   10.777285]  ? __se_sys_finit_module+0xaa/0xc0
> [   10.781759]  __se_sys_finit_module+0xaa/0xc0
> [   10.786061]  do_syscall_64+0x54/0x190
> [   10.789752]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [   10.794831] RIP: 0033:0x7ff6d74664d9
> [   10.798430] RSP: 002b:7ffd91e7dd78 EFLAGS: 0246 ORIG_RAX: 
> 0139
> [   10.806033] RAX: ffda RBX: 560519bfae20 RCX: 
> 7ff6d74664d9
> [   10.813195] RDX:  RSI: 7ff6d795ce23 RDI: 
> 000e
> [   10.820360] RBP: 7ff6d795ce23 R08:  R09: 
> 
> [   10.827523] R10: 000e R11: 0246 R12: 
> 
> [   10.834690] R13: 560519bf9a30 R14: 0002 R15: 
> 0aba9500
> [   10.841862] Code: c2 10 5f ea 81 48 c7 c6 f0 5e ea 81 bf 7c 00 00 00 e8 0d 
> 7c 00 00 31 ed e9 88 01 00 00 48 8b 03 31 ed 48 85 c0
> +0f 84 e9 00 00 00 <4c> 8b 60 28 4d 85 e4 0f 84 dc 00 00 00 0f b7 78 0a e8 62 
> fe ff
> [   10.860832] RIP: acpi_ps_complete_this_op+0xa7/0x22a RSP: c93a7578
> [   10.867907] ---[ end trace 3a0d2ee1129bc71e ]---
> 
> Cc: Chris Wils

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)
URL   : https://patchwork.freedesktop.org/series/45580/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4413_full -> Patchwork_9500_full =

== Summary - WARNING ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  PASS -> SKIP

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


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_schedule@pi-ringfull-bsd2:
  shard-kbl:  NOTRUN -> FAIL (fdo#103158)

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

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

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#103822, fdo#104724) +1

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


 Possible fixes 

igt@gem_workarounds@suspend-resume-context:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

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

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  FAIL (fdo#103822, fdo#104724) -> PASS


 Warnings 

igt@drv_selftest@live_gtt:
  shard-glk:  INCOMPLETE -> FAIL (fdo#105347)


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4413 -> Patchwork_9500

  CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9500: 1a05980f45a6d7c09fdfdb2761611bee4803cdad @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


Re: [Intel-gfx] [PATCH v8 2/2] drm/i915: Wait for PSR exit before checking for vblank evasion

2018-07-02 Thread Dhinakaran Pandiyan
On Fri, 2018-06-29 at 16:26 -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-06-27 at 13:02 -0700, Tarun Vyas wrote:
> > 
> > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited,
> > then
> > the pipe_update_start call schedules itself out to check back
> > later.
> > 
> > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915
> > but
> > lags w.r.t core kernel code, hot plugging an external display
> > triggers
> > tons of "potential atomic update errors" in the dmesg, on *pipe A*.
> > A
> > closer analysis reveals that we try to read the scanline 3 times
> > and
> > eventually timeout, b/c PSR hasn't exited fully leading to a
> > PIPEDSL
> > stuck @ 1599. This issue is not seen on upstream kernels, b/c for
> > *some*
> > reason we loop inside intel_pipe_update start for ~2+ msec which in
> > this
> > case is more than enough to exit PSR fully, hence an *unstuck*
> > PIPEDSL
> > counter, hence no error. On the other hand, the ChromeOS kernel
> > spends
> > ~1.1 msec looping inside intel_pipe_update_start and hence errors
> > out
> > b/c the source is still in PSR.
> > 
> > Regardless, we should wait for PSR exit (if PSR is disabled, we
> > incur
> > a ~1-2 usec penalty) before reading the PIPEDSL, b/c if we haven't
> > fully exited PSR, then checking for vblank evasion isn't actually
> > applicable.
> > 
> > v4: Comment explaining psr_wait after enabling VBL interrupts (DK)
> > 
> > v5: CAN_PSR() to handle platforms that don't support PSR.
> > 
> > v6: Handle local_irq_disable on early return (Chris)
>  
> Series Reviewed-by: Dhinakaran Pandiyan
> 
> 
> Daniel's questions were addressed over IRC, I'll push this version if
> they aren't any other concerns.

and pushed to -dinq with Daniel's irc ack.

" ickle: danvet ack on the PSR wait_for_idle series? 
 sure"

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


Re: [Intel-gfx] [PATCH] drm/i915/psr: Add psr1 live status

2018-07-02 Thread Dhinakaran Pandiyan
On Wed, 2018-06-27 at 13:38 +0530, vathsala nagaraju wrote:
> From: Vathsala Nagaraju 
> 
> Prints live state of psr1.Extending the existing
> PSR2 live state function to cover psr1.
> 
> Tested on KBL with psr2 and psr1 panel.
> 
> v2: rebase
> v3: DK
> Rename psr2_live_status to psr_source_status.
> v4: DK
> Move EDP_PSR_STATUS_STATE_SHIFT below EDP_PSR_STATUS_STATE_MASK.
> Pass seq to psr_source_status, handle source status prints in
> psr_source_status.
> v5: Fixed CI warning messages
> v6:
> Remove extra space in the title before the colon.(DK)
> Rebase. (Jani)
> v7: Use tabs for indenting the values.(Jani)
> v8: Addressed dk's review comments.
> 
> Cc: Rodrigo Vivi 
> Cc: Dhinakaran Pandiyan 
> 
> Reviewed-by: Dhinakaran Pandiyan 
> Signed-off-by: Vathsala Nagaraju 

I have pushed this version to -dinq, thanks for addressing the reviews.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Remove unecessary check for unsupported modifiers for NV12

2018-07-02 Thread Dhinakaran Pandiyan
On Thu, 2018-06-28 at 11:36 -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-06-28 at 08:48 +0200, Daniel Vetter wrote:
> > 
> > On Wed, Jun 27, 2018 at 11:18:54PM -0700, Dhinakaran Pandiyan
> > wrote:
> > > 
> > > 
> > > There is already a check to allow only RGB formats with CCS
> > > modifiers.
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan  > > >
> > Reviewed-by: Daniel Vetter 
> > 
> Thanks for the reviews.
Pushed this to -dinq.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3)
URL   : https://patchwork.freedesktop.org/series/45774/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4413_full -> Patchwork_9499_full =

== Summary - FAILURE ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@kms_available_modes_crc@available_mode_test_crc:
  shard-apl:  PASS -> FAIL


 Warnings 

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


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_big:
  shard-hsw:  PASS -> INCOMPLETE (fdo#103540) +1

igt@gem_exec_schedule@pi-ringfull-bsd2:
  shard-kbl:  NOTRUN -> FAIL (fdo#103158)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105189)

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

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


 Possible fixes 

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  FAIL (fdo#103822, fdo#104724) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4413 -> Patchwork_9499

  CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9499: e3d5d0eb50dde824f73f6ee82168f9d3b284bf71 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


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

2018-07-02 Thread Daniele Ceraolo Spurio



On 29/06/18 09:50, Lis, Tomasz wrote:



On 2018-06-11 18:37, Daniele Ceraolo Spurio wrote:



On 25/05/18 11:26, Tomasz Lis wrote:

The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result 
from

Context Status Buffer.

Preemption in previous gens required a special batch buffer to be 
executed,
so the Command Streamer never preempted to idle directly. In Icelake 
it is

possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.

This patch does not cover using the new preemption mechanism when GuC is
active.

v2: Added needs_preempt_context() change so that it is not created when
 preempt-to-idle is supported. (Chris)
 Updated setting HWACK flag so that it is cleared after
 preempt-to-dle. (Chris, Daniele)
 Updated to use I915_ENGINE_HAS_PREEMPTION flag. (Chris)

v3: Fixed needs_preempt_context() change. (Chris)
 Merged preemption trigger functions to one. (Chris)
 Fixed conyext state tonot assume COMPLETED_MASK after preemption,
 since idle-to-idle case will not have it set.

v4: Simplified needs_preempt_context() change. (Daniele)
 Removed clearing HWACK flag in idle-to-idle preempt. (Daniele)

Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Winiarski 
Cc: Mika Kuoppala 
Bspec: 18922
Signed-off-by: Tomasz Lis 
---
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/i915_gem_context.c  |   3 +-
  drivers/gpu/drm/i915/i915_pci.c  |   3 +-
  drivers/gpu/drm/i915/intel_device_info.h |   1 +
  drivers/gpu/drm/i915/intel_lrc.c | 113 
+--

  drivers/gpu/drm/i915/intel_lrc.h |   1 +
  6 files changed, 86 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 487922f..35eddf7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2534,6 +2534,8 @@ intel_info(const struct drm_i915_private 
*dev_priv)

  ((dev_priv)->info.has_logical_ring_elsq)
  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
  ((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+    ((dev_priv)->info.has_hw_preempt_to_idle)
    #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
  diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c

index 45393f6..341a5ff 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -455,7 +455,8 @@ destroy_kernel_context(struct i915_gem_context 
**ctxp)

    static bool needs_preempt_context(struct drm_i915_private *i915)
  {
-    return HAS_LOGICAL_RING_PREEMPTION(i915);
+    return HAS_LOGICAL_RING_PREEMPTION(i915) &&
+   !HAS_HW_PREEMPT_TO_IDLE(i915);
  }
    int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c 
b/drivers/gpu/drm/i915/i915_pci.c

index 97a91e6a..ee09926 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -593,7 +593,8 @@ static const struct intel_device_info 
intel_cannonlake_info = {

  GEN(11), \
  .ddb_size = 2048, \
  .has_csr = 0, \
-    .has_logical_ring_elsq = 1
+    .has_logical_ring_elsq = 1, \
+    .has_hw_preempt_to_idle = 1
    static const struct intel_device_info intel_icelake_11_info = {
  GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h

index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
  func(has_logical_ring_contexts); \
  func(has_logical_ring_elsq); \
  func(has_logical_ring_preemption); \
+    func(has_hw_preempt_to_idle); \
  func(has_overlay); \
  func(has_pooled_eu); \
  func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
b/drivers/gpu/drm/i915/intel_lrc.c

index 8a6058b..f95cb37 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -154,6 +154,7 @@
  #define GEN8_CTX_STATUS_ACTIVE_IDLE    (1 << 3)
  #define GEN8_CTX_STATUS_COMPLETE    (1 << 4)
  #define GEN8_CTX_STATUS_LITE_RESTORE    (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE    (1 << 29)
    #define GEN8_CTX_STATUS_COMPLETED_MASK \
   (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -522,31 +523,46 @@ static void port_assign(struct execlist_port 
*port, struct i915_request *rq)

  static void inject_preempt_context(struct intel_engine_cs *engine)


continuing the discussion from the previous patch, I still think that 
we should rename this function now that it doesn't inject a context on 
some gens. A new function name should be relatively trivial to handle 
from other patch series hitting the area (compared to having a second

Re: [Intel-gfx] [PATCH 10/10] drm/vmwgfx: Use drm_plane_mask() & co.

2018-07-02 Thread Sinclair Yeh
Reviewed-by: Sinclair Yeh 

I assume you'll upstream this as part of your series?

On Tue, Jun 26, 2018 at 10:47:16PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use drm_{plane,connector}_mask() where appropriate.
> 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index ef96ba7432ad..17e01423ead1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -535,9 +535,9 @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
>struct drm_crtc_state *new_state)
>  {
>   struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
> - int connector_mask = 1 << drm_connector_index(&du->connector);
> + int connector_mask = drm_connector_mask(&du->connector);
>   bool has_primary = new_state->plane_mask &
> -BIT(drm_plane_index(crtc->primary));
> +drm_plane_mask(crtc->primary);
>  
>   /* We always want to have an active plane with an active CRTC */
>   if (has_primary != new_state->enable)
> -- 
> 2.16.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 8/9] drm/tinydrm: Use drm_fbdev_generic_setup()

2018-07-02 Thread David Lechner

On 07/02/2018 08:54 AM, Noralf Trønnes wrote:

Make full use of the generic fbdev client.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---


Reviewed-by: David Lechner 


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


Re: [Intel-gfx] [PATCH v4 9/9] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()

2018-07-02 Thread David Lechner

On 07/02/2018 08:54 AM, Noralf Trønnes wrote:

Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
---


Reviewed-by: David Lechner 


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


[Intel-gfx] ✓ Fi.CI.IGT: success for usb/icl: Work around ACPI boottime crash

2018-07-02 Thread Patchwork
== Series Details ==

Series: usb/icl: Work around ACPI boottime crash
URL   : https://patchwork.freedesktop.org/series/45778/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4412_full -> Patchwork_9498_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-apl:  PASS -> FAIL (fdo#105347)

igt@gem_tiled_fence_blits@normal:
  shard-snb:  NOTRUN -> INCOMPLETE (fdo#105411)

igt@gem_workarounds@suspend-resume-context:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103822)

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


 Possible fixes 

igt@drv_suspend@shrink:
  shard-glk:  FAIL (fdo#106886) -> PASS

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

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

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#105363, fdo#102887) -> PASS

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS

igt@perf_pmu@busy-idle-no-semaphores-vecs0:
  shard-snb:  INCOMPLETE (fdo#105411) -> SKIP


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4412 -> Patchwork_9498

  CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9498: f195f00e11e20013ab321df784e9b806aefc81c6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


Re: [Intel-gfx] [PATCH 00/10] Improve crc-core driver interface

2018-07-02 Thread Alex Deucher
+ Harry and Leo


On Mon, Jul 2, 2018 at 7:07 AM, Mahesh Kumar  wrote:
> This series improves crc-core <-> driver interface.
> This series adds following functionality in the crc-core
>  - Now control node will print all the available sources if
>implemented by driver along with current source.
>  - Setting of sorce will fail if provided source is not supported
>  - cleanup of crtc_crc_open function first allocate memory before
>enabling CRC generation
>  - Don't block open() call instead wait in crc read call.
>
> Following IGT will fail due to crc-core <-> driver interface change
> igt@kms_pipe_crc_basic@bad-source 
> ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X
> ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X-frame-sequence
> In nonblocking crc tests we'll get lesser crc's due to skipping crc
>
> AMD/Rockchip/rcar code path is not validated and need inputs
>
> Changes:
>  - Add dri-devel in Cc
> Changes rev2:
>  - now get_crc_sources returns a constant pointer to an array of
>source list and crc-core does the verification
> Changes rev3:
>  - reorg patches to push non r-b patches to the last
>  - add r-b tag
>
> Cc: dri-de...@lists.freedesktop.org
>
> Mahesh Kumar (10):
>   drm: crc: Introduce verify_crc_source callback
>   drm: crc: Introduce get_crc_sources callback
>   drm/rockchip/crc: Implement verify_crc_source callback
>   drm/amdgpu_dm/crc: Implement verify_crc_source callback
>   drm/rcar-du/crc: Implement verify_crc_source callback
>   drm/i915/crc: implement verify_crc_source callback
>   drm/i915/crc: implement get_crc_sources callback
>   drm/crc: Cleanup crtc_crc_open function
>   Revert "drm: crc: Wait for a frame before returning from open()"
>   drm: crc: Introduce pre_crc_read function
>
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |   1 +
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |   7 +-
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  |  20 +++-
>  drivers/gpu/drm/drm_debugfs_crc.c  |  79 --
>  drivers/gpu/drm/i915/intel_display.c   |   2 +
>  drivers/gpu/drm/i915/intel_drv.h   |   9 +-
>  drivers/gpu/drm/i915/intel_pipe_crc.c  | 119 
> -
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  45 +++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  26 -
>  include/drm/drm_crtc.h |  48 -
>  10 files changed, 305 insertions(+), 51 deletions(-)
>
> --
> 2.16.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)
URL   : https://patchwork.freedesktop.org/series/45580/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4413 -> Patchwork_9500 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

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

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS


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


== Participating hosts (45 -> 40) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4413 -> Patchwork_9500

  CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9500: 1a05980f45a6d7c09fdfdb2761611bee4803cdad @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1a05980f45a6 drm/tilcdc: Use drm_connector_has_possible_encoder()
51b4ba4680b6 drm/msm: Use drm_connector_has_possible_encoder()
f2e15e4ea45b drm: Add drm_connector_has_possible_encoder()
a84c10f13c19 drm/radeon: Use drm_connector_for_each_possible_encoder()
8807427952c1 drm/nouveau: Use drm_connector_for_each_possible_encoder()
9ac85a361c63 drm/amdgpu: Use drm_connector_for_each_possible_encoder()
c31cba14dcaa drm: Add drm_connector_for_each_possible_encoder()
bd08e651f318 drm/i915: Nuke intel_mst_best_encoder()
27feace2e181 drm/fb-helper: Eliminate the .best_encoder() usage

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/atomic-helper: Use old/new state in drm_atomic_helper_commit_planes_on_crtc()

2018-07-02 Thread Ville Syrjälä
On Wed, Jun 27, 2018 at 10:59:49AM +0200, Daniel Vetter wrote:
> On Tue, Jun 26, 2018 at 11:41:44PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Update drm_atomic_helper_commit_planes_on_crtc() to use explicit old/new
> > states instead of relying on obj->state.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Daniel Vetter 

Thansk. Pushed to drm-misc-next.

> 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 15 ++-
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index e022cacdae34..8008a7de2e10 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2342,11 +2342,13 @@ drm_atomic_helper_commit_planes_on_crtc(struct 
> > drm_crtc_state *old_crtc_state)
> > const struct drm_crtc_helper_funcs *crtc_funcs;
> > struct drm_crtc *crtc = old_crtc_state->crtc;
> > struct drm_atomic_state *old_state = old_crtc_state->state;
> > +   struct drm_crtc_state *new_crtc_state =
> > +   drm_atomic_get_new_crtc_state(old_state, crtc);
> > struct drm_plane *plane;
> > unsigned plane_mask;
> >  
> > plane_mask = old_crtc_state->plane_mask;
> > -   plane_mask |= crtc->state->plane_mask;
> > +   plane_mask |= new_crtc_state->plane_mask;
> >  
> > crtc_funcs = crtc->helper_private;
> > if (crtc_funcs && crtc_funcs->atomic_begin)
> > @@ -2355,6 +2357,8 @@ drm_atomic_helper_commit_planes_on_crtc(struct 
> > drm_crtc_state *old_crtc_state)
> > drm_for_each_plane_mask(plane, crtc->dev, plane_mask) {
> > struct drm_plane_state *old_plane_state =
> > drm_atomic_get_old_plane_state(old_state, plane);
> > +   struct drm_plane_state *new_plane_state =
> > +   drm_atomic_get_new_plane_state(old_state, plane);
> > const struct drm_plane_helper_funcs *plane_funcs;
> >  
> > plane_funcs = plane->helper_private;
> > @@ -2362,13 +2366,14 @@ drm_atomic_helper_commit_planes_on_crtc(struct 
> > drm_crtc_state *old_crtc_state)
> > if (!old_plane_state || !plane_funcs)
> > continue;
> >  
> > -   WARN_ON(plane->state->crtc && plane->state->crtc != crtc);
> > +   WARN_ON(new_plane_state->crtc &&
> > +   new_plane_state->crtc != crtc);
> >  
> > -   if (drm_atomic_plane_disabling(old_plane_state, plane->state) &&
> > +   if (drm_atomic_plane_disabling(old_plane_state, 
> > new_plane_state) &&
> > plane_funcs->atomic_disable)
> > plane_funcs->atomic_disable(plane, old_plane_state);
> > -   else if (plane->state->crtc ||
> > -drm_atomic_plane_disabling(old_plane_state, 
> > plane->state))
> > +   else if (new_plane_state->crtc ||
> > +drm_atomic_plane_disabling(old_plane_state, 
> > new_plane_state))
> > plane_funcs->atomic_update(plane, old_plane_state);
> > }
> >  
> > -- 
> > 2.16.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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


Re: [Intel-gfx] [PATCH 01/10] drm: Add drm_plane_mask()

2018-07-02 Thread Ville Syrjälä
On Tue, Jun 26, 2018 at 01:09:53PM -0700, Rodrigo Vivi wrote:
> On Tue, Jun 26, 2018 at 10:47:07PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Add drm_plane_mask() which returns the 1< > We already have an identical drm_crtc_mask() for crtcs.
> > 
> > Mostly performed with coccinelle:
> > @@
> > @@
> > - (1< > + drm_plane_mask(
> >   ...)
> > -  )
> > 
> > @@
> > @@
> > - 1< > + drm_plane_mask(
> >   ...)
> > 
> > @@
> > @@
> > - BIT(drm_plane_index(
> > + drm_plane_mask(
> >   ...)
> > - )
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Rodrigo Vivi 

Series pushed to drm-misc-next. Thanks for the reviews/acks.

> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c|  4 ++--
> >  drivers/gpu/drm/drm_framebuffer.c   |  2 +-
> >  drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
> >  include/drm/drm_plane.h | 14 --
> >  4 files changed, 16 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 178842380f75..684c9d3a1d6c 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1581,7 +1581,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
> > *plane_state,
> > if (WARN_ON(IS_ERR(crtc_state)))
> > return PTR_ERR(crtc_state);
> >  
> > -   crtc_state->plane_mask &= ~(1 << drm_plane_index(plane));
> > +   crtc_state->plane_mask &= ~drm_plane_mask(plane);
> > }
> >  
> > plane_state->crtc = crtc;
> > @@ -1591,7 +1591,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
> > *plane_state,
> >crtc);
> > if (IS_ERR(crtc_state))
> > return PTR_ERR(crtc_state);
> > -   crtc_state->plane_mask |= (1 << drm_plane_index(plane));
> > +   crtc_state->plane_mask |= drm_plane_mask(plane);
> > }
> >  
> > if (crtc)
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index ed90974a452a..781af1d42d76 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -847,7 +847,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
> > if (ret)
> > goto unlock;
> >  
> > -   plane_mask |= BIT(drm_plane_index(plane));
> > +   plane_mask |= drm_plane_mask(plane);
> > }
> >  
> > /* This list is only filled when disable_crtcs is set. */
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 7a00455ca568..9d87961da1db 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -52,7 +52,7 @@ static int drm_simple_kms_crtc_check(struct drm_crtc 
> > *crtc,
> >  struct drm_crtc_state *state)
> >  {
> > bool has_primary = state->plane_mask &
> > -  BIT(drm_plane_index(crtc->primary));
> > +  drm_plane_mask(crtc->primary);
> >  
> > /* We always want to have an active plane with an active CRTC */
> > if (has_primary != state->enable)
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index 7d4d6c7f0afd..cee9dfaaa740 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -639,10 +639,20 @@ void drm_plane_cleanup(struct drm_plane *plane);
> >   * Given a registered plane, return the index of that plane within a DRM
> >   * device's list of planes.
> >   */
> > -static inline unsigned int drm_plane_index(struct drm_plane *plane)
> > +static inline unsigned int drm_plane_index(const struct drm_plane *plane)
> >  {
> > return plane->index;
> >  }
> > +
> > +/**
> > + * drm_plane_mask - find the mask of a registered plane
> > + * @plane: plane to find mask for
> > + */
> > +static inline u32 drm_plane_mask(const struct drm_plane *plane)
> > +{
> > +   return 1 << drm_plane_index(plane);
> > +}
> > +
> >  struct drm_plane * drm_plane_from_index(struct drm_device *dev, int idx);
> >  void drm_plane_force_disable(struct drm_plane *plane);
> >  
> > @@ -678,7 +688,7 @@ static inline struct drm_plane *drm_plane_find(struct 
> > drm_device *dev,
> >   */
> >  #define drm_for_each_plane_mask(plane, dev, plane_mask) \
> > list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
> > -   for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))
> > +   for_each_if ((plane_mask) & drm_plane_mask(plane))
> >  
> >  /**
> >   * drm_for_each_legacy_plane - iterate over all planes for legacy userspace
> > -- 
> > 2.16.4
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.f

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)
URL   : https://patchwork.freedesktop.org/series/45580/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
27feace2e181 drm/fb-helper: Eliminate the .best_encoder() usage
bd08e651f318 drm/i915: Nuke intel_mst_best_encoder()
c31cba14dcaa drm: Add drm_connector_for_each_possible_encoder()
-:139: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'connector' - possible 
side-effects?
#139: FILE: include/drm/drm_connector.h:1202:
+#define drm_connector_for_each_possible_encoder(connector, encoder, __i) \
+   for ((__i) = 0; (__i) < ARRAY_SIZE((connector)->encoder_ids) && \
+(connector)->encoder_ids[(__i)] != 0; (__i)++) \
+   for_each_if((encoder) = \
+   drm_encoder_find((connector)->dev, NULL, \
+(connector)->encoder_ids[(__i)])) \
+

-:139: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible 
side-effects?
#139: FILE: include/drm/drm_connector.h:1202:
+#define drm_connector_for_each_possible_encoder(connector, encoder, __i) \
+   for ((__i) = 0; (__i) < ARRAY_SIZE((connector)->encoder_ids) && \
+(connector)->encoder_ids[(__i)] != 0; (__i)++) \
+   for_each_if((encoder) = \
+   drm_encoder_find((connector)->dev, NULL, \
+(connector)->encoder_ids[(__i)])) \
+

total: 0 errors, 0 warnings, 2 checks, 99 lines checked
9ac85a361c63 drm/amdgpu: Use drm_connector_for_each_possible_encoder()
8807427952c1 drm/nouveau: Use drm_connector_for_each_possible_encoder()
a84c10f13c19 drm/radeon: Use drm_connector_for_each_possible_encoder()
f2e15e4ea45b drm: Add drm_connector_has_possible_encoder()
-:23: WARNING:LONG_LINE_COMMENT: line over 100 characters
#23: FILE: drivers/gpu/drm/drm_connector.c:335:
+ * drm_connector_has_possible_encoder - check if the connector and encoder are 
assosicated with each other

total: 0 errors, 1 warnings, 0 checks, 38 lines checked
51b4ba4680b6 drm/msm: Use drm_connector_has_possible_encoder()
1a05980f45a6 drm/tilcdc: Use drm_connector_has_possible_encoder()

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for tests/kms_pipe_crc_basic: expect setting bad source to fail

2018-07-02 Thread Patchwork
== Series Details ==

Series: tests/kms_pipe_crc_basic: expect setting bad source to fail
URL   : https://patchwork.freedesktop.org/series/45768/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4404 -> IGTPW_1521 =

== Summary - FAILURE ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@kms_pipe_crc_basic@bad-source:
  {fi-cfl-8109u}: PASS -> FAIL
  fi-pnv-d510:PASS -> FAIL
  fi-skl-6770hq:  PASS -> FAIL
  fi-bdw-5557u:   PASS -> FAIL
  fi-bwr-2160:PASS -> FAIL
  fi-snb-2520m:   PASS -> FAIL
  fi-elk-e7500:   PASS -> FAIL
  fi-hsw-4770r:   PASS -> FAIL
  fi-glk-j4005:   PASS -> FAIL
  fi-cfl-8700k:   PASS -> FAIL
  fi-hsw-peppy:   PASS -> FAIL
  fi-bdw-gvtdvm:  PASS -> FAIL
  fi-ilk-650: PASS -> FAIL
  fi-kbl-7567u:   PASS -> FAIL
  fi-skl-guc: PASS -> FAIL
  fi-whl-u:   PASS -> FAIL
  fi-cfl-guc: PASS -> FAIL
  fi-bxt-j4205:   PASS -> FAIL
  fi-skl-6700hq:  PASS -> FAIL
  fi-ivb-3520m:   PASS -> FAIL
  fi-skl-gvtdvm:  PASS -> FAIL
  fi-gdg-551: PASS -> FAIL
  fi-kbl-7500u:   PASS -> FAIL
  {fi-kbl-x1275}: PASS -> FAIL
  fi-kbl-guc: PASS -> FAIL
  fi-skl-6600u:   PASS -> FAIL
  fi-glk-dsi: PASS -> FAIL
  fi-blb-e6850:   PASS -> FAIL
  fi-ivb-3770:PASS -> FAIL
  fi-skl-6700k2:  PASS -> FAIL
  fi-bsw-n3050:   PASS -> FAIL
  fi-snb-2600:PASS -> FAIL
  fi-hsw-4770:PASS -> FAIL
  fi-kbl-7560u:   PASS -> FAIL
  fi-bxt-dsi: PASS -> FAIL
  fi-byt-n2820:   PASS -> FAIL
  fi-skl-6260u:   PASS -> FAIL
  fi-kbl-r:   PASS -> FAIL
  fi-byt-j1900:   PASS -> FAIL
  fi-cfl-s3:  PASS -> FAIL


 Warnings 

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  {fi-cfl-8109u}: PASS -> SKIP +36


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).



== Participating hosts (45 -> 40) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* IGT: IGT_4531 -> IGTPW_1521

  CI_DRM_4404: ceaab659002c938f1788b7458d5081fadc3c1ddc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1521: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1521/
  IGT_4531: a14bc8b4d69eaca189665de505e6b10cbfbb7730 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Add generic fbdev emulation

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm: Add generic fbdev emulation
URL   : https://patchwork.freedesktop.org/series/45777/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4412_full -> Patchwork_9497_full =

== Summary - WARNING ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_schedule@pi-ringfull-render:
  shard-kbl:  NOTRUN -> FAIL (fdo#103158)

igt@gem_tiled_fence_blits@normal:
  shard-snb:  NOTRUN -> INCOMPLETE (fdo#105411)

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103822)

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)

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


 Possible fixes 

igt@drv_suspend@shrink:
  shard-glk:  FAIL (fdo#106886) -> PASS

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

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#102887, fdo#105363) -> PASS

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS

igt@perf_pmu@busy-idle-no-semaphores-vecs0:
  shard-snb:  INCOMPLETE (fdo#105411) -> SKIP


 Warnings 

igt@drv_selftest@live_gtt:
  shard-glk:  INCOMPLETE (fdo#103359, k.org#198133) -> FAIL 
(fdo#105347)


  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4412 -> Patchwork_9497

  CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9497: 8c681fb6ac510d791eeaee34a1fdc3508c79067c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


Re: [Intel-gfx] [PATCH i-g-t 05/17] lib: Spin fast, retire early

2018-07-02 Thread Tvrtko Ursulin


On 02/07/2018 10:07, Chris Wilson wrote:

When using the pollable spinner, we often want to use it as a means of
ensuring the task is running on the GPU before switching to something
else. In which case we don't want to add extra delay inside the spinner,
but the current 1000 NOPs add on order of 5us, which is often larger
than the target latency.

v2: Don't change perf_pmu as that is sensitive to the extra CPU latency
from a tight GPU spinner.

Signed-off-by: Chris Wilson 
Reviewed-by: Antonio Argenziano  #v1
Reviewed-by: Joonas Lahtinen  #v1
Cc: Tvrtko Ursulin 
---
  lib/igt_dummyload.c   | 3 ++-
  lib/igt_dummyload.h   | 1 +
  tests/gem_ctx_isolation.c | 1 +
  tests/gem_eio.c   | 1 +
  tests/gem_exec_latency.c  | 4 ++--
  5 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 94efdf745..7beb66244 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -199,7 +199,8 @@ emit_recursive_batch(igt_spin_t *spin,
 * between function calls, that appears enough to keep SNB out of
 * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
 */
-   batch += 1000;
+   if (!(opts->flags & IGT_SPIN_FAST))
+   batch += 1000;


igt_require(!snb) or something, given the comment whose last two lines 
can be seen in the diff above?


Regards,

Tvrtko

  
  	/* recurse */

r = &relocs[obj[BATCH].relocation_count++];
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index c794f2544..e80a12451 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -52,6 +52,7 @@ struct igt_spin_factory {
  
  #define IGT_SPIN_FENCE_OUT (1 << 0)

  #define IGT_SPIN_POLL_RUN  (1 << 1)
+#define IGT_SPIN_FAST  (1 << 2)
  
  igt_spin_t *

  __igt_spin_batch_factory(int fd, const struct igt_spin_factory *opts);
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
index 2e19e8c03..4325e1c28 100644
--- a/tests/gem_ctx_isolation.c
+++ b/tests/gem_ctx_isolation.c
@@ -560,6 +560,7 @@ static void inject_reset_context(int fd, unsigned int 
engine)
struct igt_spin_factory opts = {
.ctx = gem_context_create(fd),
.engine = engine,
+   .flags = IGT_SPIN_FAST,
};
igt_spin_t *spin;
  
diff --git a/tests/gem_eio.c b/tests/gem_eio.c

index 0ec1aaec9..3162a3170 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -160,6 +160,7 @@ static igt_spin_t * __spin_poll(int fd, uint32_t ctx, 
unsigned long flags)
struct igt_spin_factory opts = {
.ctx = ctx,
.engine = flags,
+   .flags = IGT_SPIN_FAST,
};
  
  	if (gem_can_store_dword(fd, opts.engine))

diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
index 75811f325..de16322a6 100644
--- a/tests/gem_exec_latency.c
+++ b/tests/gem_exec_latency.c
@@ -65,7 +65,7 @@ poll_ring(int fd, unsigned ring, const char *name)
  {
const struct igt_spin_factory opts = {
.engine = ring,
-   .flags = IGT_SPIN_POLL_RUN,
+   .flags = IGT_SPIN_POLL_RUN | IGT_SPIN_FAST,
};
struct timespec tv = {};
unsigned long cycles;
@@ -464,7 +464,7 @@ rthog_latency_on_ring(int fd, unsigned int engine, const 
char *name, unsigned in
  #define MMAP_SZ (64 << 10)
const struct igt_spin_factory opts = {
.engine = engine,
-   .flags = IGT_SPIN_POLL_RUN,
+   .flags = IGT_SPIN_POLL_RUN | IGT_SPIN_FAST,
};
struct rt_pkt *results;
unsigned int engines[16];


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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 04/17] lib: Convert spin batch constructor to a factory

2018-07-02 Thread Tvrtko Ursulin


On 02/07/2018 10:07, Chris Wilson wrote:

In order to make adding more options easier, expose the full set of
options to the caller.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  lib/igt_dummyload.c| 147 +
  lib/igt_dummyload.h|  42 +-
  tests/drv_missed_irq.c |   2 +-
  tests/gem_busy.c   |  17 ++--
  tests/gem_ctx_isolation.c  |  26 +++---
  tests/gem_eio.c|  13 ++-
  tests/gem_exec_fence.c |  16 ++--
  tests/gem_exec_latency.c   |  18 +++-
  tests/gem_exec_nop.c   |   4 +-
  tests/gem_exec_reloc.c |  10 ++-
  tests/gem_exec_schedule.c  |  27 --
  tests/gem_exec_suspend.c   |   2 +-
  tests/gem_fenced_exec_thrash.c |   2 +-
  tests/gem_shrink.c |   4 +-
  tests/gem_spin_batch.c |   4 +-
  tests/gem_sync.c   |   5 +-
  tests/gem_wait.c   |   4 +-
  tests/kms_busy.c   |  10 ++-
  tests/kms_cursor_legacy.c  |   7 +-
  tests/perf_pmu.c   |  33 +---
  tests/pm_rps.c |   9 +-
  21 files changed, 189 insertions(+), 213 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 3809b4e61..94efdf745 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -75,12 +75,9 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
reloc->write_domain = write_domains;
  }
  
-#define OUT_FENCE	(1 << 0)

-#define POLL_RUN   (1 << 1)
-
  static int
-emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine,
-uint32_t dep, unsigned int flags)
+emit_recursive_batch(igt_spin_t *spin,
+int fd, const struct igt_spin_factory *opts)
  {
  #define SCRATCH 0
  #define BATCH 1
@@ -95,21 +92,18 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t 
ctx, unsigned engine,
int i;
  
  	nengine = 0;

-   if (engine == ALL_ENGINES) {
-   for_each_engine(fd, engine) {
-   if (engine) {
-   if (flags & POLL_RUN)
-   igt_require(!(flags & POLL_RUN) ||
-   gem_can_store_dword(fd, engine));
-
-   engines[nengine++] = engine;
-   }
+   if (opts->engine == ALL_ENGINES) {
+   unsigned int engine;
+
+   for_each_physical_engine(fd, engine) {
+   if (opts->flags & IGT_SPIN_POLL_RUN &&
+   !gem_can_store_dword(fd, engine))
+   continue;
+
+   engines[nengine++] = engine;
}
} else {
-   gem_require_ring(fd, engine);
-   igt_require(!(flags & POLL_RUN) ||
-   gem_can_store_dword(fd, engine));
-   engines[nengine++] = engine;
+   engines[nengine++] = opts->engine;
}
igt_require(nengine);
  
@@ -130,20 +124,20 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine,

execbuf->buffer_count++;
batch_start = batch;
  
-	if (dep) {

-   igt_assert(!(flags & POLL_RUN));
+   if (opts->dependency) {
+   igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN));
  
  		/* dummy write to dependency */

-   obj[SCRATCH].handle = dep;
+   obj[SCRATCH].handle = opts->dependency;
fill_reloc(&relocs[obj[BATCH].relocation_count++],
-  dep, 1020,
+  opts->dependency, 1020,
   I915_GEM_DOMAIN_RENDER,
   I915_GEM_DOMAIN_RENDER);
execbuf->buffer_count++;
-   } else if (flags & POLL_RUN) {
+   } else if (opts->flags & IGT_SPIN_POLL_RUN) {
unsigned int offset;
  
-		igt_assert(!dep);

+   igt_assert(!opts->dependency);
  
  		if (gen == 4 || gen == 5) {

execbuf->flags |= I915_EXEC_SECURE;
@@ -231,9 +225,9 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t 
ctx, unsigned engine,
  
  	execbuf->buffers_ptr = to_user_pointer(obj +

   (2 - execbuf->buffer_count));
-   execbuf->rsvd1 = ctx;
+   execbuf->rsvd1 = opts->ctx;
  
-	if (flags & OUT_FENCE)

+   if (opts->flags & IGT_SPIN_FENCE_OUT)
execbuf->flags |= I915_EXEC_FENCE_OUT;
  
  	for (i = 0; i < nengine; i++) {

@@ -242,7 +236,7 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t 
ctx, unsigned engine,
  
  		gem_execbuf_wr(fd, execbuf);
  
-		if (flags & OUT_FENCE) {

+   if (opts->flags & IGT_SPIN_FENCE_OUT) {
int _fd = execbuf->rsvd2 >> 32;
  
  			igt_assert(_fd >= 0);

@@ -271,16 +265,14 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t 
ctx, unsigned engine,
  }
  
  static igt

[Intel-gfx] [PATCH v3 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()

2018-07-02 Thread Ville Syrjala
From: Ville Syrjälä 

Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.

v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
v3: Initialize nv_encoder to NULL to shut up gcc/smatch

Cc: Dan Carpenter 
Cc: Daniel Vetter 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Alex Deucher  #v1
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7b557c354307..bb46c1d489cf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -363,19 +363,11 @@ module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
 struct nouveau_encoder *
 find_encoder(struct drm_connector *connector, int type)
 {
-   struct drm_device *dev = connector->dev;
struct nouveau_encoder *nv_encoder;
struct drm_encoder *enc;
-   int i, id;
-
-   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
-   id = connector->encoder_ids[i];
-   if (!id)
-   break;
+   int i;
 
-   enc = drm_encoder_find(dev, NULL, id);
-   if (!enc)
-   continue;
+   drm_connector_for_each_possible_encoder(connector, enc, i) {
nv_encoder = nouveau_encoder(enc);
 
if (type == DCB_OUTPUT_ANY ||
@@ -420,7 +412,7 @@ nouveau_connector_ddc_detect(struct drm_connector 
*connector)
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_gpio *gpio = nvxx_gpio(&drm->client.device);
-   struct nouveau_encoder *nv_encoder;
+   struct nouveau_encoder *nv_encoder = NULL;
struct drm_encoder *encoder;
int i, panel = -ENODEV;
 
@@ -436,14 +428,7 @@ nouveau_connector_ddc_detect(struct drm_connector 
*connector)
}
}
 
-   for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
-   int id = connector->encoder_ids[i];
-   if (id == 0)
-   break;
-
-   encoder = drm_encoder_find(dev, NULL, id);
-   if (!encoder)
-   continue;
+   drm_connector_for_each_possible_encoder(connector, encoder, i) {
nv_encoder = nouveau_encoder(encoder);
 
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
-- 
2.16.4

___
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: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3)
URL   : https://patchwork.freedesktop.org/series/45774/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4413 -> Patchwork_9499 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS


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


== Participating hosts (45 -> 40) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4413 -> Patchwork_9499

  CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9499: e3d5d0eb50dde824f73f6ee82168f9d3b284bf71 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e3d5d0eb50dd drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for usb/icl: Work around ACPI boottime crash

2018-07-02 Thread Patchwork
== Series Details ==

Series: usb/icl: Work around ACPI boottime crash
URL   : https://patchwork.freedesktop.org/series/45778/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9498 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

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

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


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


== Participating hosts (43 -> 40) ==

  Additional (1): fi-byt-j1900 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4412 -> Patchwork_9498

  CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9498: f195f00e11e20013ab321df784e9b806aefc81c6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f195f00e11e2 usb/icl: Work around ACPI boottime crash

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: abstract and document register picking macros

2018-07-02 Thread Jani Nikula
On Fri, 29 Jun 2018, Rodrigo Vivi  wrote:
> On Fri, Jun 29, 2018 at 01:20:39PM +0300, Jani Nikula wrote:
>> Try to describe what the pick variants do, and which to prefer. No
>> functional changes.
>> 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Rodrigo Vivi 

Thanks, pushed.

BR,
Jani.

>
>> 
>> ---
>> 
>> Let the naming bikeshed fest begin!
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h | 28 ++--
>>  1 file changed, 22 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index c30cfcd90754..7dc774682922 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -139,19 +139,35 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>>  return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
>>  }
>>  
>> +/*
>> + * Given the first two numbers __a and __b of arbitrarily many evenly spaced
>> + * numbers, pick the 0-based __index'th value.
>> + *
>> + * Always prefer this over _PICK() if the numbers are evenly spaced.
>> + */
>> +#define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))
>> +
>> +/*
>> + * Given the arbitrary numbers in varargs, pick the 0-based __index'th 
>> number.
>> + *
>> + * Always prefer _PICK_EVEN() over this if the numbers are evenly spaced.
>> + */
>>  #define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>>  
>> -#define _PIPE(pipe, a, b) ((a) + (pipe) * ((b) - (a)))
>> +/*
>> + * Named helper wrappers around _PICK_EVEN() and _PICK().
>> + */
>> +#define _PIPE(pipe, a, b) _PICK_EVEN(pipe, a, b)
>>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
>> -#define _PLANE(plane, a, b) _PIPE(plane, a, b)
>> +#define _PLANE(plane, a, b) _PICK_EVEN(plane, a, b)
>>  #define _MMIO_PLANE(plane, a, b) _MMIO_PIPE(plane, a, b)
>> -#define _TRANS(tran, a, b) ((a) + (tran) * ((b) - (a)))
>> +#define _TRANS(tran, a, b) _PICK_EVEN(tran, a, b)
>>  #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
>> -#define _PORT(port, a, b) ((a) + (port) * ((b) - (a)))
>> +#define _PORT(port, a, b) _PICK_EVEN(port, a, b)
>>  #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
>>  #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
>>  #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
>> -#define _PLL(pll, a, b) ((a) + (pll) * ((b) - (a)))
>> +#define _PLL(pll, a, b) _PICK_EVEN(pll, a, b)
>>  #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
>>  #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
>>  #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>> @@ -6874,7 +6890,7 @@ enum {
>>  #define _PS_ECC_STAT_2B 0x68AD0
>>  #define _PS_ECC_STAT_1C 0x691D0
>>  
>> -#define _ID(id, a, b) ((a) + (id) * ((b) - (a)))
>> +#define _ID(id, a, b) _PICK_EVEN(id, a, b)
>>  #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
>>  _ID(id, _PS_1A_CTRL, _PS_2A_CTRL),   \
>>  _ID(id, _PS_1B_CTRL, _PS_2B_CTRL))
>> -- 
>> 2.11.0
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Graphics Center
___
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: Add generic fbdev emulation

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm: Add generic fbdev emulation
URL   : https://patchwork.freedesktop.org/series/45777/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9497 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Possible fixes 

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

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


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


== Participating hosts (43 -> 40) ==

  Additional (1): fi-byt-j1900 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4412 -> Patchwork_9497

  CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9497: 8c681fb6ac510d791eeaee34a1fdc3508c79067c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8c681fb6ac51 drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
1decaf928232 drm/tinydrm: Use drm_fbdev_generic_setup()
5d0b6c2e1752 drm/fb-helper: Finish the generic fbdev emulation
10fdb59e4e4a drm/debugfs: Add internal client debugfs file
03ee165264d0 drm/client: Add client callbacks
3f78d617c951 drm/cma-helper: Use the generic fbdev emulation
8aa54780abbc drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
5c343c927656 drm/fb-helper: Add generic fbdev emulation .fb_probe function
44cb6f91d1db drm: Begin an API for in-kernel clients

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Add generic fbdev emulation

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm: Add generic fbdev emulation
URL   : https://patchwork.freedesktop.org/series/45777/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm: Begin an API for in-kernel clients
Okay!

Commit: drm/fb-helper: Add generic fbdev emulation .fb_probe function
+drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void)

Commit: drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
Okay!

Commit: drm/cma-helper: Use the generic fbdev emulation
Okay!

Commit: drm/client: Add client callbacks
Okay!

Commit: drm/debugfs: Add internal client debugfs file
Okay!

Commit: drm/fb-helper: Finish the generic fbdev emulation
Okay!

Commit: drm/tinydrm: Use drm_fbdev_generic_setup()
Okay!

Commit: drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
Okay!

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


[Intel-gfx] [PATCH v3] drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.

2018-07-02 Thread StanLis
From: Stanislav Lisovskiy 

PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.

v2: Edited commit message, removed redundant whitespaces.

v3: Fixed fallthrough logic for the format switch cases.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_display.c | 10 ++
 drivers/gpu/drm/i915/intel_sprite.c  |  5 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 56818a45181c..2447a620abb5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_AYUV,
 };
 
 static const uint32_t skl_pri_planar_formats[] = {
@@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = {
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
DRM_FORMAT_NV12,
+   DRM_FORMAT_AYUV,
 };
 
 static const uint64_t skl_format_modifiers_noccs[] = {
@@ -3497,6 +3499,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_XRGB_2101010;
case DRM_FORMAT_XBGR2101010:
return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010;
+   case DRM_FORMAT_AYUV:
+   return PLANE_CTL_FORMAT_AYUV;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -13371,6 +13375,11 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
}
 
switch (format) {
+   case DRM_FORMAT_AYUV:
+   if (modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED)
+   return true;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
@@ -14510,6 +14519,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_AYUV:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YVYU:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 344c0e709b19..0a6958f07dae 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1405,6 +1405,11 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
}
 
switch (format) {
+   case DRM_FORMAT_AYUV:
+   if (modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED)
+   return true;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
-- 
2.17.0

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add generic fbdev emulation

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm: Add generic fbdev emulation
URL   : https://patchwork.freedesktop.org/series/45777/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
44cb6f91d1db drm: Begin an API for in-kernel clients
-:26: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#26: 
new file mode 100644

-:31: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#31: FILE: Documentation/gpu/drm-client.rst:1:
+=

total: 0 errors, 2 warnings, 0 checks, 412 lines checked
5c343c927656 drm/fb-helper: Add generic fbdev emulation .fb_probe function
8aa54780abbc drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
3f78d617c951 drm/cma-helper: Use the generic fbdev emulation
-:359: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#359: FILE: drivers/gpu/drm/drm_fb_cma_helper.c:172:
+struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
+   unsigned int preferred_bpp, unsigned int max_conn_count)

total: 0 errors, 0 warnings, 1 checks, 425 lines checked
03ee165264d0 drm/client: Add client callbacks
10fdb59e4e4a drm/debugfs: Add internal client debugfs file
5d0b6c2e1752 drm/fb-helper: Finish the generic fbdev emulation
1decaf928232 drm/tinydrm: Use drm_fbdev_generic_setup()
8c681fb6ac51 drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()

___
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: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev2)
URL   : https://patchwork.freedesktop.org/series/45774/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9496 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_ctx_create@basic-files:
  fi-glk-dsi: PASS -> DMESG-WARN (fdo#106954)


 Possible fixes 

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

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


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


== Participating hosts (43 -> 39) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4412 -> Patchwork_9496

  CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9496: 8821d5e9ab048a4e4947e7b51f6d79b5d368de68 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8821d5e9ab04 drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()

2018-07-02 Thread Ville Syrjälä
On Mon, Jul 02, 2018 at 04:04:45PM +0300, Ville Syrjälä wrote:
> On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote:
> > Hi Ville,
> > 
> > Thank you for the patch! Perhaps something to improve:
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202
> > base:   git://people.freedesktop.org/~airlied/linux.git drm-next
> > 
> > smatch warnings:
> > drivers/gpu/drm/nouveau/nouveau_connector.c:461 
> > nouveau_connector_ddc_detect() error: uninitialized symbol 'nv_encoder'.
> > 
> > # 
> > https://github.com/0day-ci/linux/commit/7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> > git remote add linux-review https://github.com/0day-ci/linux
> > git remote update linux-review
> > git checkout 7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> > vim +/nv_encoder +461 drivers/gpu/drm/nouveau/nouveau_connector.c
> > 
> > 6ee738610 Ben Skeggs  2009-12-11  407  
> > 8777c5c11 Ben Skeggs  2014-06-06  408  static struct nouveau_encoder *
> > 8777c5c11 Ben Skeggs  2014-06-06  409  
> > nouveau_connector_ddc_detect(struct drm_connector *connector)
> > 6ee738610 Ben Skeggs  2009-12-11  410  {
> > 6ee738610 Ben Skeggs  2009-12-11  411   struct drm_device *dev = 
> > connector->dev;
> > 1a1841d30 Ben Skeggs  2012-12-10  412   struct nouveau_connector 
> > *nv_connector = nouveau_connector(connector);
> > 77145f1cb Ben Skeggs  2012-07-31  413   struct nouveau_drm *drm = 
> > nouveau_drm(dev);
> > 1167c6bc5 Ben Skeggs  2016-05-18  414   struct nvkm_gpio *gpio = 
> > nvxx_gpio(&drm->client.device);
> > 8777c5c11 Ben Skeggs  2014-06-06  415   struct nouveau_encoder 
> > *nv_encoder;
> > 6d385c0aa Rob Clark   2014-07-17  416   struct drm_encoder *encoder;
> > 1a1841d30 Ben Skeggs  2012-12-10  417   int i, panel = -ENODEV;
> > 1a1841d30 Ben Skeggs  2012-12-10  418  
> > 1a1841d30 Ben Skeggs  2012-12-10  419   /* eDP panels need powering on 
> > by us (if the VBIOS doesn't default it
> > 1a1841d30 Ben Skeggs  2012-12-10  420* to on) before doing any AUX 
> > channel transactions.  LVDS panel power
> > 1a1841d30 Ben Skeggs  2012-12-10  421* is handled by the SOR 
> > itself, and not required for LVDS DDC.
> > 1a1841d30 Ben Skeggs  2012-12-10  422*/
> > 1a1841d30 Ben Skeggs  2012-12-10  423   if (nv_connector->type == 
> > DCB_CONNECTOR_eDP) {
> > 2ea7249fe Ben Skeggs  2015-08-20  424   panel = 
> > nvkm_gpio_get(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff);
> > 1a1841d30 Ben Skeggs  2012-12-10  425   if (panel == 0) {
> > 2ea7249fe Ben Skeggs  2015-08-20  426   
> > nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1);
> > 1a1841d30 Ben Skeggs  2012-12-10  427   msleep(300);
> > 1a1841d30 Ben Skeggs  2012-12-10  428   }
> > 1a1841d30 Ben Skeggs  2012-12-10  429   }
> > 6ee738610 Ben Skeggs  2009-12-11  430  
> > 7ec8bb653 Ville Syrjälä   2018-06-28  431   
> > drm_connector_for_each_possible_encoder(connector, encoder, i) {
> > 6d385c0aa Rob Clark   2014-07-17  432   nv_encoder = 
> > nouveau_encoder(encoder);
> > 
> > ^
> > If we enter the loop that means nv_encoder is non-NULL.  Smatch can't
> > prove that we always enter the loop in this case for whatever reason but
> > my guess is that we always do.
> > 
> > 4ca2b7120 Francisco Jerez 2010-08-08  433  
> > 8777c5c11 Ben Skeggs  2014-06-06  434   if 
> > (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> > 8777c5c11 Ben Skeggs  2014-06-06  435   int ret = 
> > nouveau_dp_detect(nv_encoder);
> > 52aa30f25 Ben Skeggs  2016-11-04  436   if (ret == 
> > NOUVEAU_DP_MST)
> > 52aa30f25 Ben Skeggs  2016-11-04  437   return 
> > NULL;
> > 52aa30f25 Ben Skeggs  2016-11-04  438   if (ret == 
> > NOUVEAU_DP_SST)
> > 8777c5c11 Ben Skeggs  2014-06-06  439   break;
> > 8777c5c11 Ben Skeggs  2014-06-06  440   } else
> > 39c1c9011 Lukas Wunner2016-01-11  441   if 
> > ((vga_switcheroo_handler_flags() &
> > 39c1c9011 Lukas Wunner2016-01-11  442
> > VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
> > 39c1c9011 Lukas Wunner2016-01-11  443   
> > nv_encoder->dcb->type == DCB_OUTPUT_LVDS &&
> > 39c1c9011 Lukas Wunner2016-01-11  444   nv_encoder->i2c) {
> > 39c1c9011 Lukas Wunner2016-01-11  445   int ret;
> > 39c1c9011 Lukas Wunner2016-01-11  446   
> > vga_switcheroo_lock_ddc(dev->pdev);
> > 39c1c9011 Lukas Wunner2016-01-11  447   ret = 
> > nvkm_probe_i2c(nv_encoder->i2c, 0x50);
> > 39c1c9011 Lukas Wunner2016-01-11  448   
> > vga_switcheroo_unlock_ddc(dev->pdev);
> > 39c1c9011 Lukas Wunner   

[Intel-gfx] [PATCH] usb/icl: Work around ACPI boottime crash

2018-07-02 Thread Imre Deak
Work around the following boot time crash:

[   10.456056] CPU: 1 PID: 220 Comm: systemd-udevd Tainted: GW 
4.17.0-rc7-CI-CI_DRM_4040+ #182
[   10.465828] Hardware name: Intel Corporation Ice Lake Client 
Platform/IceLake U DDR4 SODIMM PD RVP, BIOS
+ICLSFWR1.R00.2204.A00.1805172221 05/17/2018
[   10.479168] RIP: 0010:acpi_ps_complete_this_op+0xa7/0x22a
[   10.484627] RSP: 0018:c93a7578 EFLAGS: 00010202
[   10.489881] RAX: 6b6b6b6b6b6b6b6b RBX: 8804abeda9c8 RCX: 0020
[   10.497045] RDX:  RSI: 88049e604a68 RDI: 
[   10.504213] RBP:  R08: 8804abeda9c8 R09: 
[   10.511376] R10:  R11:  R12: 000e
[   10.518542] R13: 88049e604a68 R14: 88049e604a68 R15: a00263c2
[   10.525713] FS:  7ff6d85f18c0() GS:8804be88() 
knlGS:
[   10.533839] CS:  0010 DS:  ES:  CR0: 80050033
[   10.539616] CR2: 7ff6d73cff40 CR3: 00049f794001 CR4: 00760ee0
[   10.546783] DR0:  DR1:  DR2: 
[   10.553949] DR3:  DR6: fffe0ff0 DR7: 0400
[   10.561112] PKRU: 5554
[   10.563849] Call Trace:
[   10.566323]  acpi_ps_complete_op+0x49/0x3f1
[   10.570537]  acpi_ps_parse_loop+0x94c/0x9bb
[   10.574754]  ? acpi_ds_delete_walk_state+0x113/0x131
[   10.579750]  acpi_ps_parse_aml+0x1a2/0x4af
[   10.583875]  acpi_ps_execute_method+0x1e9/0x2a5
[   10.588435]  acpi_ns_evaluate+0x2e4/0x42c
[   10.592473]  acpi_evaluate_object+0x1fd/0x3a8
[   10.596873]  usb_acpi_find_companion+0xee/0x1f0 [usbcore]
[   10.602319]  acpi_platform_notify+0x33/0xa0
[   10.606532]  device_add+0x197/0x600
[   10.610048]  ? __init_waitqueue_head+0x36/0x50
[   10.614529]  usb_hub_create_port_device+0x11d/0x340 [usbcore]
[   10.620314]  hub_probe+0x9a5/0x1010 [usbcore]
[   10.624701]  ? _raw_spin_unlock_irqrestore+0x51/0x60
[   10.629730]  usb_probe_interface+0x13f/0x300 [usbcore]
[   10.634900]  driver_probe_device+0x302/0x470
[   10.639198]  ? __driver_attach+0xe0/0xe0
[   10.643147]  bus_for_each_drv+0x59/0x90
[   10.647013]  __device_attach+0xb7/0x130
[   10.650878]  bus_probe_device+0x9c/0xb0
[   10.654745]  device_add+0x3c5/0x600
[   10.658270]  usb_set_configuration+0x540/0x880 [usbcore]
[   10.663621]  generic_probe+0x28/0x80 [usbcore]
[   10.668097]  driver_probe_device+0x302/0x470
[   10.672393]  ? __driver_attach+0xe0/0xe0
[   10.676346]  bus_for_each_drv+0x59/0x90
[   10.680211]  __device_attach+0xb7/0x130
[   10.684076]  bus_probe_device+0x9c/0xb0
[   10.687940]  device_add+0x3c5/0x600
[   10.691464]  usb_new_device+0x269/0x490 [usbcore]
[   10.696206]  usb_add_hcd+0x558/0x850 [usbcore]
[   10.700682]  xhci_pci_probe+0x13d/0x240 [xhci_pci]
[   10.705534]  pci_device_probe+0xa1/0x130
[   10.709484]  driver_probe_device+0x302/0x470
[   10.713784]  __driver_attach+0xb9/0xe0
[   10.717562]  ? driver_probe_device+0x470/0x470
[   10.722033]  ? driver_probe_device+0x470/0x470
[   10.726505]  bus_for_each_dev+0x64/0x90
[   10.730370]  ? preempt_count_sub+0x92/0xd0
[   10.734495]  bus_add_driver+0x164/0x260
[   10.738362]  ? 0xa004e000
[   10.741704]  driver_register+0x57/0xc0
[   10.745482]  ? 0xa004e000
[   10.748824]  do_one_initcall+0x4a/0x350
[   10.752690]  ? do_init_module+0x22/0x20a
[   10.756643]  ? rcu_read_lock_sched_held+0x74/0x80
[   10.761377]  ? kmem_cache_alloc_trace+0x284/0x2e0
[   10.766114]  do_init_module+0x5b/0x20a
[   10.769895]  load_module+0x250d/0x2b20
[   10.773678]  ? kernel_read+0x2c/0x40
[   10.777285]  ? __se_sys_finit_module+0xaa/0xc0
[   10.781759]  __se_sys_finit_module+0xaa/0xc0
[   10.786061]  do_syscall_64+0x54/0x190
[   10.789752]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   10.794831] RIP: 0033:0x7ff6d74664d9
[   10.798430] RSP: 002b:7ffd91e7dd78 EFLAGS: 0246 ORIG_RAX: 
0139
[   10.806033] RAX: ffda RBX: 560519bfae20 RCX: 7ff6d74664d9
[   10.813195] RDX:  RSI: 7ff6d795ce23 RDI: 000e
[   10.820360] RBP: 7ff6d795ce23 R08:  R09: 
[   10.827523] R10: 000e R11: 0246 R12: 
[   10.834690] R13: 560519bf9a30 R14: 0002 R15: 0aba9500
[   10.841862] Code: c2 10 5f ea 81 48 c7 c6 f0 5e ea 81 bf 7c 00 00 00 e8 0d 
7c 00 00 31 ed e9 88 01 00 00 48 8b 03 31 ed 48 85 c0
+0f 84 e9 00 00 00 <4c> 8b 60 28 4d 85 e4 0f 84 dc 00 00 00 0f b7 78 0a e8 62 
fe ff
[   10.860832] RIP: acpi_ps_complete_this_op+0xa7/0x22a RSP: c93a7578
[   10.867907] ---[ end trace 3a0d2ee1129bc71e ]---

Cc: Chris Wilson 
Signed-off-by: Imre Deak 
---
 drivers/usb/core/usb-acpi.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index e221861b3187..8424b3a27e7e 100644
--- a/drivers/usb/core/u

Re: [Intel-gfx] [PATCH v2] drm/i915: Try GGTT mmapping whole object as partial

2018-07-02 Thread Matthew Auld
On 30 June 2018 at 10:05, Chris Wilson  wrote:
> If the whole object is already pinned by HW for use as scanout, we will
> fail to move it to the mappable region and so must resort to using a
> partial VMA covering the whole object.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104513
> Fixes: aa136d9d72c2 ("drm/i915: Convert partial ggtt vma to full ggtt if it 
> spans the entire object")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Matthew Auld 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v4 8/9] drm/tinydrm: Use drm_fbdev_generic_setup()

2018-07-02 Thread Noralf Trønnes
Make full use of the generic fbdev client.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +--
 drivers/gpu/drm/tinydrm/ili9225.c   | 1 -
 drivers/gpu/drm/tinydrm/ili9341.c   | 1 -
 drivers/gpu/drm/tinydrm/mi0283qt.c  | 1 -
 drivers/gpu/drm/tinydrm/st7586.c| 1 -
 drivers/gpu/drm/tinydrm/st7735r.c   | 1 -
 6 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 24a33bf862fa..19c7f70adfa5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -204,7 +204,7 @@ static int tinydrm_register(struct tinydrm_device *tdev)
if (ret)
return ret;
 
-   ret = drm_fb_cma_fbdev_init_with_funcs(drm, 0, 0, tdev->fb_funcs);
+   ret = drm_fbdev_generic_setup(drm, 0);
if (ret)
DRM_ERROR("Failed to initialize fbdev: %d\n", ret);
 
@@ -214,7 +214,6 @@ static int tinydrm_register(struct tinydrm_device *tdev)
 static void tinydrm_unregister(struct tinydrm_device *tdev)
 {
drm_atomic_helper_shutdown(tdev->drm);
-   drm_fb_cma_fbdev_fini(tdev->drm);
drm_dev_unregister(tdev->drm);
 }
 
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 841c69aba059..455fefe012f5 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -368,7 +368,6 @@ static struct drm_driver ili9225_driver = {
  DRIVER_ATOMIC,
.fops   = &ili9225_fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.name   = "ili9225",
.desc   = "Ilitek ILI9225",
.date   = "20171106",
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c 
b/drivers/gpu/drm/tinydrm/ili9341.c
index 8864dcde6edc..6701037749a7 100644
--- a/drivers/gpu/drm/tinydrm/ili9341.c
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -145,7 +145,6 @@ static struct drm_driver ili9341_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | 
DRIVER_ATOMIC,
.fops   = &ili9341_fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "ili9341",
.desc   = "Ilitek ILI9341",
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 015d03f2acba..d7bb4c5e6657 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -154,7 +154,6 @@ static struct drm_driver mi0283qt_driver = {
  DRIVER_ATOMIC,
.fops   = &mi0283qt_fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "mi0283qt",
.desc   = "Multi-Inno MI0283QT",
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 5c29e3803ecb..2fcbc3067d71 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -304,7 +304,6 @@ static struct drm_driver st7586_driver = {
  DRIVER_ATOMIC,
.fops   = &st7586_fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "st7586",
.desc   = "Sitronix ST7586",
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c 
b/drivers/gpu/drm/tinydrm/st7735r.c
index 6c7b15c9da4f..3081bc57c116 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -120,7 +120,6 @@ static struct drm_driver st7735r_driver = {
  DRIVER_ATOMIC,
.fops   = &st7735r_fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "st7735r",
.desc   = "Sitronix ST7735R",
-- 
2.15.1

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


[Intel-gfx] [PATCH v4 7/9] drm/fb-helper: Finish the generic fbdev emulation

2018-07-02 Thread Noralf Trønnes
This adds a drm_fbdev_generic_setup() function that sets up generic
fbdev emulation with client callbacks for restore, hotplug and
unregister.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 117 
 include/drm/drm_fb_helper.h |   7 +++
 2 files changed, 124 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bea3a0cb324a..e2f0db1432aa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -67,6 +67,9 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  * helper functions used by many drivers to implement the kernel mode setting
  * interfaces.
  *
+ * Drivers that support a dumb buffer with a virtual address and mmap support,
+ * should try out the generic fbdev emulation using drm_fbdev_generic_setup().
+ *
  * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
  * down by calling drm_fb_helper_fbdev_teardown().
  *
@@ -3118,6 +3121,120 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper 
*fb_helper,
 }
 EXPORT_SYMBOL(drm_fb_helper_generic_probe);
 
+static const struct drm_fb_helper_funcs drm_fb_helper_generic_funcs = {
+   .fb_probe = drm_fb_helper_generic_probe,
+};
+
+static void drm_fbdev_client_unregister(struct drm_client_dev *client)
+{
+   struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+   if (fb_helper->fbdev) {
+   drm_fb_helper_unregister_fbi(fb_helper);
+   /* drm_fbdev_fb_destroy() takes care of cleanup */
+   return;
+   }
+
+   /* Did drm_fb_helper_fbdev_setup() run? */
+   if (fb_helper->dev)
+   drm_fb_helper_fini(fb_helper);
+
+   drm_client_release(client);
+   kfree(fb_helper);
+}
+
+static int drm_fbdev_client_restore(struct drm_client_dev *client)
+{
+   struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+   drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+
+   return 0;
+}
+
+static int drm_fbdev_client_hotplug(struct drm_client_dev *client)
+{
+   struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+   struct drm_device *dev = client->dev;
+   int ret;
+
+   /* If drm_fb_helper_fbdev_setup() failed, we only try once */
+   if (!fb_helper->dev && fb_helper->funcs)
+   return 0;
+
+   if (dev->fb_helper)
+   return drm_fb_helper_hotplug_event(dev->fb_helper);
+
+   if (!dev->mode_config.num_connector)
+   return 0;
+
+   ret = drm_fb_helper_fbdev_setup(dev, fb_helper, 
&drm_fb_helper_generic_funcs,
+   fb_helper->preferred_bpp, 0);
+   if (ret) {
+   fb_helper->dev = NULL;
+   fb_helper->fbdev = NULL;
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct drm_client_funcs drm_fbdev_client_funcs = {
+   .owner  = THIS_MODULE,
+   .unregister = drm_fbdev_client_unregister,
+   .restore= drm_fbdev_client_restore,
+   .hotplug= drm_fbdev_client_hotplug,
+};
+
+/**
+ * drm_fb_helper_generic_fbdev_setup() - Setup generic fbdev emulation
+ * @dev: DRM device
+ * @preferred_bpp: Preferred bits per pixel for the device.
+ * @dev->mode_config.preferred_depth is used if this is zero.
+ *
+ * This function sets up generic fbdev emulation for drivers that supports
+ * dumb buffers with a virtual address and that can be mmap'ed.
+ *
+ * Restore, hotplug events and teardown are all taken care of. Drivers that do
+ * suspend/resume need to call drm_fb_helper_set_suspend_unlocked() themselves.
+ * Simple drivers might use drm_mode_config_helper_suspend().
+ *
+ * Drivers that set the dirty callback on their framebuffer will get a shadow
+ * fbdev buffer that is blitted onto the real buffer. This is done in order to
+ * make deferred I/O work with all kinds of buffers.
+ *
+ * This function is safe to call even when there are no connectors present.
+ * Setup will be retried on the next hotplug event.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
+{
+   struct drm_fb_helper *fb_helper;
+   int ret;
+
+   if (!drm_fbdev_emulation)
+   return 0;
+
+   fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
+   if (!fb_helper)
+   return -ENOMEM;
+
+   ret = drm_client_new(dev, &fb_helper->client, "fbdev", 
&drm_fbdev_client_funcs);
+   if (ret) {
+   kfree(fb_helper);
+   return ret;
+   }
+
+   fb_helper->preferred_bpp = preferred_bpp;
+
+   drm_fbdev_client_hotplug(&fb_helper->client);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fbdev_generic_setup);
+
 /* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT)
  * but the module doesn't depend on any fb console

[Intel-gfx] [PATCH v4 4/9] drm/cma-helper: Use the generic fbdev emulation

2018-07-02 Thread Noralf Trønnes
This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.

There are currently 2 fbdev init/fini functions:
- drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
- drm_fbdev_cma_init/drm_fbdev_cma_fini

This is because the work on generic fbdev came up during a fbdev
refactoring and thus wasn't completed. No point in completing that
refactoring when drivers will soon move to drm_fb_helper_generic_probe().

tinydrm uses drm_fb_cma_fbdev_init_with_funcs().

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 360 +---
 include/drm/drm_fb_cma_helper.h |   3 -
 2 files changed, 42 insertions(+), 321 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..5762a7c441e9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,11 +27,8 @@
 #include 
 #include 
 
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
 struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
-   const struct drm_framebuffer_funcs *fb_funcs;
 };
 
 /**
@@ -44,36 +42,6 @@ struct drm_fbdev_cma {
  *
  * An fbdev framebuffer backed by cma is also available by calling
  * drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
- * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will be
- * set up automatically. &drm_framebuffer_funcs.dirty is called by
- * drm_fb_helper_deferred_io() in process context (&struct delayed_work).
- *
- * Example fbdev deferred io code::
- *
- * static int driver_fb_dirty(struct drm_framebuffer *fb,
- *struct drm_file *file_priv,
- *unsigned flags, unsigned color,
- *struct drm_clip_rect *clips,
- *unsigned num_clips)
- * {
- * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
- * ... push changes ...
- * return 0;
- * }
- *
- * static struct drm_framebuffer_funcs driver_fb_funcs = {
- * .destroy   = drm_gem_fb_destroy,
- * .create_handle = drm_gem_fb_create_handle,
- * .dirty = driver_fb_dirty,
- * };
- *
- * Initialize::
- *
- * fbdev = drm_fb_cma_fbdev_init_with_funcs(dev, 16,
- *   dev->mode_config.num_crtc,
- *   dev->mode_config.num_connector,
- *   &driver_fb_funcs);
- *
  */
 
 static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
@@ -131,153 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer 
*fb,
 }
 EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
 
-static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
-   return dma_mmap_writecombine(info->device, vma, info->screen_base,
-info->fix.smem_start, info->fix.smem_len);
-}
-
-static struct fb_ops drm_fbdev_cma_ops = {
-   .owner  = THIS_MODULE,
-   DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_fillrect= drm_fb_helper_sys_fillrect,
-   .fb_copyarea= drm_fb_helper_sys_copyarea,
-   .fb_imageblit   = drm_fb_helper_sys_imageblit,
-   .fb_mmap= drm_fb_cma_mmap,
-};
-
-static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
- struct vm_area_struct *vma)
-{
-   fb_deferred_io_mmap(info, vma);
-   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
-
-   return 0;
-}
-
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
-   struct drm_gem_cma_object *cma_obj)
-{
-   struct fb_deferred_io *fbdefio;
-   struct fb_ops *fbops;
-
-   /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
-   fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
-   fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
-   if (!fbdefio || !fbops) {
-   kfree(fbdefio);
-   kfree(fbops);
-   return -ENOMEM;
-   }
-
-   /* can't be offset from vaddr since dirty() uses cma_obj */
-   fbi->screen_buffer = cma_obj->vaddr;
-   /* fb_deferred_io_fault() needs a physical address */
-   fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
-   *fbops = *fbi->fbops;
-   fbi->fbops = fbops;
-
-   fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
-   fbdefio->deferred_io = drm_fb_helper_deferred_io;
-   fbi->fbdef

[Intel-gfx] [PATCH v4 6/9] drm/debugfs: Add internal client debugfs file

2018-07-02 Thread Noralf Trønnes
Print the names of the internal clients currently attached.

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_client.c  | 28 
 drivers/gpu/drm/drm_debugfs.c |  7 +++
 include/drm/drm_client.h  |  3 +++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index f05ee98bd10c..e8d7b259ff22 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -375,3 +375,31 @@ void drm_client_framebuffer_delete(struct 
drm_client_buffer *buffer)
drm_client_buffer_delete(buffer);
 }
 EXPORT_SYMBOL(drm_client_framebuffer_delete);
+
+#ifdef CONFIG_DEBUG_FS
+static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+   struct drm_client_dev *client;
+
+   mutex_lock(&dev->clientlist_mutex);
+   list_for_each_entry(client, &dev->clientlist, list)
+   drm_printf(&p, "%s\n", client->name);
+   mutex_unlock(&dev->clientlist_mutex);
+
+   return 0;
+}
+
+static const struct drm_info_list drm_client_debugfs_list[] = {
+   { "internal_clients", drm_client_debugfs_internal_clients, 0 },
+};
+
+int drm_client_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(drm_client_debugfs_list,
+   ARRAY_SIZE(drm_client_debugfs_list),
+   minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b2482818fee8..50a20bfc07ea 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -164,6 +165,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
DRM_ERROR("Failed to create framebuffer debugfs 
file\n");
return ret;
}
+
+   ret = drm_client_debugfs_init(minor);
+   if (ret) {
+   DRM_ERROR("Failed to create client debugfs file\n");
+   return ret;
+   }
}
 
if (dev->driver->debugfs_init) {
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 02cbb02714d8..e03ac786b0e1 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -10,6 +10,7 @@ struct drm_device;
 struct drm_file;
 struct drm_framebuffer;
 struct drm_gem_object;
+struct drm_minor;
 struct module;
 
 /**
@@ -146,4 +147,6 @@ struct drm_client_buffer *
 drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32 
height, u32 format);
 void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
 
+int drm_client_debugfs_init(struct drm_minor *minor);
+
 #endif
-- 
2.15.1

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


[Intel-gfx] [PATCH v4 9/9] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()

2018-07-02 Thread Noralf Trønnes
Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 21 -
 include/drm/drm_fb_cma_helper.h |  3 ---
 2 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 718c7f961d8a..9da36a6271d3 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -99,27 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer 
*fb,
 }
 EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
 
-/**
- * drm_fb_cma_fbdev_init_with_funcs() - Allocate and initialize fbdev emulation
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device.
- * @dev->mode_config.preferred_depth is used if this is zero.
- * @max_conn_count: Maximum number of connectors.
- *  @dev->mode_config.num_connector is used if this is zero.
- * @funcs: Framebuffer functions, in particular a custom dirty() callback.
- * Can be NULL.
- *
- * Returns:
- * Zero on success or negative error code on failure.
- */
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
-   unsigned int preferred_bpp, unsigned int max_conn_count,
-   const struct drm_framebuffer_funcs *funcs)
-{
-   return drm_fb_cma_fbdev_init(dev, preferred_bpp, max_conn_count);
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init_with_funcs);
-
 /**
  * drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
  * @dev: DRM device
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index a0546c3451f9..96e26e3b9a0c 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -16,9 +16,6 @@ struct drm_mode_fb_cmd2;
 struct drm_plane;
 struct drm_plane_state;
 
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
-   unsigned int preferred_bpp, unsigned int max_conn_count,
-   const struct drm_framebuffer_funcs *funcs);
 int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp,
  unsigned int max_conn_count);
 void drm_fb_cma_fbdev_fini(struct drm_device *dev);
-- 
2.15.1

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


[Intel-gfx] [PATCH v4 5/9] drm/client: Add client callbacks

2018-07-02 Thread Noralf Trønnes
Add client callbacks and hook them up.
Add a list of clients per drm_device.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_client.c| 92 -
 drivers/gpu/drm/drm_drv.c   |  7 +++
 drivers/gpu/drm/drm_fb_cma_helper.c |  2 +-
 drivers/gpu/drm/drm_fb_helper.c | 11 -
 drivers/gpu/drm/drm_file.c  |  3 ++
 drivers/gpu/drm/drm_probe_helper.c  |  3 ++
 include/drm/drm_client.h| 75 +-
 include/drm/drm_device.h| 14 ++
 8 files changed, 201 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 9c9b8ac7aea3..f05ee98bd10c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,7 @@ EXPORT_SYMBOL(drm_client_close);
  * @dev: DRM device
  * @client: DRM client
  * @name: Client name
+ * @funcs: DRM client functions (optional)
  *
  * Use drm_client_put() to free the client.
  *
@@ -73,24 +75,47 @@ EXPORT_SYMBOL(drm_client_close);
  * Zero on success or negative error code on failure.
  */
 int drm_client_new(struct drm_device *dev, struct drm_client_dev *client,
-  const char *name)
+  const char *name, const struct drm_client_funcs *funcs)
 {
+   bool registered;
int ret;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
!dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
return -ENOTSUPP;
 
+   if (funcs && !try_module_get(funcs->owner))
+   return -ENODEV;
+
client->dev = dev;
client->name = name;
+   client->funcs = funcs;
 
ret = drm_client_open(client);
if (ret)
-   return ret;
+   goto err_put_module;
+
+   mutex_lock(&dev->clientlist_mutex);
+   registered = dev->registered;
+   if (registered)
+   list_add(&client->list, &dev->clientlist);
+   mutex_unlock(&dev->clientlist_mutex);
+   if (!registered) {
+   ret = -ENODEV;
+   goto err_close;
+   }
 
drm_dev_get(dev);
 
return 0;
+
+err_close:
+   drm_client_close(client);
+err_put_module:
+   if (funcs)
+   module_put(funcs->owner);
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_client_new);
 
@@ -116,9 +141,72 @@ void drm_client_release(struct drm_client_dev *client)
 
drm_client_close(client);
drm_dev_put(dev);
+   if (client->funcs)
+   module_put(client->funcs->owner);
 }
 EXPORT_SYMBOL(drm_client_release);
 
+void drm_client_dev_unregister(struct drm_device *dev)
+{
+   struct drm_client_dev *client, *tmp;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return;
+
+   mutex_lock(&dev->clientlist_mutex);
+   list_for_each_entry_safe(client, tmp, &dev->clientlist, list) {
+   list_del(&client->list);
+   if (client->funcs && client->funcs->unregister) {
+   client->funcs->unregister(client);
+   } else {
+   drm_client_release(client);
+   kfree(client);
+   }
+   }
+   mutex_unlock(&dev->clientlist_mutex);
+}
+
+void drm_client_dev_hotplug(struct drm_device *dev)
+{
+   struct drm_client_dev *client;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return;
+
+   mutex_lock(&dev->clientlist_mutex);
+   list_for_each_entry(client, &dev->clientlist, list) {
+   if (!client->funcs || !client->funcs->hotplug)
+   continue;
+
+   ret = client->funcs->hotplug(client);
+   DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
+   }
+   mutex_unlock(&dev->clientlist_mutex);
+}
+EXPORT_SYMBOL(drm_client_dev_hotplug);
+
+void drm_client_dev_restore(struct drm_device *dev)
+{
+   struct drm_client_dev *client;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return;
+
+   mutex_lock(&dev->clientlist_mutex);
+   list_for_each_entry(client, &dev->clientlist, list) {
+   if (!client->funcs || !client->funcs->restore)
+   continue;
+
+   ret = client->funcs->restore(client);
+   DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
+   if (!ret) /* The first one to return zero gets the privilege to 
restore */
+   break;
+   }
+   mutex_unlock(&dev->clientlist_mutex);
+}
+
 static void drm_client_buffer_delete(struct drm_client_buffer *buffer)
 {
struct drm_device *dev = buffer->client->dev;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e7ff0b03328b..6eb935bb2f92 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/d

[Intel-gfx] [PATCH v4 0/9] drm: Add generic fbdev emulation

2018-07-02 Thread Noralf Trønnes
This patchset adds generic fbdev emulation for drivers that supports GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.

Change this version:
Fix a bug in an error path that the kbuild test robot caught.

Change previous version:
Rework client removal (again). Drop reference counting, only allow the
driver to remove a client.

Noralf.

Changes since version 3:
- drm/cma-helper: Use the generic fbdev emulation: Fix error path
- Remove setting .lastclose in new tinydrm driver ili9341

Changes since version 2:
- Applied first 3 patches to drm-misc-next
- Drop client reference counting and only allow the driver to release
clients.

Noralf Trønnes (9):
  drm: Begin an API for in-kernel clients
  drm/fb-helper: Add generic fbdev emulation .fb_probe function
  drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
  drm/cma-helper: Use the generic fbdev emulation
  drm/client: Add client callbacks
  drm/debugfs: Add internal client debugfs file
  drm/fb-helper: Finish the generic fbdev emulation
  drm/tinydrm: Use drm_fbdev_generic_setup()
  drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()

 Documentation/gpu/drm-client.rst|  12 +
 Documentation/gpu/index.rst |   1 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_client.c| 405 
 drivers/gpu/drm/drm_debugfs.c   |   7 +
 drivers/gpu/drm/drm_drv.c   |   8 +
 drivers/gpu/drm/drm_fb_cma_helper.c | 379 +++---
 drivers/gpu/drm/drm_fb_helper.c | 316 +-
 drivers/gpu/drm/drm_file.c  |   3 +
 drivers/gpu/drm/drm_probe_helper.c  |   3 +
 drivers/gpu/drm/pl111/pl111_drv.c   |   2 +
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c |   3 +-
 drivers/gpu/drm/tinydrm/ili9225.c   |   1 -
 drivers/gpu/drm/tinydrm/ili9341.c   |   1 -
 drivers/gpu/drm/tinydrm/mi0283qt.c  |   1 -
 drivers/gpu/drm/tinydrm/st7586.c|   1 -
 drivers/gpu/drm/tinydrm/st7735r.c   |   1 -
 include/drm/drm_client.h| 152 +++
 include/drm/drm_device.h|  21 ++
 include/drm/drm_fb_cma_helper.h |   6 -
 include/drm/drm_fb_helper.h |  38 +++
 21 files changed, 1010 insertions(+), 353 deletions(-)
 create mode 100644 Documentation/gpu/drm-client.rst
 create mode 100644 drivers/gpu/drm/drm_client.c
 create mode 100644 include/drm/drm_client.h

-- 
2.15.1

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


[Intel-gfx] [PATCH v4 2/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function

2018-07-02 Thread Noralf Trønnes
This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 192 +++-
 include/drm/drm_fb_helper.h |  31 +++
 2 files changed, 222 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cab14f253384..0a0a577ebc3c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -30,6 +30,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -738,6 +739,24 @@ static void drm_fb_helper_resume_worker(struct work_struct 
*work)
console_unlock();
 }
 
+static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
+ struct drm_clip_rect *clip)
+{
+   struct drm_framebuffer *fb = fb_helper->fb;
+   unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
+   size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
+   void *src = fb_helper->fbdev->screen_buffer + offset;
+   void *dst = fb_helper->buffer->vaddr + offset;
+   size_t len = (clip->x2 - clip->x1) * cpp;
+   unsigned int y;
+
+   for (y = clip->y1; y < clip->y2; y++) {
+   memcpy(dst, src, len);
+   src += fb->pitches[0];
+   dst += fb->pitches[0];
+   }
+}
+
 static void drm_fb_helper_dirty_work(struct work_struct *work)
 {
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
@@ -753,8 +772,12 @@ static void drm_fb_helper_dirty_work(struct work_struct 
*work)
spin_unlock_irqrestore(&helper->dirty_lock, flags);
 
/* call dirty callback only when it has been really touched */
-   if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2)
+   if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
+   /* Generic fbdev uses a shadow buffer */
+   if (helper->buffer)
+   drm_fb_helper_dirty_blit_real(helper, &clip_copy);
helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+   }
 }
 
 /**
@@ -2921,6 +2944,173 @@ void drm_fb_helper_output_poll_changed(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
 
+/* @user: 1=userspace, 0=fbcon */
+static int drm_fbdev_fb_open(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   if (!try_module_get(fb_helper->dev->driver->fops->owner))
+   return -ENODEV;
+
+   return 0;
+}
+
+static int drm_fbdev_fb_release(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   module_put(fb_helper->dev->driver->fops->owner);
+
+   return 0;
+}
+
+/*
+ * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
+ * unregister_framebuffer() or fb_release().
+ */
+static void drm_fbdev_fb_destroy(struct fb_info *info)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct fb_info *fbi = fb_helper->fbdev;
+   struct fb_ops *fbops = NULL;
+   void *shadow = NULL;
+
+   if (fbi->fbdefio) {
+   fb_deferred_io_cleanup(fbi);
+   shadow = fbi->screen_buffer;
+   fbops = fbi->fbops;
+   }
+
+   drm_fb_helper_fini(fb_helper);
+
+   if (shadow) {
+   vfree(shadow);
+   kfree(fbops);
+   }
+
+   drm_client_framebuffer_delete(fb_helper->buffer);
+   drm_client_release(&fb_helper->client);
+   kfree(fb_helper);
+}
+
+static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   if (fb_helper->dev->driver->gem_prime_mmap)
+   return 
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
+   else
+   return -ENODEV;
+}
+
+static struct fb_ops drm_fbdev_fb_ops = {
+   .owner  = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
+   .fb_open= drm_fbdev_fb_open,
+   .fb_release = drm_fbdev_fb_release,
+   .fb_destroy = drm_fbdev_fb_destroy,
+   .fb_mmap= drm_fbdev_fb_mmap,
+   .fb_read= drm_fb_helper_sys_read,
+   .fb_write   = drm_fb_helper_sys_write,
+   .fb_fillrect= drm_fb_helper_sys_fillrect,
+   .fb_copyarea= drm_fb_helper_sys_copyarea,
+   .fb_imageblit   = drm_fb_helper_sys_imageblit,
+};
+
+static struct fb_deferred_io drm_fbdev_defio = {
+   .delay  = HZ / 20,
+   .deferred_io= drm_fb_helper_deferred_io,
+};
+
+/**
+ * drm_fb_helper_generic_probe - Generic fbdev emulation probe helper
+ * @fb_helper: fbdev helper structure
+ * @sizes: describes fbdev size and scanout surface 

[Intel-gfx] [PATCH v4 3/9] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap

2018-07-02 Thread Noralf Trønnes
These are needed for pl111 to use the generic fbdev emulation.

Cc: Eric Anholt 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 054b93689d94..17a38e85ba7d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -250,6 +250,8 @@ static struct drm_driver pl111_drm_driver = {
.gem_prime_import_sg_table = pl111_gem_import_sg_table,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   .gem_prime_vmap = drm_gem_cma_prime_vmap,
 
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = pl111_debugfs_init,
-- 
2.15.1

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


[Intel-gfx] [PATCH v4 1/9] drm: Begin an API for in-kernel clients

2018-07-02 Thread Noralf Trønnes
This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.

Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer is created from a kernel thread. The easy way out is to use
drm_driver.gem_prime_vmap to get the virtual address, which requires a
GEM object. This excludes the vmwgfx driver which is the only non-GEM
driver apart from the legacy ones. A solution for vmwgfx will have to be
worked out later if it wants to support the client API which it probably
will when we have a bootsplash client.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/drm-client.rst |  12 ++
 Documentation/gpu/index.rst  |   1 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_client.c | 289 +++
 drivers/gpu/drm/drm_drv.c|   1 +
 include/drm/drm_client.h |  76 ++
 include/drm/drm_device.h |   7 +
 7 files changed, 387 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/gpu/drm-client.rst
 create mode 100644 drivers/gpu/drm/drm_client.c
 create mode 100644 include/drm/drm_client.h

diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst
new file mode 100644
index ..7e672063e7eb
--- /dev/null
+++ b/Documentation/gpu/drm-client.rst
@@ -0,0 +1,12 @@
+=
+Kernel clients
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_client.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+   :export:
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index 00288f34c5a6..1fcf8e851e15 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
drm-kms
drm-kms-helpers
drm-uapi
+   drm-client
drivers
vga-switcheroo
vgaarbiter
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 69c13517ea3a..d6657a61d037 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o drm_lease.o drm_writeback.o
+   drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
new file mode 100644
index ..9c9b8ac7aea3
--- /dev/null
+++ b/drivers/gpu/drm/drm_client.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 Noralf Trønnes
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
+
+/**
+ * DOC: overview
+ *
+ * This library provides support for clients running in the kernel like fbdev 
and bootsplash.
+ * Currently it's only partially implemented, just enough to support fbdev.
+ *
+ * GEM drivers which provide a GEM based dumb buffer with a virtual address 
are supported.
+ */
+
+static int drm_client_open(struct drm_client_dev *client)
+{
+   struct drm_device *dev = client->dev;
+   struct drm_file *file;
+
+   file = drm_file_alloc(dev->primary);
+   if (IS_ERR(file))
+   return PTR_ERR(file);
+
+   mutex_lock(&dev->filelist_mutex);
+   list_add(&file->lhead, &dev->filelist_internal);
+   mutex_unlock(&dev->filelist_mutex);
+
+   client->file = file;
+
+   return 0;
+}
+
+static void drm_client_close(struct drm_client_dev *client)
+{
+   struct drm_device *dev = client->dev;
+
+   mutex_lock(&dev->filelist_mutex);
+   list_del(&client->file->lhead);
+   mutex_unlock(&dev->filelist_mutex);
+
+   drm_file_free(client->file);
+}
+EXPORT_SYMBOL(drm_client_close);
+
+/**
+ * drm_client_new - Create a DRM client
+ * @dev: DRM device
+ * @client: DRM client
+ * @name: Client name
+ *
+ * Use drm_client_put() to free the client.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_new(struct drm_device *dev, struct drm_client_dev *client,
+  const char *name)
+{
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
+   !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
+   return -ENOTSUPP;
+
+   client->dev = dev;
+   client->name = name;
+
+   ret = drm_client_open(client);
+   if (ret)
+   return ret;
+
+   drm_dev_get(dev);

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show who pinned the pages when a leak is hit (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev2)
URL   : https://patchwork.freedesktop.org/series/45770/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4412_full -> Patchwork_9495_full =

== Summary - FAILURE ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@gem_pwrite@big-cpu-random:
  shard-kbl:  PASS -> DMESG-WARN +5

igt@gem_pwrite@big-gtt-backwards:
  shard-hsw:  PASS -> DMESG-WARN +6

igt@gem_pwrite@big-gtt-random:
  shard-apl:  PASS -> DMESG-WARN +3
  shard-glk:  PASS -> DMESG-WARN +3

igt@gem_pwrite@huge-gtt-fbr:
  shard-snb:  PASS -> DMESG-WARN +5


 Warnings 

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


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_tiled_fence_blits@normal:
  shard-snb:  NOTRUN -> INCOMPLETE (fdo#105411)

igt@gem_workarounds@suspend-resume-context:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105363)

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

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


 Possible fixes 

igt@drv_suspend@shrink:
  shard-glk:  FAIL (fdo#106886) -> PASS

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

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

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#102887, fdo#105363) -> PASS

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS +1

igt@kms_rotation_crc@sprite-rotation-180:
  shard-snb:  FAIL (fdo#104724, fdo#103925) -> PASS

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

igt@perf_pmu@busy-idle-no-semaphores-vecs0:
  shard-snb:  INCOMPLETE (fdo#105411) -> SKIP


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4412 -> Patchwork_9495

  CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9495: cd6455c5f8ad1d2336f31839edaa97525824b157 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


[Intel-gfx] [PATCH v2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.

2018-07-02 Thread StanLis
From: Stanislav Lisovskiy 

PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.

v2: Edited commit message, removed redundant whitespaces.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_display.c | 7 +++
 drivers/gpu/drm/i915/intel_sprite.c  | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 56818a45181c..d6de5ddcb912 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_AYUV,
 };
 
 static const uint32_t skl_pri_planar_formats[] = {
@@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = {
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
DRM_FORMAT_NV12,
+   DRM_FORMAT_AYUV,
 };
 
 static const uint64_t skl_format_modifiers_noccs[] = {
@@ -3497,6 +3499,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_XRGB_2101010;
case DRM_FORMAT_XBGR2101010:
return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010;
+   case DRM_FORMAT_AYUV:
+   return PLANE_CTL_FORMAT_AYUV;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -13396,6 +13400,8 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
modifier == I915_FORMAT_MOD_Y_TILED)
return true;
/* fall through */
+   case DRM_FORMAT_AYUV:
+   return true;
default:
return false;
}
@@ -14510,6 +14516,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_AYUV:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YVYU:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 344c0e709b19..8f95f8aad513 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1423,6 +1423,8 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
+   case DRM_FORMAT_AYUV:
+   return true;
/* fall through */
case DRM_FORMAT_C8:
if (modifier == DRM_FORMAT_MOD_LINEAR ||
-- 
2.17.0

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


[Intel-gfx] [PATCH v1] drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.

2018-07-02 Thread StanLis
From: Stanislav Lisovskiy 

---
 drivers/gpu/drm/i915/intel_display.c | 8 
 drivers/gpu/drm/i915/intel_sprite.c  | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 56818a45181c..4bc702193c88 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_AYUV,
 };
 
 static const uint32_t skl_pri_planar_formats[] = {
@@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = {
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
DRM_FORMAT_NV12,
+   DRM_FORMAT_AYUV,
 };
 
 static const uint64_t skl_format_modifiers_noccs[] = {
@@ -2446,6 +2448,7 @@ static const struct drm_format_info ccs_formats[] = {
{ .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 8, .vsub = 16, },
 };
 
+
 static const struct drm_format_info *
 lookup_format_info(const struct drm_format_info formats[],
   int num_formats, u32 format)
@@ -3497,6 +3500,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_XRGB_2101010;
case DRM_FORMAT_XBGR2101010:
return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010;
+   case DRM_FORMAT_AYUV:
+   return PLANE_CTL_FORMAT_AYUV;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -13396,6 +13401,8 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
modifier == I915_FORMAT_MOD_Y_TILED)
return true;
/* fall through */
+   case DRM_FORMAT_AYUV:
+   return true;
default:
return false;
}
@@ -14510,6 +14517,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_AYUV:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YVYU:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 344c0e709b19..1bc446987720 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -585,6 +585,7 @@ vlv_update_plane(struct intel_plane *plane,
I915_WRITE_FW(SPCONSTALPHA(pipe, plane_id), 0);
 
I915_WRITE_FW(SPSIZE(pipe, plane_id), (crtc_h << 16) | crtc_w);
+
I915_WRITE_FW(SPCNTR(pipe, plane_id), sprctl);
I915_WRITE_FW(SPSURF(pipe, plane_id),
  intel_plane_ggtt_offset(plane_state) + sprsurf_offset);
@@ -1423,6 +1424,8 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
+   case DRM_FORMAT_AYUV:
+   return true;
/* fall through */
case DRM_FORMAT_C8:
if (modifier == DRM_FORMAT_MOD_LINEAR ||
-- 
2.17.0

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


Re: [Intel-gfx] [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()

2018-07-02 Thread Ville Syrjälä
On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote:
> Hi Ville,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> url:
> https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202
> base:   git://people.freedesktop.org/~airlied/linux.git drm-next
> 
> smatch warnings:
> drivers/gpu/drm/nouveau/nouveau_connector.c:461 
> nouveau_connector_ddc_detect() error: uninitialized symbol 'nv_encoder'.
> 
> # 
> https://github.com/0day-ci/linux/commit/7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> vim +/nv_encoder +461 drivers/gpu/drm/nouveau/nouveau_connector.c
> 
> 6ee738610 Ben Skeggs  2009-12-11  407  
> 8777c5c11 Ben Skeggs  2014-06-06  408  static struct nouveau_encoder *
> 8777c5c11 Ben Skeggs  2014-06-06  409  
> nouveau_connector_ddc_detect(struct drm_connector *connector)
> 6ee738610 Ben Skeggs  2009-12-11  410  {
> 6ee738610 Ben Skeggs  2009-12-11  411 struct drm_device *dev = 
> connector->dev;
> 1a1841d30 Ben Skeggs  2012-12-10  412 struct nouveau_connector 
> *nv_connector = nouveau_connector(connector);
> 77145f1cb Ben Skeggs  2012-07-31  413 struct nouveau_drm *drm = 
> nouveau_drm(dev);
> 1167c6bc5 Ben Skeggs  2016-05-18  414 struct nvkm_gpio *gpio = 
> nvxx_gpio(&drm->client.device);
> 8777c5c11 Ben Skeggs  2014-06-06  415 struct nouveau_encoder 
> *nv_encoder;
> 6d385c0aa Rob Clark   2014-07-17  416 struct drm_encoder *encoder;
> 1a1841d30 Ben Skeggs  2012-12-10  417 int i, panel = -ENODEV;
> 1a1841d30 Ben Skeggs  2012-12-10  418  
> 1a1841d30 Ben Skeggs  2012-12-10  419 /* eDP panels need powering on 
> by us (if the VBIOS doesn't default it
> 1a1841d30 Ben Skeggs  2012-12-10  420  * to on) before doing any AUX 
> channel transactions.  LVDS panel power
> 1a1841d30 Ben Skeggs  2012-12-10  421  * is handled by the SOR 
> itself, and not required for LVDS DDC.
> 1a1841d30 Ben Skeggs  2012-12-10  422  */
> 1a1841d30 Ben Skeggs  2012-12-10  423 if (nv_connector->type == 
> DCB_CONNECTOR_eDP) {
> 2ea7249fe Ben Skeggs  2015-08-20  424 panel = 
> nvkm_gpio_get(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff);
> 1a1841d30 Ben Skeggs  2012-12-10  425 if (panel == 0) {
> 2ea7249fe Ben Skeggs  2015-08-20  426 
> nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1);
> 1a1841d30 Ben Skeggs  2012-12-10  427 msleep(300);
> 1a1841d30 Ben Skeggs  2012-12-10  428 }
> 1a1841d30 Ben Skeggs  2012-12-10  429 }
> 6ee738610 Ben Skeggs  2009-12-11  430  
> 7ec8bb653 Ville Syrjälä   2018-06-28  431 
> drm_connector_for_each_possible_encoder(connector, encoder, i) {
> 6d385c0aa Rob Clark   2014-07-17  432 nv_encoder = 
> nouveau_encoder(encoder);
> 
> ^
> If we enter the loop that means nv_encoder is non-NULL.  Smatch can't
> prove that we always enter the loop in this case for whatever reason but
> my guess is that we always do.
> 
> 4ca2b7120 Francisco Jerez 2010-08-08  433  
> 8777c5c11 Ben Skeggs  2014-06-06  434 if 
> (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> 8777c5c11 Ben Skeggs  2014-06-06  435 int ret = 
> nouveau_dp_detect(nv_encoder);
> 52aa30f25 Ben Skeggs  2016-11-04  436 if (ret == 
> NOUVEAU_DP_MST)
> 52aa30f25 Ben Skeggs  2016-11-04  437 return 
> NULL;
> 52aa30f25 Ben Skeggs  2016-11-04  438 if (ret == 
> NOUVEAU_DP_SST)
> 8777c5c11 Ben Skeggs  2014-06-06  439 break;
> 8777c5c11 Ben Skeggs  2014-06-06  440 } else
> 39c1c9011 Lukas Wunner2016-01-11  441 if 
> ((vga_switcheroo_handler_flags() &
> 39c1c9011 Lukas Wunner2016-01-11  442  
> VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
> 39c1c9011 Lukas Wunner2016-01-11  443 
> nv_encoder->dcb->type == DCB_OUTPUT_LVDS &&
> 39c1c9011 Lukas Wunner2016-01-11  444 nv_encoder->i2c) {
> 39c1c9011 Lukas Wunner2016-01-11  445 int ret;
> 39c1c9011 Lukas Wunner2016-01-11  446 
> vga_switcheroo_lock_ddc(dev->pdev);
> 39c1c9011 Lukas Wunner2016-01-11  447 ret = 
> nvkm_probe_i2c(nv_encoder->i2c, 0x50);
> 39c1c9011 Lukas Wunner2016-01-11  448 
> vga_switcheroo_unlock_ddc(dev->pdev);
> 39c1c9011 Lukas Wunner2016-01-11  449 if (ret)
> 39c1c9011 Lukas Wunner2016-01-11  450 break;
> 39c1c9011 Lukas Wunner2016-01-11  451 

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 14:39:50, Christian König wrote:
[...]
> Not wanting to block something as important as this, so feel free to add an
> Acked-by: Christian König  to the patch.

Thanks a lot!

> Let's rather face the next topic: Any idea how to runtime test this?

This is a good question indeed. One way to do that would be triggering
the OOM killer from the context which uses each of these mmu notifiers
(one at the time) and see how that works. You would see the note in the
log whenever the notifier would block. The primary thing to test is how
often the oom reaper really had to back off completely.

> I mean I can rather easily provide a test which crashes an AMD GPU, which in
> turn then would mean that the MMU notifier would block forever without this
> patch.

Well, you do not really have to go that far. It should be sufficient to
do the above. The current code would simply back of without releasing
any memory. The patch should help to reclaim some memory.
 
> But do you know a way to let the OOM killer kill a specific process?

Yes, you can set its oom_score_adj to 1000 which means always select
that task.
-- 
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 06/20] drm/i915/icl: Power down unused DSI lanes

2018-07-02 Thread Chauhan, Madhav
> -Original Message-
> From: Nikula, Jani
> Sent: Monday, July 2, 2018 6:12 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Zanoni, Paulo R ; Shankar, Uma
> ; Vivi, Rodrigo ;
> Chauhan, Madhav 
> Subject: Re: [PATCH 06/20] drm/i915/icl: Power down unused DSI lanes
> 
> On Fri, 15 Jun 2018, Madhav Chauhan  wrote:
> > To save power, unused lanes should be powered down using the bitfield
> > of PORT_CL_DW10.
> >
> > Signed-off-by: Madhav Chauhan 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi_new.c | 44
> > 
> >  1 file changed, 44 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
> > b/drivers/gpu/drm/i915/intel_dsi_new.c
> > index 5ec4016..baaf46d 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi_new.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi_new.c
> > @@ -74,6 +74,47 @@ static void gen11_dsi_enable_io_power(struct
> intel_encoder *encoder)
> > intel_display_power_get(dev_priv,
> POWER_DOMAIN_PORT_DDI_B_IO);  }
> >
> > +static void gen11_dsi_power_up_lanes(struct intel_encoder *encoder) {
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> > +   enum port port;
> > +   u32 tmp;
> > +   u32 lane_mask;
> > +
> > +   switch (intel_dsi->lane_count) {
> > +   case 1:
> > +   lane_mask = PWR_DOWN_LN_3_1_0;
> > +   break;
> > +   case 2:
> > +   lane_mask = PWR_DOWN_LN_3_1;
> > +   break;
> > +   case 3:
> > +   lane_mask = PWR_DOWN_LN_3;
> > +   break;
> > +   case 4:
> > +   lane_mask = PWR_UP_ALL_LANES;
> > +   break;
> > +   default:
> 
> Just put the default label next to case 4 to reduce duplication.
> 
> > +   lane_mask = PWR_UP_ALL_LANES;
> > +   break;
> > +   }
> > +
> > +   lane_mask = lane_mask << PWR_DOWN_LN_SHIFT;
> 
> Include the shifts in the macros as discussed.
> 
> With those,
> 
> Reviewed-by: Jani Nikula 

Ok. Thanks for review

Regards,
Madhav

> 
> > +
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   tmp = I915_READ(ICL_PORT_CL_DW10(port));
> > +   tmp &= ~PWR_DOWN_LN_MASK;
> > +   I915_WRITE(ICL_PORT_CL_DW10(port), tmp | lane_mask);
> > +   }
> > +}
> > +
> > +static void gen11_dsi_enable_port_and_phy(struct intel_encoder
> > +*encoder) {
> > +   /* step 4a: power up all lanes of the DDI used by DSI */
> > +   gen11_dsi_power_up_lanes(encoder);
> > +}
> > +
> >  static void __attribute__((unused)) gen11_dsi_pre_enable(
> > struct intel_encoder *encoder,
> > const struct intel_crtc_state *pipe_config,
> @@ -84,4 +125,7 @@
> > static void __attribute__((unused)) gen11_dsi_pre_enable(
> >
> > /* step3: enable DSI PLL */
> > gen11_dsi_program_esc_clk_div(encoder);
> > +
> > +   /* step4: enable DSI port and DPHY */
> > +   gen11_dsi_enable_port_and_phy(encoder);
> >  }
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 06/20] drm/i915/icl: Power down unused DSI lanes

2018-07-02 Thread Jani Nikula
On Fri, 15 Jun 2018, Madhav Chauhan  wrote:
> To save power, unused lanes should be powered
> down using the bitfield of PORT_CL_DW10.
>
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/intel_dsi_new.c | 44 
> 
>  1 file changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c 
> b/drivers/gpu/drm/i915/intel_dsi_new.c
> index 5ec4016..baaf46d 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_new.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_new.c
> @@ -74,6 +74,47 @@ static void gen11_dsi_enable_io_power(struct intel_encoder 
> *encoder)
>   intel_display_power_get(dev_priv, POWER_DOMAIN_PORT_DDI_B_IO);
>  }
>  
> +static void gen11_dsi_power_up_lanes(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> + enum port port;
> + u32 tmp;
> + u32 lane_mask;
> +
> + switch (intel_dsi->lane_count) {
> + case 1:
> + lane_mask = PWR_DOWN_LN_3_1_0;
> + break;
> + case 2:
> + lane_mask = PWR_DOWN_LN_3_1;
> + break;
> + case 3:
> + lane_mask = PWR_DOWN_LN_3;
> + break;
> + case 4:
> + lane_mask = PWR_UP_ALL_LANES;
> + break;
> + default:

Just put the default label next to case 4 to reduce duplication.

> + lane_mask = PWR_UP_ALL_LANES;
> + break;
> + }
> +
> + lane_mask = lane_mask << PWR_DOWN_LN_SHIFT;

Include the shifts in the macros as discussed.

With those,

Reviewed-by: Jani Nikula 

> +
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(ICL_PORT_CL_DW10(port));
> + tmp &= ~PWR_DOWN_LN_MASK;
> + I915_WRITE(ICL_PORT_CL_DW10(port), tmp | lane_mask);
> + }
> +}
> +
> +static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
> +{
> + /* step 4a: power up all lanes of the DDI used by DSI */
> + gen11_dsi_power_up_lanes(encoder);
> +}
> +
>  static void __attribute__((unused)) gen11_dsi_pre_enable(
>   struct intel_encoder *encoder,
>   const struct intel_crtc_state *pipe_config,
> @@ -84,4 +125,7 @@ static void __attribute__((unused)) gen11_dsi_pre_enable(
>  
>   /* step3: enable DSI PLL */
>   gen11_dsi_program_esc_clk_div(encoder);
> +
> + /* step4: enable DSI port and DPHY */
> + gen11_dsi_enable_port_and_phy(encoder);
>  }

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


Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Christian König

Am 02.07.2018 um 14:35 schrieb Michal Hocko:

On Mon 02-07-18 14:24:29, Christian König wrote:

Am 02.07.2018 um 14:20 schrieb Michal Hocko:

On Mon 02-07-18 14:13:42, Christian König wrote:

Am 02.07.2018 um 13:54 schrieb Michal Hocko:

On Mon 02-07-18 11:14:58, Christian König wrote:

Am 27.06.2018 um 09:44 schrieb Michal Hocko:

This is the v2 of RFC based on the feedback I've received so far. The
code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
because I have no idea how.

Any further feedback is highly appreciated of course.

That sounds like it should work and at least the amdgpu changes now look
good to me on first glance.

Can you split that up further in the usual way? E.g. adding the blockable
flag in one patch and fixing all implementations of the MMU notifier in
follow up patches.

But such a code would be broken, no? Ignoring the blockable state will
simply lead to lockups until the fixup parts get applied.

Well to still be bisect-able you only need to get the interface change in
first with fixing the function signature of the implementations.

That would only work if those functions return -AGAIN unconditionally.
Otherwise they would pretend to not block while that would be obviously
incorrect. This doesn't sound correct to me.


Then add all the new code to the implementations and last start to actually
use the new interface.

That is a pattern we use regularly and I think it's good practice to do
this.

But we do rely on the proper blockable handling.

Yeah, but you could add the handling only after you have all the
implementations in place. Don't you?

Yeah, but then I would be adding a code with no user. And I really
prefer to no do so because then the code is harder to argue about.


Is the split up really worth it? I was thinking about that but had hard
times to end up with something that would be bisectable. Well, except
for returning -EBUSY until all notifiers are implemented. Which I found
confusing.

It at least makes reviewing changes much easier, cause as driver maintainer
I can concentrate on the stuff only related to me.

Additional to that when you cause some unrelated side effect in a driver we
can much easier pinpoint the actual change later on when the patch is
smaller.


This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd
changes.

If you are worried to give r-b only for those then this can be done even
for larger patches. Just make your Reviewd-by more specific
R-b: name # For BLA BLA

Yeah, possible alternative but more work for me when I review it :)

I definitely do not want to add more work to reviewers and I completely
see how massive "flag days" like these are not popular but I really
didn't find a reasonable way around that would be both correct and
wouldn't add much more churn on the way. So if you really insist then I
would really appreciate a hint on the way to achive the same without any
above downsides.

Well, I don't insist on this. It's just from my point of view that this
patch doesn't needs to be one patch, but could be split up.

Well, if there are more people with the same concern I can try to do
that. But if your only concern is to focus on your particular part then
I guess it would be easier both for you and me to simply apply the patch
and use git show $files_for_your_subystem on your end. I have put the
patch to attempts/oom-vs-mmu-notifiers branch to my tree at
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git


Not wanting to block something as important as this, so feel free to add 
an Acked-by: Christian König  to the patch.


Let's rather face the next topic: Any idea how to runtime test this?

I mean I can rather easily provide a test which crashes an AMD GPU, 
which in turn then would mean that the MMU notifier would block forever 
without this patch.


But do you know a way to let the OOM killer kill a specific process?

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


Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 14:24:29, Christian König wrote:
> Am 02.07.2018 um 14:20 schrieb Michal Hocko:
> > On Mon 02-07-18 14:13:42, Christian König wrote:
> > > Am 02.07.2018 um 13:54 schrieb Michal Hocko:
> > > > On Mon 02-07-18 11:14:58, Christian König wrote:
> > > > > Am 27.06.2018 um 09:44 schrieb Michal Hocko:
> > > > > > This is the v2 of RFC based on the feedback I've received so far. 
> > > > > > The
> > > > > > code even compiles as a bonus ;) I haven't runtime tested it yet, 
> > > > > > mostly
> > > > > > because I have no idea how.
> > > > > > 
> > > > > > Any further feedback is highly appreciated of course.
> > > > > That sounds like it should work and at least the amdgpu changes now 
> > > > > look
> > > > > good to me on first glance.
> > > > > 
> > > > > Can you split that up further in the usual way? E.g. adding the 
> > > > > blockable
> > > > > flag in one patch and fixing all implementations of the MMU notifier 
> > > > > in
> > > > > follow up patches.
> > > > But such a code would be broken, no? Ignoring the blockable state will
> > > > simply lead to lockups until the fixup parts get applied.
> > > Well to still be bisect-able you only need to get the interface change in
> > > first with fixing the function signature of the implementations.
> > That would only work if those functions return -AGAIN unconditionally.
> > Otherwise they would pretend to not block while that would be obviously
> > incorrect. This doesn't sound correct to me.
> > 
> > > Then add all the new code to the implementations and last start to 
> > > actually
> > > use the new interface.
> > > 
> > > That is a pattern we use regularly and I think it's good practice to do
> > > this.
> > But we do rely on the proper blockable handling.
> 
> Yeah, but you could add the handling only after you have all the
> implementations in place. Don't you?

Yeah, but then I would be adding a code with no user. And I really
prefer to no do so because then the code is harder to argue about.

> > > > Is the split up really worth it? I was thinking about that but had hard
> > > > times to end up with something that would be bisectable. Well, except
> > > > for returning -EBUSY until all notifiers are implemented. Which I found
> > > > confusing.
> > > It at least makes reviewing changes much easier, cause as driver 
> > > maintainer
> > > I can concentrate on the stuff only related to me.
> > > 
> > > Additional to that when you cause some unrelated side effect in a driver 
> > > we
> > > can much easier pinpoint the actual change later on when the patch is
> > > smaller.
> > > 
> > > > > This way I'm pretty sure Felix and I can give an rb on the 
> > > > > amdgpu/amdkfd
> > > > > changes.
> > > > If you are worried to give r-b only for those then this can be done even
> > > > for larger patches. Just make your Reviewd-by more specific
> > > > R-b: name # For BLA BLA
> > > Yeah, possible alternative but more work for me when I review it :)
> > I definitely do not want to add more work to reviewers and I completely
> > see how massive "flag days" like these are not popular but I really
> > didn't find a reasonable way around that would be both correct and
> > wouldn't add much more churn on the way. So if you really insist then I
> > would really appreciate a hint on the way to achive the same without any
> > above downsides.
> 
> Well, I don't insist on this. It's just from my point of view that this
> patch doesn't needs to be one patch, but could be split up.

Well, if there are more people with the same concern I can try to do
that. But if your only concern is to focus on your particular part then
I guess it would be easier both for you and me to simply apply the patch
and use git show $files_for_your_subystem on your end. I have put the
patch to attempts/oom-vs-mmu-notifiers branch to my tree at
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
-- 
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 1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active()

2018-07-02 Thread Tvrtko Ursulin


On 02/07/2018 12:44, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-07-02 12:34:51)

@@ -1921,6 +1914,8 @@ void i915_vma_move_to_active(struct i915_vma *vma,
   
   if (flags & EXEC_OBJECT_NEEDS_FENCE)

   i915_gem_active_set(&vma->last_fence, rq);
+
+ export_fence(vma, rq, flags);


Don't care about new extra reservation object operations from the other
i915_move_to_active_callers?


No. Not filling the reservation_object is an underhand shortcut. It
should never be not correct to track the fences for an object. Doing it
in one place correctly, should prevent cheating.


Fair enough.

Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Christian König

Am 02.07.2018 um 14:20 schrieb Michal Hocko:

On Mon 02-07-18 14:13:42, Christian König wrote:

Am 02.07.2018 um 13:54 schrieb Michal Hocko:

On Mon 02-07-18 11:14:58, Christian König wrote:

Am 27.06.2018 um 09:44 schrieb Michal Hocko:

This is the v2 of RFC based on the feedback I've received so far. The
code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
because I have no idea how.

Any further feedback is highly appreciated of course.

That sounds like it should work and at least the amdgpu changes now look
good to me on first glance.

Can you split that up further in the usual way? E.g. adding the blockable
flag in one patch and fixing all implementations of the MMU notifier in
follow up patches.

But such a code would be broken, no? Ignoring the blockable state will
simply lead to lockups until the fixup parts get applied.

Well to still be bisect-able you only need to get the interface change in
first with fixing the function signature of the implementations.

That would only work if those functions return -AGAIN unconditionally.
Otherwise they would pretend to not block while that would be obviously
incorrect. This doesn't sound correct to me.


Then add all the new code to the implementations and last start to actually
use the new interface.

That is a pattern we use regularly and I think it's good practice to do
this.

But we do rely on the proper blockable handling.


Yeah, but you could add the handling only after you have all the 
implementations in place. Don't you?



Is the split up really worth it? I was thinking about that but had hard
times to end up with something that would be bisectable. Well, except
for returning -EBUSY until all notifiers are implemented. Which I found
confusing.

It at least makes reviewing changes much easier, cause as driver maintainer
I can concentrate on the stuff only related to me.

Additional to that when you cause some unrelated side effect in a driver we
can much easier pinpoint the actual change later on when the patch is
smaller.


This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd
changes.

If you are worried to give r-b only for those then this can be done even
for larger patches. Just make your Reviewd-by more specific
R-b: name # For BLA BLA

Yeah, possible alternative but more work for me when I review it :)

I definitely do not want to add more work to reviewers and I completely
see how massive "flag days" like these are not popular but I really
didn't find a reasonable way around that would be both correct and
wouldn't add much more churn on the way. So if you really insist then I
would really appreciate a hint on the way to achive the same without any
above downsides.


Well, I don't insist on this. It's just from my point of view that this 
patch doesn't needs to be one patch, but could be split up.


Could be that I just don't know the code or the consequences of adding 
that well enough to really judge.


Christian.
___
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: Show who pinned the pages when a leak is hit (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev2)
URL   : https://patchwork.freedesktop.org/series/45770/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9495 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_ctx_create@basic-files:
  fi-skl-gvtdvm:  PASS -> DMESG-WARN (fdo#106954)


 Possible fixes 

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

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


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


== Participating hosts (43 -> 39) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4412 -> Patchwork_9495

  CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9495: cd6455c5f8ad1d2336f31839edaa97525824b157 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

cd6455c5f8ad drm/i915: Show who pinned the pages when a leak is hit

== Logs ==

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


Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 14:13:42, Christian König wrote:
> Am 02.07.2018 um 13:54 schrieb Michal Hocko:
> > On Mon 02-07-18 11:14:58, Christian König wrote:
> > > Am 27.06.2018 um 09:44 schrieb Michal Hocko:
> > > > This is the v2 of RFC based on the feedback I've received so far. The
> > > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
> > > > because I have no idea how.
> > > > 
> > > > Any further feedback is highly appreciated of course.
> > > That sounds like it should work and at least the amdgpu changes now look
> > > good to me on first glance.
> > > 
> > > Can you split that up further in the usual way? E.g. adding the blockable
> > > flag in one patch and fixing all implementations of the MMU notifier in
> > > follow up patches.
> > But such a code would be broken, no? Ignoring the blockable state will
> > simply lead to lockups until the fixup parts get applied.
> 
> Well to still be bisect-able you only need to get the interface change in
> first with fixing the function signature of the implementations.

That would only work if those functions return -AGAIN unconditionally.
Otherwise they would pretend to not block while that would be obviously
incorrect. This doesn't sound correct to me.

> Then add all the new code to the implementations and last start to actually
> use the new interface.
> 
> That is a pattern we use regularly and I think it's good practice to do
> this.

But we do rely on the proper blockable handling.

> > Is the split up really worth it? I was thinking about that but had hard
> > times to end up with something that would be bisectable. Well, except
> > for returning -EBUSY until all notifiers are implemented. Which I found
> > confusing.
> 
> It at least makes reviewing changes much easier, cause as driver maintainer
> I can concentrate on the stuff only related to me.
> 
> Additional to that when you cause some unrelated side effect in a driver we
> can much easier pinpoint the actual change later on when the patch is
> smaller.
> 
> > 
> > > This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd
> > > changes.
> > If you are worried to give r-b only for those then this can be done even
> > for larger patches. Just make your Reviewd-by more specific
> > R-b: name # For BLA BLA
> 
> Yeah, possible alternative but more work for me when I review it :)

I definitely do not want to add more work to reviewers and I completely
see how massive "flag days" like these are not popular but I really
didn't find a reasonable way around that would be both correct and
wouldn't add much more churn on the way. So if you really insist then I
would really appreciate a hint on the way to achive the same without any
above downsides.
-- 
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 06/10] drm/i915/crc: implement verify_crc_source callback

2018-07-02 Thread Maarten Lankhorst
Op 02-07-18 om 13:07 schreef Mahesh Kumar:
> This patch implements verify_crc_source callback function introduced
> earlier in this series.
>
> Signed-off-by: Mahesh Kumar 
> Cc: dri-de...@lists.freedesktop.org
> Reviewed-by: Maarten Lankhorst 
> ---
Patch 6 and 7 were acked for inclusion through drm-misc by Jani:
https://people.freedesktop.org/~cbrill/dri-log/?channel=intel-gfx&highlight_names=&date=2018-07-02

But we still need ack from the other maintainers to get this patch merged. :)
Could you ping a few maintainers?

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


Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Christian König

Am 02.07.2018 um 13:54 schrieb Michal Hocko:

On Mon 02-07-18 11:14:58, Christian König wrote:

Am 27.06.2018 um 09:44 schrieb Michal Hocko:

This is the v2 of RFC based on the feedback I've received so far. The
code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
because I have no idea how.

Any further feedback is highly appreciated of course.

That sounds like it should work and at least the amdgpu changes now look
good to me on first glance.

Can you split that up further in the usual way? E.g. adding the blockable
flag in one patch and fixing all implementations of the MMU notifier in
follow up patches.

But such a code would be broken, no? Ignoring the blockable state will
simply lead to lockups until the fixup parts get applied.


Well to still be bisect-able you only need to get the interface change 
in first with fixing the function signature of the implementations.


Then add all the new code to the implementations and last start to 
actually use the new interface.


That is a pattern we use regularly and I think it's good practice to do 
this.



Is the split up really worth it? I was thinking about that but had hard
times to end up with something that would be bisectable. Well, except
for returning -EBUSY until all notifiers are implemented. Which I found
confusing.


It at least makes reviewing changes much easier, cause as driver 
maintainer I can concentrate on the stuff only related to me.


Additional to that when you cause some unrelated side effect in a driver 
we can much easier pinpoint the actual change later on when the patch is 
smaller.





This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd
changes.

If you are worried to give r-b only for those then this can be done even
for larger patches. Just make your Reviewd-by more specific
R-b: name # For BLA BLA


Yeah, possible alternative but more work for me when I review it :)

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Show who pinned the pages when a leak is hit (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev2)
URL   : https://patchwork.freedesktop.org/series/45770/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Show who pinned the pages when a leak is hit
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3666:16: warning: expression 
using sizeof(void)

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Show who pinned the pages when a leak is hit (rev2)

2018-07-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Show who pinned the pages when a leak is hit (rev2)
URL   : https://patchwork.freedesktop.org/series/45770/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
cd6455c5f8ad drm/i915: Show who pinned the pages when a leak is hit
-:207: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#207: FILE: drivers/gpu/drm/i915/i915_gem_object.h:253:
+   spinlock_t debug_lock;

total: 0 errors, 0 warnings, 1 checks, 200 lines checked

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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 01/17] lib: Report file cache as available system memory

2018-07-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-07-02 12:54:18)
> 
> On 02/07/2018 10:07, Chris Wilson wrote:
> > sysinfo() doesn't include all reclaimable memory. In particular it
> > excludes the majority of global_node_page_state(NR_FILE_PAGES),
> > reclaimable pages that are a copy of on-disk files It seems the only way
> > to obtain this counter is by parsing /proc/meminfo. For comparison,
> > check vm_enough_memory() which includes NR_FILE_PAGES as available
> > (sadly there's no way to call vm_enough_memory() directly either!)
> > 
> > v2: Pay attention to what one writes.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   lib/intel_os.c | 36 +++-
> >   1 file changed, 31 insertions(+), 5 deletions(-)
> > 
> > diff --git a/lib/intel_os.c b/lib/intel_os.c
> > index 885ffdcec..5bd18fc52 100644
> > --- a/lib/intel_os.c
> > +++ b/lib/intel_os.c
> > @@ -84,6 +84,18 @@ intel_get_total_ram_mb(void)
> >   return retval / (1024*1024);
> >   }
> >   
> > +static uint64_t get_meminfo(const char *info, const char *tag)
> > +{
> > + const char *str;
> > + unsigned long val;
> > +
> > + str = strstr(info, tag);
> > + if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
> > + return (uint64_t)val << 10;
> > +
> > + return 0;
> 
> Might be safer to assert format was as expected and keywords we expect 
> are there, rather than silently return zero.

Definitely prefer not to assert here if we can help it.
igt_warn should be obvious enough to catch change in tags, but not if
the information changes.
 
> > +}
> > +
> >   /**
> >* intel_get_avail_ram_mb:
> >*
> > @@ -96,17 +108,31 @@ intel_get_avail_ram_mb(void)
> >   uint64_t retval;
> >   
> >   #ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */
> > - struct sysinfo sysinf;
> > + char *info;
> >   int fd;
> >   
> >   fd = drm_open_driver(DRIVER_INTEL);
> >   intel_purge_vm_caches(fd);
> >   close(fd);
> >   
> > - igt_assert(sysinfo(&sysinf) == 0);
> > - retval = sysinf.freeram;
> > - retval += min(sysinf.freeswap, sysinf.bufferram);
> > - retval *= sysinf.mem_unit;
> > + fd = open("/proc", O_RDONLY);
> > + info = igt_sysfs_get(fd, "meminfo");
> > + close(fd);
> > +
> > + if (info) {
> > + retval  = get_meminfo(info, "MemAvailable: ");
> > + retval += get_meminfo(info, "Buffers: ");
> > + retval += get_meminfo(info, "Cached: ");
> > + retval += get_meminfo(info, "SwapCached: ");
> 
> I think it would be more robust to have no trailing space in tag strings.

There was a reason iirc, but I think it was just for debug convenience.

> > + free(info);
> > + } else {
> > + struct sysinfo sysinf;
> > +
> > + igt_assert(sysinfo(&sysinf) == 0);
> > + retval = sysinf.freeram;
> > + retval += min(sysinf.freeswap, sysinf.bufferram);
> > + retval *= sysinf.mem_unit;
> > + }
> 
> Not sure it is worth keeping this path - will we ever not have 
> /proc/meminfo?

I expect someone will eventually deem it to be too dangerous information
and remove it. I felt since we had the code here, we might as well try.
Technically /proc doesn't have to be mounted. :|

> >   #elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */
> >   long pagesize, npages;
> >   
> > 
> 
> Google agrees with you that sysinfo indeed has this limitation. So in 
> general no complaints.
> 
> One tiny detail might be that this would now return a too large value - 
> doesn't count that it should not swap out itself when thinking about 
> free memory. But I don't think that is for this level of API to concern 
> with - it is definitely way more correct to report page cache.

The question we ask is whether or not the test itself will be swapped
out; I don't mind if we swap others out in order to run the test. We do
after all try and purge memory to make it all available to ourselves,
and part of that was in the belief that it would make the filecache
available to us.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 03/17] igt/gem_set_tiling_vs_pwrite: Show the erroneous value

2018-07-02 Thread Tvrtko Ursulin


On 02/07/2018 10:07, Chris Wilson wrote:

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

diff --git a/tests/gem_set_tiling_vs_pwrite.c b/tests/gem_set_tiling_vs_pwrite.c
index 006edfe4e..f0126b648 100644
--- a/tests/gem_set_tiling_vs_pwrite.c
+++ b/tests/gem_set_tiling_vs_pwrite.c
@@ -75,7 +75,7 @@ igt_simple_main
memset(data, 0, OBJECT_SIZE);
gem_read(fd, handle, 0, data, OBJECT_SIZE);
for (i = 0; i < OBJECT_SIZE/4; i++)
-   igt_assert(i == data[i]);
+   igt_assert_eq_u32(data[i], i);
  
  	/* touch it before changing the tiling, so that the fence sticks around */

gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
@@ -88,7 +88,7 @@ igt_simple_main
memset(data, 0, OBJECT_SIZE);
gem_read(fd, handle, 0, data, OBJECT_SIZE);
for (i = 0; i < OBJECT_SIZE/4; i++)
-   igt_assert(i == data[i]);
+   igt_assert_eq_u32(data[i], i);
  
  	munmap(ptr, OBJECT_SIZE);
  



Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 02/17] igt/gem_tiled_partial_pwrite_pread: Check for known swizzling

2018-07-02 Thread Tvrtko Ursulin


On 02/07/2018 10:07, Chris Wilson wrote:

As we want to compare a templated tiling pattern against the target_bo,
we need to know that the swizzling is compatible. Or else the two
tiling pattern may differ due to underlying page address that we cannot
know, and so the test may sporadically fail.

References: https://bugs.freedesktop.org/show_bug.cgi?id=102575
Signed-off-by: Chris Wilson 
---
  tests/gem_tiled_partial_pwrite_pread.c | 24 
  1 file changed, 24 insertions(+)

diff --git a/tests/gem_tiled_partial_pwrite_pread.c 
b/tests/gem_tiled_partial_pwrite_pread.c
index fe573c37c..83c57c07d 100644
--- a/tests/gem_tiled_partial_pwrite_pread.c
+++ b/tests/gem_tiled_partial_pwrite_pread.c
@@ -249,6 +249,24 @@ static void test_partial_read_writes(void)
}
  }
  
+static bool known_swizzling(uint32_t handle)

+{
+   struct drm_i915_gem_get_tiling2 {
+   uint32_t handle;
+   uint32_t tiling_mode;
+   uint32_t swizzle_mode;
+   uint32_t phys_swizzle_mode;
+   } arg = {
+   .handle = handle,
+   };
+#define DRM_IOCTL_I915_GEM_GET_TILING2	DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_TILING, struct 


Can't we rely on this being in system headers by now?

drm_i915_gem_get_tiling2)

+
+   if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING2, &arg))
+   return false;
+
+   return arg.phys_swizzle_mode == arg.swizzle_mode;
+}
+
  igt_main
  {
uint32_t tiling_mode = I915_TILING_X;
@@ -271,6 +289,12 @@ igt_main
  &tiling_mode, 
&scratch_pitch, 0);
igt_assert(tiling_mode == I915_TILING_X);
igt_assert(scratch_pitch == 4096);
+
+   /*
+* As we want to compare our template tiled pattern against
+* the target bo, we need consistent swizzling on both.
+*/
+   igt_require(known_swizzling(scratch_bo->handle));
staging_bo = drm_intel_bo_alloc(bufmgr, "staging bo", BO_SIZE, 
4096);
tiled_staging_bo = drm_intel_bo_alloc_tiled(bufmgr, "scratch 
bo", 1024,
BO_SIZE/4096, 4,



Another option could be to keep allocating until we found one in the 
memory area with compatible swizzling? Like this it may be some noise in 
the test pass<->skip transitions.


Regards,

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


[Intel-gfx] [PATCH v2] drm/i915: Show who pinned the pages when a leak is hit

2018-07-02 Thread Chris Wilson
Currently, we emit a warning when freeing an object if we do so with the
pages still pinned (presumably as they are still in use somewhere). This
only tells us that there is a problem, but doesn't tell us anything
about the object or who might be pinning them and so provides no clue as
to track down the problem.

Let's try tracking everyone who pins the pages to see if we strike it
lucky and catch the culprit red handed.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105360
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Kconfig.debug |   1 +
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_gem.c|   5 +-
 drivers/gpu/drm/i915/i915_gem_object.c | 109 +
 drivers/gpu/drm/i915/i915_gem_object.h |  34 
 5 files changed, 150 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 9de8b1c51a5c..84052becb279 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -43,6 +43,7 @@ config DRM_I915_DEBUG_GEM
 bool "Insert extra checks into the GEM internals"
 default n
 depends on DRM_I915_WERROR
+select STACKDEPOT
 help
   Enable extra sanity checks (including BUGs) along the GEM driver
   paths that may slow the system down and if hit hang the machine.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2cefe4c30f88..cc334a0fc91d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2990,6 +2990,8 @@ i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
 {
might_lock(&obj->mm.lock);
 
+   track_i915_gem_object_pin_pages(obj);
+
if (atomic_inc_not_zero(&obj->mm.pages_pin_count))
return 0;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8954db6ab083..e56240dc93f3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2459,6 +2459,7 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
 
+   untrack_i915_gem_object_pin_pages(obj);
 unlock:
mutex_unlock(&obj->mm.lock);
 }
@@ -4870,8 +4871,10 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
if (obj->ops->release)
obj->ops->release(obj);
 
-   if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
+   if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) {
+   show_i915_gem_object_pin_pages(obj);
atomic_set(&obj->mm.pages_pin_count, 0);
+   }
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
 
diff --git a/drivers/gpu/drm/i915/i915_gem_object.c 
b/drivers/gpu/drm/i915/i915_gem_object.c
index aab8cdd80e6d..bad7fac72bdd 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/i915_gem_object.c
@@ -25,6 +25,115 @@
 #include "i915_drv.h"
 #include "i915_gem_object.h"
 
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+
+#include 
+
+#define STACKDEPTH 12
+
+void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+   unsigned long entries[STACKDEPTH];
+   struct stack_trace trace = {
+   .entries = entries,
+   .max_entries = ARRAY_SIZE(entries),
+   .skip = 1
+   };
+   unsigned long flags;
+   depot_stack_handle_t stack, *stacks;
+
+   save_stack_trace(&trace);
+   if (trace.nr_entries &&
+   trace.entries[trace.nr_entries - 1] == ULONG_MAX)
+   trace.nr_entries--;
+
+   stack = depot_save_stack(&trace, GFP_KERNEL);
+   if (!stack)
+   return;
+
+   spin_lock_irqsave(&obj->mm.debug_lock, flags);
+   stacks = krealloc(obj->mm.debug_owners,
+ (obj->mm.debug_count + 1) * sizeof(*stacks),
+ GFP_NOWAIT);
+   if (stacks) {
+   stacks[obj->mm.debug_count++] = stack;
+   obj->mm.debug_owners = stacks;
+   }
+   spin_unlock_irqrestore(&obj->mm.debug_lock, flags);
+}
+
+void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+   depot_stack_handle_t *stacks;
+   unsigned long flags;
+
+   spin_lock_irqsave(&obj->mm.debug_lock, flags);
+   stacks = fetch_and_zero(&obj->mm.debug_owners);
+   obj->mm.debug_count = 0;
+   spin_unlock_irqrestore(&obj->mm.debug_lock, flags);
+
+   kfree(stacks);
+}
+
+static int cmphandle(const void *_a, const void *_b)
+{
+   const depot_stack_handle_t * const a = _a, * const b = _b;
+
+   if (*a < *b)
+   return -1;
+   else if (*a > *b)
+   return 1;
+   else
+   return 0;
+}
+
+void show_i915_gem_object_p

Re: [Intel-gfx] [PATCH] drm/i915: Show who pinned the pages when a leak is hit

2018-07-02 Thread Chris Wilson
Quoting Chris Wilson (2018-07-02 12:44:52)
> @@ -451,6 +460,31 @@ i915_gem_object_get_tile_row_size(struct 
> drm_i915_gem_object *obj)
>  int i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
>unsigned int tiling, unsigned int stride);
>  
> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
> +
> +void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj);
> +void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj);
> +void show_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj);
> +
> +#else
> +
> +static inline void
> +track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
> +{
> +}
> +
> +static inline void
> +untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
> +{
> +}
> +
> +static inline void
> +show_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
> +{
> +}
> +
> +#endif

Grr, didn't notice in the rebase that i915_gem_object_pin_pages was no
longer here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 01/17] lib: Report file cache as available system memory

2018-07-02 Thread Tvrtko Ursulin


On 02/07/2018 10:07, Chris Wilson wrote:

sysinfo() doesn't include all reclaimable memory. In particular it
excludes the majority of global_node_page_state(NR_FILE_PAGES),
reclaimable pages that are a copy of on-disk files It seems the only way
to obtain this counter is by parsing /proc/meminfo. For comparison,
check vm_enough_memory() which includes NR_FILE_PAGES as available
(sadly there's no way to call vm_enough_memory() directly either!)

v2: Pay attention to what one writes.

Signed-off-by: Chris Wilson 
---
  lib/intel_os.c | 36 +++-
  1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/lib/intel_os.c b/lib/intel_os.c
index 885ffdcec..5bd18fc52 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -84,6 +84,18 @@ intel_get_total_ram_mb(void)
return retval / (1024*1024);
  }
  
+static uint64_t get_meminfo(const char *info, const char *tag)

+{
+   const char *str;
+   unsigned long val;
+
+   str = strstr(info, tag);
+   if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
+   return (uint64_t)val << 10;
+
+   return 0;


Might be safer to assert format was as expected and keywords we expect 
are there, rather than silently return zero.



+}
+
  /**
   * intel_get_avail_ram_mb:
   *
@@ -96,17 +108,31 @@ intel_get_avail_ram_mb(void)
uint64_t retval;
  
  #ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */

-   struct sysinfo sysinf;
+   char *info;
int fd;
  
  	fd = drm_open_driver(DRIVER_INTEL);

intel_purge_vm_caches(fd);
close(fd);
  
-	igt_assert(sysinfo(&sysinf) == 0);

-   retval = sysinf.freeram;
-   retval += min(sysinf.freeswap, sysinf.bufferram);
-   retval *= sysinf.mem_unit;
+   fd = open("/proc", O_RDONLY);
+   info = igt_sysfs_get(fd, "meminfo");
+   close(fd);
+
+   if (info) {
+   retval  = get_meminfo(info, "MemAvailable: ");
+   retval += get_meminfo(info, "Buffers: ");
+   retval += get_meminfo(info, "Cached: ");
+   retval += get_meminfo(info, "SwapCached: ");


I think it would be more robust to have no trailing space in tag strings.


+   free(info);
+   } else {
+   struct sysinfo sysinf;
+
+   igt_assert(sysinfo(&sysinf) == 0);
+   retval = sysinf.freeram;
+   retval += min(sysinf.freeswap, sysinf.bufferram);
+   retval *= sysinf.mem_unit;
+   }


Not sure it is worth keeping this path - will we ever not have 
/proc/meminfo?



  #elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */
long pagesize, npages;
  



Google agrees with you that sysinfo indeed has this limitation. So in 
general no complaints.


One tiny detail might be that this would now return a too large value - 
doesn't count that it should not swap out itself when thinking about 
free memory. But I don't think that is for this level of API to concern 
with - it is definitely way more correct to report page cache.


Regards,

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


Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 11:14:58, Christian König wrote:
> Am 27.06.2018 um 09:44 schrieb Michal Hocko:
> > This is the v2 of RFC based on the feedback I've received so far. The
> > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
> > because I have no idea how.
> > 
> > Any further feedback is highly appreciated of course.
> 
> That sounds like it should work and at least the amdgpu changes now look
> good to me on first glance.
> 
> Can you split that up further in the usual way? E.g. adding the blockable
> flag in one patch and fixing all implementations of the MMU notifier in
> follow up patches.

But such a code would be broken, no? Ignoring the blockable state will
simply lead to lockups until the fixup parts get applied.
Is the split up really worth it? I was thinking about that but had hard
times to end up with something that would be bisectable. Well, except
for returning -EBUSY until all notifiers are implemented. Which I found
confusing.

> This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd
> changes.

If you are worried to give r-b only for those then this can be done even
for larger patches. Just make your Reviewd-by more specific
R-b: name # For BLA BLA
-- 
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: failure for Improve crc-core driver interface (rev4)

2018-07-02 Thread Patchwork
== Series Details ==

Series: Improve crc-core driver interface (rev4)
URL   : https://patchwork.freedesktop.org/series/45246/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4411 -> Patchwork_9494 =

== Summary - FAILURE ==

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

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@gem_exec_suspend@basic-s3:
  {fi-cfl-8109u}: PASS -> DMESG-WARN

igt@kms_pipe_crc_basic@bad-source:
  {fi-cfl-8109u}: PASS -> FAIL +1
  fi-skl-6770hq:  PASS -> FAIL +6
  fi-bwr-2160:PASS -> FAIL +4
  fi-hsw-4770r:   PASS -> FAIL +6
  fi-glk-j4005:   PASS -> FAIL
  fi-cfl-8700k:   PASS -> FAIL +6
  {fi-kbl-x1275}: PASS -> FAIL
  fi-kbl-guc: PASS -> FAIL
  fi-glk-dsi: PASS -> FAIL
  fi-bsw-n3050:   PASS -> FAIL

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
  fi-ivb-3520m:   PASS -> FAIL +6
  fi-cfl-s3:  PASS -> FAIL +6
  fi-skl-6700hq:  PASS -> FAIL +6
  fi-skl-guc: PASS -> FAIL +6
  fi-blb-e6850:   PASS -> FAIL +4

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-ilk-650: PASS -> FAIL +4
  fi-elk-e7500:   PASS -> FAIL +4
  fi-byt-n2820:   PASS -> FAIL +4
  fi-snb-2520m:   PASS -> FAIL +4

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
  fi-bdw-5557u:   PASS -> FAIL +6
  fi-pnv-d510:PASS -> FAIL +4
  fi-skl-6600u:   PASS -> FAIL +6
  fi-bxt-dsi: PASS -> FAIL +6
  fi-hsw-4770:PASS -> FAIL +6
  fi-cfl-guc: PASS -> FAIL +6
  fi-ivb-3770:PASS -> FAIL +6

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
  fi-hsw-peppy:   PASS -> FAIL +6
  fi-bdw-gvtdvm:  PASS -> FAIL +6
  fi-gdg-551: PASS -> FAIL +4
  fi-kbl-7500u:   PASS -> FAIL +6
  fi-snb-2600:PASS -> FAIL +4

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
  fi-kbl-7567u:   PASS -> FAIL +6
  fi-skl-6260u:   PASS -> FAIL +6
  fi-skl-6700k2:  PASS -> FAIL +6
  fi-skl-gvtdvm:  PASS -> FAIL +6
  fi-bxt-j4205:   PASS -> FAIL +6
  fi-kbl-7560u:   PASS -> FAIL +6
  fi-whl-u:   PASS -> FAIL +6
  fi-kbl-r:   PASS -> FAIL +6


 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
  fi-glk-j4005:   PASS -> FAIL (fdo#106211) +5
  fi-bsw-n3050:   PASS -> FAIL (fdo#106211) +1

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c-frame-sequence:
  fi-glk-dsi: PASS -> FAIL (fdo#106211) +5


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

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


== Participating hosts (44 -> 39) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4411 -> Patchwork_9494

  CI_DRM_4411: 3fd8031a8f5d378ebda63131f6b504c3c4a5eb93 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9494: 43533286914804b8dd5bc3d683945a5bce9be6e6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

435332869148 drm: crc: Introduce pre_crc_read function
39240b6ce9c5 Revert "drm: crc: Wait for a frame before returning from open()"
92d712d5c8bf drm/crc: Cleanup crtc_crc_open function
f1a6ac764e69 drm/i915/crc: implement get_crc_sources callback
29e0bbaabf60 drm/i915/crc: implement verify_crc_source callback
c75c0d05c696 drm/rcar-du/crc: Implement verify_crc_source callback
649d027b2b34 drm/amdgpu_dm/crc: Implement verify_crc_source callback
8993123ebcb1 drm/rockchip/crc: Implement verify_crc_source callback
d5dac505c466 drm: crc: Introduce get_crc_sources callback
2fe8786784e0 drm: crc: Introduce verify_crc_source callback

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Show who pinned the pages when a leak is hit

2018-07-02 Thread Chris Wilson
Currently, we emit a warning when freeing an object if we do so with the
pages still pinned (presumably as they are still in use somewhere). This
only tells us that there is a problem, but doesn't tell us anything
about the object or who might be pinning them and so provides no clue as
to track down the problem.

Let's try tracking everyone who pins the pages to see if we strike it
lucky and catch the culprit red handed.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105360
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Kconfig.debug |   1 +
 drivers/gpu/drm/i915/i915_gem.c|   5 +-
 drivers/gpu/drm/i915/i915_gem_object.c | 109 +
 drivers/gpu/drm/i915/i915_gem_object.h |  34 
 4 files changed, 148 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 9de8b1c51a5c..84052becb279 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -43,6 +43,7 @@ config DRM_I915_DEBUG_GEM
 bool "Insert extra checks into the GEM internals"
 default n
 depends on DRM_I915_WERROR
+select STACKDEPOT
 help
   Enable extra sanity checks (including BUGs) along the GEM driver
   paths that may slow the system down and if hit hang the machine.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8954db6ab083..e56240dc93f3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2459,6 +2459,7 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
 
+   untrack_i915_gem_object_pin_pages(obj);
 unlock:
mutex_unlock(&obj->mm.lock);
 }
@@ -4870,8 +4871,10 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
if (obj->ops->release)
obj->ops->release(obj);
 
-   if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
+   if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) {
+   show_i915_gem_object_pin_pages(obj);
atomic_set(&obj->mm.pages_pin_count, 0);
+   }
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
 
diff --git a/drivers/gpu/drm/i915/i915_gem_object.c 
b/drivers/gpu/drm/i915/i915_gem_object.c
index aab8cdd80e6d..e1f60e4e17ce 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/i915_gem_object.c
@@ -25,6 +25,115 @@
 #include "i915_drv.h"
 #include "i915_gem_object.h"
 
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+
+#include 
+
+#define STACKDEPTH 12
+
+void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+   unsigned long entries[STACKDEPTH];
+   struct stack_trace trace = {
+   .entries = entries,
+   .max_entries = ARRAY_SIZE(entries),
+   .skip = 1
+   };
+   unsigned long flags;
+   depot_stack_handle_t stack, *stacks;
+
+   save_stack_trace(&trace);
+   if (trace.nr_entries &&
+   trace.entries[trace.nr_entries - 1] == ULONG_MAX)
+   trace.nr_entries--;
+
+   stack = depot_save_stack(&trace, GFP_NOWAIT);
+   if (!stack)
+   return;
+
+   spin_lock_irqsave(&obj->mm.debug_lock, flags);
+   stacks = krealloc(obj->mm.debug_owners,
+ (obj->mm.debug_count + 1) * sizeof(*stacks),
+ GFP_NOWAIT);
+   if (stacks) {
+   stacks[obj->mm.debug_count++] = stack;
+   obj->mm.debug_owners = stacks;
+   }
+   spin_unlock_irqrestore(&obj->mm.debug_lock, flags);
+}
+
+void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+   depot_stack_handle_t *stacks;
+   unsigned long flags;
+
+   spin_lock_irqsave(&obj->mm.debug_lock, flags);
+   stacks = fetch_and_zero(&obj->mm.debug_owners);
+   obj->mm.debug_count = 0;
+   spin_unlock_irqrestore(&obj->mm.debug_lock, flags);
+
+   kfree(stacks);
+}
+
+static int cmphandle(const void *_a, const void *_b)
+{
+   const depot_stack_handle_t * const a = _a, * const b = _b;
+
+   if (*a < *b)
+   return -1;
+   else if (*a > *b)
+   return 1;
+   else
+   return 0;
+}
+
+void show_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+   unsigned long entries[STACKDEPTH];
+   depot_stack_handle_t *stacks;
+   unsigned long flags, count, i;
+   char *buf;
+
+   spin_lock_irqsave(&obj->mm.debug_lock, flags);
+   stacks = fetch_and_zero(&obj->mm.debug_owners);
+   count = fetch_and_zero(&obj->mm.debug_count);
+   spin_unlock_irqrestore(&obj->mm.debug_lock, flags);
+   if (!count)
+   return;
+
+   DRM_DEBUG_DRIVER("obj %p leaked pa

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active()

2018-07-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-07-02 12:34:51)
> > @@ -1921,6 +1914,8 @@ void i915_vma_move_to_active(struct i915_vma *vma,
> >   
> >   if (flags & EXEC_OBJECT_NEEDS_FENCE)
> >   i915_gem_active_set(&vma->last_fence, rq);
> > +
> > + export_fence(vma, rq, flags);
> 
> Don't care about new extra reservation object operations from the other 
> i915_move_to_active_callers?

No. Not filling the reservation_object is an underhand shortcut. It
should never be not correct to track the fences for an object. Doing it
in one place correctly, should prevent cheating.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/6] drm/i915: Move i915_vma_move_to_active() to i915_vma.c

2018-07-02 Thread Tvrtko Ursulin


On 29/06/2018 23:54, Chris Wilson wrote:

i915_vma_move_to_active() has grown beyond its execbuf origins, and
should take its rightful place in i915_vma.c as a method for i915_vma!

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h|  3 --
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 61 --
  drivers/gpu/drm/i915/i915_vma.c| 61 ++
  drivers/gpu/drm/i915/i915_vma.h|  4 ++
  4 files changed, 65 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd8f69a00e86..1c04872890d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3099,9 +3099,6 @@ i915_gem_obj_finish_shmem_access(struct 
drm_i915_gem_object *obj)
  }
  
  int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);

-int __must_check i915_vma_move_to_active(struct i915_vma *vma,
-struct i915_request *rq,
-unsigned int flags);
  int i915_gem_dumb_create(struct drm_file *file_priv,
 struct drm_device *dev,
 struct drm_mode_create_dumb *args);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 97136e4ce91d..3f0c612d42e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1868,67 +1868,6 @@ static bool i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
return true;
  }
  
-static void export_fence(struct i915_vma *vma,

-struct i915_request *rq,
-unsigned int flags)
-{
-   struct reservation_object *resv = vma->resv;
-
-   /*
-* Ignore errors from failing to allocate the new fence, we can't
-* handle an error right now. Worst case should be missed
-* synchronisation leading to rendering corruption.
-*/
-   reservation_object_lock(resv, NULL);
-   if (flags & EXEC_OBJECT_WRITE)
-   reservation_object_add_excl_fence(resv, &rq->fence);
-   else if (reservation_object_reserve_shared(resv) == 0)
-   reservation_object_add_shared_fence(resv, &rq->fence);
-   reservation_object_unlock(resv);
-}
-
-int i915_vma_move_to_active(struct i915_vma *vma,
-   struct i915_request *rq,
-   unsigned int flags)
-{
-   struct drm_i915_gem_object *obj = vma->obj;
-   const unsigned int idx = rq->engine->id;
-
-   lockdep_assert_held(&rq->i915->drm.struct_mutex);
-   GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
-
-   /*
-* Add a reference if we're newly entering the active list.
-* The order in which we add operations to the retirement queue is
-* vital here: mark_active adds to the start of the callback list,
-* such that subsequent callbacks are called first. Therefore we
-* add the active reference first and queue for it to be dropped
-* *last*.
-*/
-   if (!i915_vma_is_active(vma))
-   obj->active_count++;
-   i915_vma_set_active(vma, idx);
-   i915_gem_active_set(&vma->last_read[idx], rq);
-   list_move_tail(&vma->vm_link, &vma->vm->active_list);
-
-   obj->write_domain = 0;
-   if (flags & EXEC_OBJECT_WRITE) {
-   obj->write_domain = I915_GEM_DOMAIN_RENDER;
-
-   if (intel_fb_obj_invalidate(obj, ORIGIN_CS))
-   i915_gem_active_set(&obj->frontbuffer_write, rq);
-
-   obj->read_domains = 0;
-   }
-   obj->read_domains |= I915_GEM_GPU_DOMAINS;
-
-   if (flags & EXEC_OBJECT_NEEDS_FENCE)
-   i915_gem_active_set(&vma->last_fence, rq);
-
-   export_fence(vma, rq, flags);
-   return 0;
-}
-
  static int i915_reset_gen7_sol_offsets(struct i915_request *rq)
  {
u32 *cs;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d0e606e9b27a..7635c27e7e8b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -859,6 +859,67 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(&vma->obj->userfault_link);
  }
  
+static void export_fence(struct i915_vma *vma,

+struct i915_request *rq,
+unsigned int flags)
+{
+   struct reservation_object *resv = vma->resv;
+
+   /*
+* Ignore errors from failing to allocate the new fence, we can't
+* handle an error right now. Worst case should be missed
+* synchronisation leading to rendering corruption.
+*/
+   reservation_object_lock(resv, NULL);
+   if (flags & EXEC_OBJECT_WRITE)
+   reservation_object_add_excl_fence(resv, &rq->fence);
+   else if (reservation_object_reserve_shared(resv) == 0)
+   reser

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Start returning an error from i915_vma_move_to_active()

2018-07-02 Thread Tvrtko Ursulin


On 29/06/2018 23:54, Chris Wilson wrote:

Handling such a late error in request construction is tricky, but to
accommodate future patches which may allocate here, we potentially could
err. To handle the error after already adjusting global state to track
the new request, we must finish and submit the request. But we don't
want to use the request as not everything is being tracked by it, so we
opt to cancel the commands inside the request.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gvt/scheduler.c  |  6 -
  drivers/gpu/drm/i915/i915_drv.h   |  6 ++---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c| 25 +--
  drivers/gpu/drm/i915/i915_gem_render_state.c  |  2 +-
  drivers/gpu/drm/i915/selftests/huge_pages.c   |  9 +--
  .../drm/i915/selftests/i915_gem_coherency.c   |  4 +--
  .../gpu/drm/i915/selftests/i915_gem_context.c | 12 +++--
  .../gpu/drm/i915/selftests/i915_gem_object.c  |  7 +++---
  drivers/gpu/drm/i915/selftests/i915_request.c |  8 --
  .../gpu/drm/i915/selftests/intel_hangcheck.c  | 11 ++--
  drivers/gpu/drm/i915/selftests/intel_lrc.c| 11 ++--
  .../drm/i915/selftests/intel_workarounds.c|  5 +++-
  12 files changed, 78 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 928818f218f7..b0e566956b8d 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -476,7 +476,11 @@ static int prepare_shadow_batch_buffer(struct 
intel_vgpu_workload *workload)
i915_gem_obj_finish_shmem_access(bb->obj);
bb->accessing = false;
  
-			i915_vma_move_to_active(bb->vma, workload->req, 0);

+   ret = i915_vma_move_to_active(bb->vma,
+ workload->req,
+ 0);
+   if (ret)
+   goto err;
}
}
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ce7d06332884..cd8f69a00e86 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3099,9 +3099,9 @@ i915_gem_obj_finish_shmem_access(struct 
drm_i915_gem_object *obj)
  }
  
  int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);

-void i915_vma_move_to_active(struct i915_vma *vma,
-struct i915_request *rq,
-unsigned int flags);
+int __must_check i915_vma_move_to_active(struct i915_vma *vma,
+struct i915_request *rq,
+unsigned int flags);
  int i915_gem_dumb_create(struct drm_file *file_priv,
 struct drm_device *dev,
 struct drm_mode_create_dumb *args);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 91f20445147f..97136e4ce91d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1165,12 +1165,16 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
goto err_request;
  
  	GEM_BUG_ON(!reservation_object_test_signaled_rcu(batch->resv, true));

-   i915_vma_move_to_active(batch, rq, 0);
-   i915_vma_unpin(batch);
+   err = i915_vma_move_to_active(batch, rq, 0);
+   if (err)
+   goto skip_request;
  
-	i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);

+   err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
+   if (err)
+   goto skip_request;
  
  	rq->batch = batch;

+   i915_vma_unpin(batch);
  
  	cache->rq = rq;

cache->rq_cmd = cmd;
@@ -1179,6 +1183,8 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
/* Return with batch mapping (cmd) still pinned */
return 0;
  
+skip_request:

+   i915_request_skip(rq, err);
  err_request:
i915_request_add(rq);
  err_unpin:
@@ -1818,7 +1824,11 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
unsigned int flags = eb->flags[i];
struct i915_vma *vma = eb->vma[i];
  
-		i915_vma_move_to_active(vma, eb->request, flags);

+   err = i915_vma_move_to_active(vma, eb->request, flags);
+   if (unlikely(err)) {
+   i915_request_skip(eb->request, err);
+   return err;
+   }
  
  		__eb_unreserve_vma(vma, flags);

vma->exec_flags = NULL;
@@ -1877,9 +1887,9 @@ static void export_fence(struct i915_vma *vma,
reservation_object_unlock(resv);
  }
  
-void i915_vma_move_to_active(struct i915_vma *vma,

-struct i915_request *rq,
-unsigned int flags)
+int i915_vma_move_to_active(struct i915_vma *vma,
+

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Export i915_request_skip()

2018-07-02 Thread Tvrtko Ursulin


On 29/06/2018 23:54, Chris Wilson wrote:

In the next patch, we will want to start skipping requests on failing to
complete their payloads. So export the utility function current used to
make requests inoperable following a failed gpu reset.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 25 +++--
  drivers/gpu/drm/i915/i915_request.c | 21 +
  drivers/gpu/drm/i915/i915_request.h |  2 ++
  3 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8954db6ab083..2ff6251483ce 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3074,25 +3074,6 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
return err;
  }
  
-static void skip_request(struct i915_request *request)

-{
-   void *vaddr = request->ring->vaddr;
-   u32 head;
-
-   /* As this request likely depends on state from the lost
-* context, clear out all the user operations leaving the
-* breadcrumb at the end (so we get the fence notifications).
-*/
-   head = request->head;
-   if (request->postfix < head) {
-   memset(vaddr + head, 0, request->ring->size - head);
-   head = 0;
-   }
-   memset(vaddr + head, 0, request->postfix - head);
-
-   dma_fence_set_error(&request->fence, -EIO);
-}
-
  static void engine_skip_context(struct i915_request *request)
  {
struct intel_engine_cs *engine = request->engine;
@@ -3107,10 +3088,10 @@ static void engine_skip_context(struct i915_request 
*request)
  
  	list_for_each_entry_continue(request, &engine->timeline.requests, link)

if (request->gem_context == hung_ctx)
-   skip_request(request);
+   i915_request_skip(request, -EIO);
  
  	list_for_each_entry(request, &timeline->requests, link)

-   skip_request(request);
+   i915_request_skip(request, -EIO);
  
  	spin_unlock(&timeline->lock);

spin_unlock_irqrestore(&engine->timeline.lock, flags);
@@ -3153,7 +3134,7 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
  
  	if (stalled) {

i915_gem_context_mark_guilty(request->gem_context);
-   skip_request(request);
+   i915_request_skip(request, -EIO);
  
  		/* If this context is now banned, skip all pending requests. */

if (i915_gem_context_is_banned(request->gem_context))
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index a2f7e9358450..7ae08b68121e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1013,6 +1013,27 @@ i915_request_await_object(struct i915_request *to,
return ret;
  }
  
+void i915_request_skip(struct i915_request *rq, int error)

+{
+   void *vaddr = rq->ring->vaddr;
+   u32 head;
+
+   GEM_BUG_ON(!IS_ERR_VALUE((long)error));


This gets checked by dma_fence_set_error below but if you want to have 
it explicitly spelled out here OK.



+   dma_fence_set_error(&rq->fence, error);
+
+   /*
+* As this request likely depends on state from the lost
+* context, clear out all the user operations leaving the
+* breadcrumb at the end (so we get the fence notifications).
+*/
+   head = rq->infix;
+   if (rq->postfix < head) {
+   memset(vaddr + head, 0, rq->ring->size - head);
+   head = 0;
+   }
+   memset(vaddr + head, 0, rq->postfix - head);
+}
+
  /*
   * NB: This function is not allowed to fail. Doing so would mean the the
   * request is not being tracked for completion but the work itself is
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 7ee220ded9c9..a355a081485f 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -258,6 +258,8 @@ void i915_request_add(struct i915_request *rq);
  void __i915_request_submit(struct i915_request *request);
  void i915_request_submit(struct i915_request *request);
  
+void i915_request_skip(struct i915_request *request, int error);

+
  void __i915_request_unsubmit(struct i915_request *request);
  void i915_request_unsubmit(struct i915_request *request);
  



With sounds of grumbling for code movement with changes:

Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [Intel-gfx] [PATCH 1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active()

2018-07-02 Thread Tvrtko Ursulin


On 29/06/2018 23:54, Chris Wilson wrote:

Currently all callers are responsible for adding the vma to the active
timeline and then exporting its fence. Combine the two operations into
i915_vma_move_to_active() to move all the extra handling from the
callers to the single site.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c| 47 +--
  drivers/gpu/drm/i915/selftests/huge_pages.c   |  4 --
  .../drm/i915/selftests/i915_gem_coherency.c   |  4 --
  .../gpu/drm/i915/selftests/i915_gem_context.c |  4 --
  .../gpu/drm/i915/selftests/i915_gem_object.c  |  4 --
  5 files changed, 21 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c2dd9b4cdace..91f20445147f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1166,15 +1166,9 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
  
  	GEM_BUG_ON(!reservation_object_test_signaled_rcu(batch->resv, true));

i915_vma_move_to_active(batch, rq, 0);
-   reservation_object_lock(batch->resv, NULL);
-   reservation_object_add_excl_fence(batch->resv, &rq->fence);
-   reservation_object_unlock(batch->resv);
i915_vma_unpin(batch);
  
  	i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);

-   reservation_object_lock(vma->resv, NULL);
-   reservation_object_add_excl_fence(vma->resv, &rq->fence);
-   reservation_object_unlock(vma->resv);
  
  	rq->batch = batch;
  
@@ -1771,25 +1765,6 @@ static int eb_relocate(struct i915_execbuffer *eb)

return eb_relocate_slow(eb);
  }
  
-static void eb_export_fence(struct i915_vma *vma,

-   struct i915_request *rq,
-   unsigned int flags)
-{
-   struct reservation_object *resv = vma->resv;
-
-   /*
-* Ignore errors from failing to allocate the new fence, we can't
-* handle an error right now. Worst case should be missed
-* synchronisation leading to rendering corruption.
-*/
-   reservation_object_lock(resv, NULL);
-   if (flags & EXEC_OBJECT_WRITE)
-   reservation_object_add_excl_fence(resv, &rq->fence);
-   else if (reservation_object_reserve_shared(resv) == 0)
-   reservation_object_add_shared_fence(resv, &rq->fence);
-   reservation_object_unlock(resv);
-}
-
  static int eb_move_to_gpu(struct i915_execbuffer *eb)
  {
const unsigned int count = eb->buffer_count;
@@ -1844,7 +1819,6 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
struct i915_vma *vma = eb->vma[i];
  
  		i915_vma_move_to_active(vma, eb->request, flags);

-   eb_export_fence(vma, eb->request, flags);
  
  		__eb_unreserve_vma(vma, flags);

vma->exec_flags = NULL;
@@ -1884,6 +1858,25 @@ static bool i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
return true;
  }
  
+static void export_fence(struct i915_vma *vma,

+struct i915_request *rq,
+unsigned int flags)
+{
+   struct reservation_object *resv = vma->resv;
+
+   /*
+* Ignore errors from failing to allocate the new fence, we can't
+* handle an error right now. Worst case should be missed
+* synchronisation leading to rendering corruption.
+*/
+   reservation_object_lock(resv, NULL);
+   if (flags & EXEC_OBJECT_WRITE)
+   reservation_object_add_excl_fence(resv, &rq->fence);
+   else if (reservation_object_reserve_shared(resv) == 0)
+   reservation_object_add_shared_fence(resv, &rq->fence);
+   reservation_object_unlock(resv);
+}
+
  void i915_vma_move_to_active(struct i915_vma *vma,
 struct i915_request *rq,
 unsigned int flags)
@@ -1921,6 +1914,8 @@ void i915_vma_move_to_active(struct i915_vma *vma,
  
  	if (flags & EXEC_OBJECT_NEEDS_FENCE)

i915_gem_active_set(&vma->last_fence, rq);
+
+   export_fence(vma, rq, flags);


Don't care about new extra reservation object operations from the other 
i915_move_to_active_callers?


Regards,

Tvrtko


  }
  
  static int i915_reset_gen7_sol_offsets(struct i915_request *rq)

diff --git a/drivers/gpu/drm/i915/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/selftests/huge_pages.c
index b5e87fcdcdae..358fc81f6c99 100644
--- a/drivers/gpu/drm/i915/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/selftests/huge_pages.c
@@ -998,10 +998,6 @@ static int gpu_write(struct i915_vma *vma,
  
  	i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
  
-	reservation_object_lock(vma->resv, NULL);

-   reservation_object_add_excl_fence(vma->resv, &rq->fence);
-   reservation_object_unlock(vma->resv);
-
  err_request:
i915_request_add(rq);
  
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c b/drivers/gpu/drm/i

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: expect setting bad source to fail

2018-07-02 Thread Maarten Lankhorst
Op 02-07-18 om 13:16 schreef Mahesh Kumar:
> Now crc-core framework verifies the source string passed by the user.
> So setting bad-source will fail. Expect file write to fail in bad-source
> subtest of kms_pipe_crc_basic.
>
> Signed-off-by: Mahesh Kumar 
> ---
>  tests/kms_pipe_crc_basic.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
> index 235fdc38..2d4dfee8 100644
> --- a/tests/kms_pipe_crc_basic.c
> +++ b/tests/kms_pipe_crc_basic.c
> @@ -48,8 +48,7 @@ static struct {
>  
>  static void test_bad_source(data_t *data)
>  {
> - igt_assert(igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo"));
> - igt_assert(openat(data->debugfs, "crtc-0/crc/data", O_WRONLY) == -1);
> + igt_assert(!igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo"));
>  }
>  
>  #define N_CRCS   3

New behavior makes more sense.

Reviewed-by: Maarten Lankhorst 

Do you have igt commit rights?

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


[Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: expect setting bad source to fail

2018-07-02 Thread Mahesh Kumar
Now crc-core framework verifies the source string passed by the user.
So setting bad-source will fail. Expect file write to fail in bad-source
subtest of kms_pipe_crc_basic.

Signed-off-by: Mahesh Kumar 
---
 tests/kms_pipe_crc_basic.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index 235fdc38..2d4dfee8 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -48,8 +48,7 @@ static struct {
 
 static void test_bad_source(data_t *data)
 {
-   igt_assert(igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo"));
-   igt_assert(openat(data->debugfs, "crtc-0/crc/data", O_WRONLY) == -1);
+   igt_assert(!igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo"));
 }
 
 #define N_CRCS 3
-- 
2.16.2

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


[Intel-gfx] [PATCH 04/10] drm/amdgpu_dm/crc: Implement verify_crc_source callback

2018-07-02 Thread Mahesh Kumar
This patch implements "verify_crc_source" callback function for
AMD drm driver.

Signed-off-by: Mahesh Kumar 
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  4 
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 16 
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 66bd3cc3e387..dd97cbca0527 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2563,6 +2563,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = 
{
.atomic_duplicate_state = dm_crtc_duplicate_state,
.atomic_destroy_state = dm_crtc_destroy_state,
.set_crc_source = amdgpu_dm_crtc_set_crc_source,
+   .verify_crc_source = amdgpu_dm_crtc_verify_crc_source,
.enable_vblank = dm_enable_vblank,
.disable_vblank = dm_disable_vblank,
 };
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index a29dc35954c9..e43ed064dc46 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -260,9 +260,13 @@ amdgpu_dm_remove_sink_from_freesync_module(struct 
drm_connector *connector);
 #ifdef CONFIG_DEBUG_FS
 int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
  size_t *values_cnt);
+int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *src_name,
+size_t *values_cnt);
 void amdgpu_dm_crtc_handle_crc_irq(struct drm_crtc *crtc);
 #else
 #define amdgpu_dm_crtc_set_crc_source NULL
+#define amdgpu_dm_crtc_verify_crc_source NULL
 #define amdgpu_dm_crtc_handle_crc_irq(x)
 #endif
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 52f2c01349e3..dfcca594d52a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -46,6 +46,22 @@ static enum amdgpu_dm_pipe_crc_source 
dm_parse_crc_source(const char *source)
return AMDGPU_DM_PIPE_CRC_SOURCE_INVALID;
 }
 
+int
+amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const char *src_name,
+size_t *values_cnt)
+{
+   enum amdgpu_dm_pipe_crc_source source = dm_parse_crc_source(src_name);
+
+   if (source < 0) {
+   DRM_DEBUG_DRIVER("Unknown CRC source %s for CRTC%d\n",
+src_name, crtc->index);
+   return -EINVAL;
+   }
+
+   *values_cnt = 3;
+   return 0;
+}
+
 int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
   size_t *values_cnt)
 {
-- 
2.16.2

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


[Intel-gfx] [PATCH 07/10] drm/i915/crc: implement get_crc_sources callback

2018-07-02 Thread Mahesh Kumar
This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.

Changes since V1:
 - Return array of crc sources

Signed-off-by: Mahesh Kumar 
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c  | 1 +
 drivers/gpu/drm/i915/intel_drv.h  | 3 +++
 drivers/gpu/drm/i915/intel_pipe_crc.c | 7 +++
 3 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 977ee4c7ef7b..6918c5127473 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12894,6 +12894,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_destroy_state = intel_crtc_destroy_state,
.set_crc_source = intel_crtc_set_crc_source,
.verify_crc_source = intel_crtc_verify_crc_source,
+   .get_crc_sources = intel_crtc_get_crc_sources,
 };
 
 struct wait_rps_boost {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 764b53dfe7de..99e3b6477d39 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2158,11 +2158,14 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, 
const char *source_name,
  size_t *values_cnt);
 int intel_crtc_verify_crc_source(struct drm_crtc *crtc,
 const char *source_name, size_t *values_cnt);
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count);
 void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc);
 void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc);
 #else
 #define intel_crtc_set_crc_source NULL
 #define intel_crtc_verify_crc_source NULL
+#define intel_crtc_get_crc_sources NULL
 static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc)
 {
 }
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index a37521380f94..1dffc346f1bc 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -1001,6 +1001,13 @@ intel_is_valid_crc_source(struct drm_i915_private 
*dev_priv,
return ivb_crc_source_valid(dev_priv, source);
 }
 
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count)
+{
+   *count = ARRAY_SIZE(pipe_crc_sources);
+   return pipe_crc_sources;
+}
+
 int intel_crtc_verify_crc_source(struct drm_crtc *crtc, const char 
*source_name,
 size_t *values_cnt)
 {
-- 
2.16.2

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


  1   2   >