[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)
URL   : https://patchwork.freedesktop.org/series/56606/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
08011e2e164e drm/i915: Add P010, P012, P016 plane control definitions
f9b305df8580 drm/i915: Preparations for enabling P010, P012, P016 formats
b3cde057e621 drm/i915: Enable P010, P012, P016 formats for primary and sprite 
planes
-:22: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#22: FILE: drivers/gpu/drm/i915/intel_sprite.c:1835:
+static const uint32_t glk_planar_formats[] = {

total: 0 errors, 0 warnings, 1 checks, 40 lines checked
89567e7b31f0 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
-:48: WARNING:LONG_LINE: line over 100 characters
#48: FILE: drivers/gpu/drm/drm_fourcc.c:229:
+   { .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:49: WARNING:LONG_LINE: line over 100 characters
#49: FILE: drivers/gpu/drm/drm_fourcc.c:230:
+   { .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:50: WARNING:LONG_LINE: line over 100 characters
#50: FILE: drivers/gpu/drm/drm_fourcc.c:231:
+   { .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:51: WARNING:LONG_LINE: line over 100 characters
#51: FILE: drivers/gpu/drm/drm_fourcc.c:232:
+   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:52: WARNING:LONG_LINE: line over 100 characters
#52: FILE: drivers/gpu/drm/drm_fourcc.c:233:
+   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:53: WARNING:LONG_LINE: line over 100 characters
#53: FILE: drivers/gpu/drm/drm_fourcc.c:234:
+   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:66: WARNING:LONG_LINE_COMMENT: line over 100 characters
#66: FILE: include/uapi/drm/drm_fourcc.h:154:
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0] 
X:Y:Cb:Cr 8:8:8:8 little endian */

-:72: WARNING:LONG_LINE_COMMENT: line over 100 characters
#72: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */

-:73: WARNING:LONG_LINE_COMMENT: line over 100 characters
#73: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */

-:74: WARNING:LONG_LINE_COMMENT: line over 100 characters
#74: FILE: include/uapi/drm/drm_fourcc.h:162:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0] 
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */

-:80: WARNING:LONG_LINE_COMMENT: line over 100 characters
#80: FILE: include/uapi/drm/drm_fourcc.h:168:
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0] 
X:V:Y:U 2:10:10:10 little endian */

-:81: WARNING:LONG_LINE_COMMENT: line over 100 characters
#81: FILE: include/uapi/drm/drm_fourcc.h:169:
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0] 
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */

-:82: WARNING:LONG_LINE_COMMENT: line over 100 characters
#82: FILE: include/uapi/drm/drm_fourcc.h:170:
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [63:0] 
X:V:Y:U 16:16:16:16 little endian */

total: 0 errors, 13 warnings, 0 checks, 36 lines checked
d7e8efaf83b4 drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control 
definitions
5c93c9eca237 drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:75: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#75: FILE: drivers/gpu/drm/i915/intel_sprite.c:1819:
+static const uint32_t icl_plane_formats[] = {

-:103: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#103: FILE: drivers/gpu/drm/i915/intel_sprite.c:1875:
+static const uint32_t icl_planar_formats[] = {

total: 0 errors, 1 warnings, 2 checks, 138 lines checked

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)
URL   : https://patchwork.freedesktop.org/series/56606/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add P010, P012, P016 plane control definitions
Okay!

Commit: drm/i915: Preparations for enabling P010, P012, P016 formats
-O:drivers/gpu/drm/i915/intel_display.c:13915:21: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_display.c:13915:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_display.c:13930:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_display.c:13930:21: warning: expression using 
sizeof(void)

Commit: drm/i915: Enable P010, P012, P016 formats for primary and sprite planes
Okay!

Commit: drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
Okay!

Commit: drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions
Okay!

Commit: drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
Okay!

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)
URL   : https://patchwork.freedesktop.org/series/56606/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693 -> Patchwork_12355


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   PASS -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  * igt@kms_psr@primary_mmap_gtt:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +27

  
 Possible fixes 

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380


Participating hosts (42 -> 34)
--

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-pnv-d510 fi-icl-y fi-bsw-kefka fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5693 -> Patchwork_12355

  CI_DRM_5693: 87cb56b5fae5e4a1cb77539a9834348605630773 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4869: a958d3f60b7718151fd0bafcdd1e4874262f51b8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12355: 5c93c9eca237a3425b5d8e57e116a59257297294 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5c93c9eca237 drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
d7e8efaf83b4 drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control 
definitions
89567e7b31f0 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
b3cde057e621 drm/i915: Enable P010, P012, P016 formats for primary and sprite 
planes
f9b305df8580 drm/i915: Preparations for enabling P010, P012, P016 formats
08011e2e164e drm/i915: Add P010, P012, P016 plane control definitions

== Logs ==

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

Re: [Intel-gfx] [PATCH 14/38] drm/i915: Introduce the i915_user_extension_method

2019-03-04 Thread Tvrtko Ursulin


On 01/03/2019 18:57, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-03-01 15:39:13)


On 01/03/2019 14:03, Chris Wilson wrote:

+int i915_user_extensions(struct i915_user_extension __user *ext,
+  const i915_user_extension_fn *tbl,
+  unsigned long count,
+  void *data)
+{
+ unsigned int stackdepth = 512;
+
+ while (ext) {
+ int err;
+ u64 x;
+
+ if (!stackdepth--) /* recursion vs useful flexibility */
+ return -EINVAL;


I don't get this. What stack? Did you mean "static unsigned int
stackdepth" in case someone puts i915_user_extension into the extension
table? Or just a limit on number of chained extensions? But you are not
processing the recursively here.


It's iterative recursion :)

I still think of this loop in terms of its simple tail recursion.

And if we need to individual levels for unwind, that is a manual stack.

Okay..

One thought I had - if unwind is too unwieldy, could we mandate each 
user extension user has an additional output field in the embedding 
struct which would hold the last processed extension id?


This way the state of the object would be less undefined after failure. 
Userspace would be able to tell how far in the extension chain i915 
managed to get to.


Regards,

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

Re: [Intel-gfx] [PATCH 16/38] drm/i915: Introduce a context barrier callback

2019-03-04 Thread Tvrtko Ursulin


On 01/03/2019 19:03, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-03-01 16:12:33)


On 01/03/2019 14:03, Chris Wilson wrote:

+ counter = 0;
+ err = context_barrier_task(ctx, 0, mock_barrier_task, &counter);
+ if (err) {
+ pr_err("Failed at line %d, err=%d\n", __LINE__, err);
+ goto out;
+ }
+ if (counter == 0) {
+ pr_err("Did not retire immediately with 0 engines\n");
+ err = -EINVAL;
+ goto out;
+ }
+
+ counter = 0;
+ err = context_barrier_task(ctx, -1, mock_barrier_task, &counter);
+ if (err) {
+ pr_err("Failed at line %d, err=%d\n", __LINE__, err);
+ goto out;
+ }
+ if (counter == 0) {
+ pr_err("Did not retire immediately for all inactive engines\n");


Why would this one retire immediately? It will send requests down the
pipe, no? So don't you actually need to wait for the tracker to be
signalled and that counter == num_engines?


Nothing has used the context at this point, so we don't emit a request
on any engine, and the barrier can be immediately executed.


Yep, that it uses ctx->active_engines slipped my mind.


+ err = -EINVAL;
+ goto out;
+ }
+
+ rq = ERR_PTR(-ENODEV);
+ with_intel_runtime_pm(i915, wakeref)
+ rq = i915_request_alloc(i915->engine[RCS], ctx);
+ if (IS_ERR(rq)) {
+ pr_err("Request allocation failed!\n");
+ goto out;
+ }
+ i915_request_add(rq);


Doesn't this need to go under the wakeref as well?


No, we only need the wakeref to start (that's only to avoid blocking
inside request_alloc --- yeah, that's not exactly how it works, we'll be
back later to fix that!). The request then carries the GT wakeref with it.


+ GEM_BUG_ON(list_empty(&ctx->active_engines));
+
+ counter = 0;
+ context_barrier_inject_fault = BIT(RCS);
+ err = context_barrier_task(ctx, -1, mock_barrier_task, &counter);
+ context_barrier_inject_fault = 0;
+ if (err == -ENXIO)
+ err = 0;
+ else
+ pr_err("Did not hit fault injection!\n");
+ if (counter != 0) {
+ pr_err("Invoked callback on error!\n");
+ err = -EIO;
+ }
+ if (err)
+ goto out;
+
+ counter = 0;
+ err = context_barrier_task(ctx, -1, mock_barrier_task, &counter);
+ if (err) {
+ pr_err("Failed at line %d, err=%d\n", __LINE__, err);
+ goto out;
+ }
+ mock_device_flush(i915);
+ if (counter == 0) {
+ pr_err("Did not retire on each active engines\n");
+ err = -EINVAL;
+ goto out;
+ }


This one is inline with my understanding, and the context_barrier_task
arguments are the same as the one above.. hm.. I am confused.


This time it is active, so we actually have to wait as the barrier waits
for the GPU before firing.


Yep.

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 18/38] drm/i915: Extend CONTEXT_CREATE to set parameters upon construction

2019-03-04 Thread Tvrtko Ursulin


On 01/03/2019 19:10, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-03-01 16:36:45)


On 01/03/2019 14:03, Chris Wilson wrote:

It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be applied to the newly constructed
context.

v2: Make a local copy of user setparam (Tvrtko)
v3: Use flags to detect availability of extension interface


Looks good to me.

Why have you changed to use flags and not just check the extension field
being non-null?


Hmm. I was thinking about how new userspace would use it on an old kernel.
As the extension is in a new bit of the extension struct that won't be
passed to the old ioctl, and so it would create a context and not report
any error despite not processing the extensions (userspace would be none
the wiser that the context was invalid). So a simple answer was to use
the flags field to indicate that we want the extension processed; the
old kernel would reject the ioctl due to pad!=0, a new kernel will be
happy. New userspace on old kernel can then fallback gracefully.

+uint32_t
+brw_clone_hw_context(struct brw_bufmgr *bufmgr, uint32_t ctx_id)
+{
+   struct drm_i915_gem_context_create_ext_clone ext_clone = {
+  .base = { I915_CONTEXT_CREATE_EXT_CLONE },
+  .clone = ctx_id,
+  .flags = ~I915_CONTEXT_CLONE_UNKNOWN,
+   };
+   struct drm_i915_gem_context_create_ext arg = {
+  .flags = I915_CONTEXT_CREATE_USE_EXTENSIONS,
+  .extensions = (uintptr_t)&ext_clone
+   };
+   if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, &arg) == 0)
+  return arg.ctx_id;
+
+   return __brw_clone_hw_context(bufmgr, ctx_id);
+}


Yeah, makes sense.

Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH v1 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread Andy Shevchenko
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/selftests/test-drm_mm.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c
index fbed2c90fd51..d1206aef26af 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1615,7 +1615,7 @@ static int igt_topdown(void *ignored)
DRM_RND_STATE(prng, random_seed);
const unsigned int count = 8192;
unsigned int size;
-   unsigned long *bitmap = NULL;
+   unsigned long *bitmap;
struct drm_mm mm;
struct drm_mm_node *nodes, *node, *next;
unsigned int *order, n, m, o = 0;
@@ -1631,8 +1631,7 @@ static int igt_topdown(void *ignored)
if (!nodes)
goto err;
 
-   bitmap = kcalloc(count / BITS_PER_LONG, sizeof(unsigned long),
-GFP_KERNEL);
+   bitmap = bitmap_zalloc(count, GFP_KERNEL);
if (!bitmap)
goto err_nodes;
 
@@ -1717,7 +1716,7 @@ static int igt_topdown(void *ignored)
drm_mm_takedown(&mm);
kfree(order);
 err_bitmap:
-   kfree(bitmap);
+   bitmap_free(bitmap);
 err_nodes:
vfree(nodes);
 err:
@@ -1745,8 +1744,7 @@ static int igt_bottomup(void *ignored)
if (!nodes)
goto err;
 
-   bitmap = kcalloc(count / BITS_PER_LONG, sizeof(unsigned long),
-GFP_KERNEL);
+   bitmap = bitmap_zcalloc(count, GFP_KERNEL);
if (!bitmap)
goto err_nodes;
 
@@ -1818,7 +1816,7 @@ static int igt_bottomup(void *ignored)
drm_mm_takedown(&mm);
kfree(order);
 err_bitmap:
-   kfree(bitmap);
+   bitmap_free(bitmap);
 err_nodes:
vfree(nodes);
 err:
-- 
2.20.1

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

[Intel-gfx] [PATCH v1 2/2] drm: i915: Switch to bitmap_zalloc()

2019-03-04 Thread Andy Shevchenko
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/i915/i915_gem.c   | 2 +-
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
 drivers/gpu/drm/i915/i915_gem_tiling.c| 6 +++---
 drivers/gpu/drm/i915/selftests/intel_uncore.c | 5 ++---
 4 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6728ea5c71d4..0d96520cfdb3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4410,7 +4410,7 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(i915, obj->base.size);
 
-   kfree(obj->bit_17);
+   bitmap_free(obj->bit_17);
i915_gem_object_free(obj);
 
GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index e037e94792f3..1f880e5b79b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -790,8 +790,7 @@ i915_gem_object_save_bit_17_swizzle(struct 
drm_i915_gem_object *obj,
int i;
 
if (obj->bit_17 == NULL) {
-   obj->bit_17 = kcalloc(BITS_TO_LONGS(page_count),
- sizeof(long), GFP_KERNEL);
+   obj->bit_17 = bitmap_zalloc(page_count, GFP_KERNEL);
if (obj->bit_17 == NULL) {
DRM_ERROR("Failed to allocate memory for bit 17 "
  "record\n");
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 16cc9ddbce34..a9b5329dae3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -301,11 +301,11 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
*obj,
/* Try to preallocate memory required to save swizzling on put-pages */
if (i915_gem_object_needs_bit17_swizzle(obj)) {
if (!obj->bit_17) {
-   obj->bit_17 = kcalloc(BITS_TO_LONGS(obj->base.size >> 
PAGE_SHIFT),
- sizeof(long), GFP_KERNEL);
+   obj->bit_17 = bitmap_zalloc(obj->base.size >> 
PAGE_SHIFT,
+   GFP_KERNEL);
}
} else {
-   kfree(obj->bit_17);
+   bitmap_free(obj->bit_17);
obj->bit_17 = NULL;
}
 
diff --git a/drivers/gpu/drm/i915/selftests/intel_uncore.c 
b/drivers/gpu/drm/i915/selftests/intel_uncore.c
index 81d9d31042a9..600167ebb303 100644
--- a/drivers/gpu/drm/i915/selftests/intel_uncore.c
+++ b/drivers/gpu/drm/i915/selftests/intel_uncore.c
@@ -137,8 +137,7 @@ static int intel_uncore_check_forcewake_domains(struct 
drm_i915_private *dev_pri
if (!IS_ENABLED(CONFIG_DRM_I915_SELFTEST_BROKEN))
return 0;
 
-   valid = kcalloc(BITS_TO_LONGS(FW_RANGE), sizeof(*valid),
-   GFP_KERNEL);
+   valid = bitmap_zalloc(FW_RANGE, GFP_KERNEL);
if (!valid)
return -ENOMEM;
 
@@ -173,7 +172,7 @@ static int intel_uncore_check_forcewake_domains(struct 
drm_i915_private *dev_pri
}
}
 
-   kfree(valid);
+   bitmap_free(valid);
return err;
 }
 
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 14/38] drm/i915: Introduce the i915_user_extension_method

2019-03-04 Thread Chris Wilson
Quoting Tvrtko Ursulin (2019-03-04 08:54:10)
> 
> On 01/03/2019 18:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-01 15:39:13)
> >>
> >> On 01/03/2019 14:03, Chris Wilson wrote:
> >>> +int i915_user_extensions(struct i915_user_extension __user *ext,
> >>> +  const i915_user_extension_fn *tbl,
> >>> +  unsigned long count,
> >>> +  void *data)
> >>> +{
> >>> + unsigned int stackdepth = 512;
> >>> +
> >>> + while (ext) {
> >>> + int err;
> >>> + u64 x;
> >>> +
> >>> + if (!stackdepth--) /* recursion vs useful flexibility */
> >>> + return -EINVAL;
> >>
> >> I don't get this. What stack? Did you mean "static unsigned int
> >> stackdepth" in case someone puts i915_user_extension into the extension
> >> table? Or just a limit on number of chained extensions? But you are not
> >> processing the recursively here.
> > 
> > It's iterative recursion :)
> > 
> > I still think of this loop in terms of its simple tail recursion.
> > 
> > And if we need to individual levels for unwind, that is a manual stack.
> Okay..
> 
> One thought I had - if unwind is too unwieldy, could we mandate each 
> user extension user has an additional output field in the embedding 
> struct which would hold the last processed extension id?

id? I guess we could do depth, though I guess pointer is more practical.
I don't think you mean ext.name as that we expect to repeat a few times.
 
> This way the state of the object would be less undefined after failure. 
> Userspace would be able to tell how far in the extension chain i915 
> managed to get to.

But I'm not convinced how practical that is. The answer is pretty much
always -EINVAL (anything else is much less ambiguous) and even then you
have no idea which field tripped EINVAL or why?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v1,1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread Patchwork
== Series Details ==

Series: series starting with [v1,1/2] drm/selftests/mm: Switch to 
bitmap_zalloc()
URL   : https://patchwork.freedesktop.org/series/57506/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/selftests/test-drm_mm.o
drivers/gpu/drm/selftests/test-drm_mm.c: In function ‘igt_bottomup’:
drivers/gpu/drm/selftests/test-drm_mm.c:1747:11: error: implicit declaration of 
function ‘bitmap_zcalloc’; did you mean ‘bitmap_zalloc’? 
[-Werror=implicit-function-declaration]
  bitmap = bitmap_zcalloc(count, GFP_KERNEL);
   ^~
   bitmap_zalloc
drivers/gpu/drm/selftests/test-drm_mm.c:1747:9: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
  bitmap = bitmap_zcalloc(count, GFP_KERNEL);
 ^
cc1: some warnings being treated as errors
scripts/Makefile.build:282: recipe for target 
'drivers/gpu/drm/selftests/test-drm_mm.o' failed
make[4]: *** [drivers/gpu/drm/selftests/test-drm_mm.o] Error 1
scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm/selftests' failed
make[3]: *** [drivers/gpu/drm/selftests] Error 2
scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:492: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1043: 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 v2 2/2] drm: i915: Switch to bitmap_zalloc()

2019-03-04 Thread Andy Shevchenko
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/i915/i915_gem.c   | 2 +-
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
 drivers/gpu/drm/i915/i915_gem_tiling.c| 6 +++---
 drivers/gpu/drm/i915/selftests/intel_uncore.c | 5 ++---
 4 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6728ea5c71d4..0d96520cfdb3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4410,7 +4410,7 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(i915, obj->base.size);
 
-   kfree(obj->bit_17);
+   bitmap_free(obj->bit_17);
i915_gem_object_free(obj);
 
GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index e037e94792f3..1f880e5b79b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -790,8 +790,7 @@ i915_gem_object_save_bit_17_swizzle(struct 
drm_i915_gem_object *obj,
int i;
 
if (obj->bit_17 == NULL) {
-   obj->bit_17 = kcalloc(BITS_TO_LONGS(page_count),
- sizeof(long), GFP_KERNEL);
+   obj->bit_17 = bitmap_zalloc(page_count, GFP_KERNEL);
if (obj->bit_17 == NULL) {
DRM_ERROR("Failed to allocate memory for bit 17 "
  "record\n");
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 16cc9ddbce34..a9b5329dae3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -301,11 +301,11 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
*obj,
/* Try to preallocate memory required to save swizzling on put-pages */
if (i915_gem_object_needs_bit17_swizzle(obj)) {
if (!obj->bit_17) {
-   obj->bit_17 = kcalloc(BITS_TO_LONGS(obj->base.size >> 
PAGE_SHIFT),
- sizeof(long), GFP_KERNEL);
+   obj->bit_17 = bitmap_zalloc(obj->base.size >> 
PAGE_SHIFT,
+   GFP_KERNEL);
}
} else {
-   kfree(obj->bit_17);
+   bitmap_free(obj->bit_17);
obj->bit_17 = NULL;
}
 
diff --git a/drivers/gpu/drm/i915/selftests/intel_uncore.c 
b/drivers/gpu/drm/i915/selftests/intel_uncore.c
index 81d9d31042a9..600167ebb303 100644
--- a/drivers/gpu/drm/i915/selftests/intel_uncore.c
+++ b/drivers/gpu/drm/i915/selftests/intel_uncore.c
@@ -137,8 +137,7 @@ static int intel_uncore_check_forcewake_domains(struct 
drm_i915_private *dev_pri
if (!IS_ENABLED(CONFIG_DRM_I915_SELFTEST_BROKEN))
return 0;
 
-   valid = kcalloc(BITS_TO_LONGS(FW_RANGE), sizeof(*valid),
-   GFP_KERNEL);
+   valid = bitmap_zalloc(FW_RANGE, GFP_KERNEL);
if (!valid)
return -ENOMEM;
 
@@ -173,7 +172,7 @@ static int intel_uncore_check_forcewake_domains(struct 
drm_i915_private *dev_pri
}
}
 
-   kfree(valid);
+   bitmap_free(valid);
return err;
 }
 
-- 
2.20.1

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

[Intel-gfx] [PATCH v2 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread Andy Shevchenko
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/selftests/test-drm_mm.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c
index fbed2c90fd51..286a0eeefcb6 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1615,7 +1615,7 @@ static int igt_topdown(void *ignored)
DRM_RND_STATE(prng, random_seed);
const unsigned int count = 8192;
unsigned int size;
-   unsigned long *bitmap = NULL;
+   unsigned long *bitmap;
struct drm_mm mm;
struct drm_mm_node *nodes, *node, *next;
unsigned int *order, n, m, o = 0;
@@ -1631,8 +1631,7 @@ static int igt_topdown(void *ignored)
if (!nodes)
goto err;
 
-   bitmap = kcalloc(count / BITS_PER_LONG, sizeof(unsigned long),
-GFP_KERNEL);
+   bitmap = bitmap_zalloc(count, GFP_KERNEL);
if (!bitmap)
goto err_nodes;
 
@@ -1717,7 +1716,7 @@ static int igt_topdown(void *ignored)
drm_mm_takedown(&mm);
kfree(order);
 err_bitmap:
-   kfree(bitmap);
+   bitmap_free(bitmap);
 err_nodes:
vfree(nodes);
 err:
@@ -1745,8 +1744,7 @@ static int igt_bottomup(void *ignored)
if (!nodes)
goto err;
 
-   bitmap = kcalloc(count / BITS_PER_LONG, sizeof(unsigned long),
-GFP_KERNEL);
+   bitmap = bitmap_zalloc(count, GFP_KERNEL);
if (!bitmap)
goto err_nodes;
 
@@ -1818,7 +1816,7 @@ static int igt_bottomup(void *ignored)
drm_mm_takedown(&mm);
kfree(order);
 err_bitmap:
-   kfree(bitmap);
+   bitmap_free(bitmap);
 err_nodes:
vfree(nodes);
 err:
-- 
2.20.1

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/selftests/mm: Switch to 
bitmap_zalloc()
URL   : https://patchwork.freedesktop.org/series/57507/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/selftests/mm: Switch to bitmap_zalloc()
-./include/linux/slab.h:664:13: error: not a function 
-./include/linux/slab.h:664:13: error: undefined identifier 
'__builtin_mul_overflow'
-./include/linux/slab.h:664:13: warning: call with no type!

Commit: drm: i915: Switch to bitmap_zalloc()
-./include/linux/slab.h:664:13: error: undefined identifier 
'__builtin_mul_overflow'
-./include/linux/slab.h:664:13: error: undefined identifier 
'__builtin_mul_overflow'
-./include/linux/slab.h:664:13: error: undefined identifier 
'__builtin_mul_overflow'
-./include/linux/slab.h:664:13: warning: call with no type!
-./include/linux/slab.h:664:13: warning: call with no type!

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

Re: [Intel-gfx] [PATCH 14/38] drm/i915: Introduce the i915_user_extension_method

2019-03-04 Thread Tvrtko Ursulin


On 04/03/2019 09:04, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-03-04 08:54:10)


On 01/03/2019 18:57, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-03-01 15:39:13)


On 01/03/2019 14:03, Chris Wilson wrote:

+int i915_user_extensions(struct i915_user_extension __user *ext,
+  const i915_user_extension_fn *tbl,
+  unsigned long count,
+  void *data)
+{
+ unsigned int stackdepth = 512;
+
+ while (ext) {
+ int err;
+ u64 x;
+
+ if (!stackdepth--) /* recursion vs useful flexibility */
+ return -EINVAL;


I don't get this. What stack? Did you mean "static unsigned int
stackdepth" in case someone puts i915_user_extension into the extension
table? Or just a limit on number of chained extensions? But you are not
processing the recursively here.


It's iterative recursion :)

I still think of this loop in terms of its simple tail recursion.

And if we need to individual levels for unwind, that is a manual stack.

Okay..

One thought I had - if unwind is too unwieldy, could we mandate each
user extension user has an additional output field in the embedding
struct which would hold the last processed extension id?


id? I guess we could do depth, though I guess pointer is more practical.
I don't think you mean ext.name as that we expect to repeat a few times.


Pointer yes, I started with a pointer but then for some reason wrote id, 
where I meant name.



This way the state of the object would be less undefined after failure.
Userspace would be able to tell how far in the extension chain i915
managed to get to.


But I'm not convinced how practical that is. The answer is pretty much
always -EINVAL (anything else is much less ambiguous) and even then you
have no idea which field tripped EINVAL or why?


Which field tripped -EINVAL is why is always true.

I am not 100% convinced myself, just worry about usability. But I don't 
have an usecase at the moment which would be practically helped with 
knowing which extension failed. In all cases I can think of it's a 
programming error ie. should be caught during development and not happen 
in production.


Regards,

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

Re: [Intel-gfx] [PATCH v2 2/2] drm: i915: Switch to bitmap_zalloc()

2019-03-04 Thread Chris Wilson
Quoting Andy Shevchenko (2019-03-04 09:29:08)
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.

Which is confusing; since we explicitly want unsigned longs, not some
amorphous bitmap type.

> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/i915/i915_gem.c   | 2 +-
>  drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
>  drivers/gpu/drm/i915/i915_gem_tiling.c| 6 +++---
>  drivers/gpu/drm/i915/selftests/intel_uncore.c | 5 ++---
>  4 files changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6728ea5c71d4..0d96520cfdb3 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4410,7 +4410,7 @@ static void __i915_gem_free_objects(struct 
> drm_i915_private *i915,
> drm_gem_object_release(&obj->base);
> i915_gem_info_remove_obj(i915, obj->base.size);
>  
> -   kfree(obj->bit_17);
> +   bitmap_free(obj->bit_17);
> i915_gem_object_free(obj);
>  
> GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
> b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> index e037e94792f3..1f880e5b79b0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> @@ -790,8 +790,7 @@ i915_gem_object_save_bit_17_swizzle(struct 
> drm_i915_gem_object *obj,
> int i;
>  
> if (obj->bit_17 == NULL) {
> -   obj->bit_17 = kcalloc(BITS_TO_LONGS(page_count),
> - sizeof(long), GFP_KERNEL);
> +   obj->bit_17 = bitmap_zalloc(page_count, GFP_KERNEL);

That feels a bit more of an overreach, as we just use bitops and never
actually use the bitmap iface.

Simply because it kills BITS_TO_LONGS(), even though I do not see why
the bitmap_[z]alloc and bitmap_free are not inlines...

And for this is not the overflow protection of kcalloc silly? We start
with a large value, factorise it, then check that the two factors do not
overflow? If it were to overflow, it would overflow in the
BITS_TO_LONGS() itself.

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread Chris Wilson
Quoting Andy Shevchenko (2019-03-04 09:29:07)
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
> 
> Signed-off-by: Andy Shevchenko 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/38] drm/i915: Introduce the i915_user_extension_method

2019-03-04 Thread Tvrtko Ursulin


On 04/03/2019 09:35, Tvrtko Ursulin wrote:


On 04/03/2019 09:04, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-03-04 08:54:10)


On 01/03/2019 18:57, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-03-01 15:39:13)


On 01/03/2019 14:03, Chris Wilson wrote:

+int i915_user_extensions(struct i915_user_extension __user *ext,
+  const i915_user_extension_fn *tbl,
+  unsigned long count,
+  void *data)
+{
+ unsigned int stackdepth = 512;
+
+ while (ext) {
+ int err;
+ u64 x;
+
+ if (!stackdepth--) /* recursion vs useful 
flexibility */

+ return -EINVAL;


I don't get this. What stack? Did you mean "static unsigned int
stackdepth" in case someone puts i915_user_extension into the 
extension
table? Or just a limit on number of chained extensions? But you are 
not

processing the recursively here.


It's iterative recursion :)

I still think of this loop in terms of its simple tail recursion.

And if we need to individual levels for unwind, that is a manual stack.

Okay..

One thought I had - if unwind is too unwieldy, could we mandate each
user extension user has an additional output field in the embedding
struct which would hold the last processed extension id?


id? I guess we could do depth, though I guess pointer is more practical.
I don't think you mean ext.name as that we expect to repeat a few times.


Pointer yes, I started with a pointer but then for some reason wrote id, 
where I meant name.



This way the state of the object would be less undefined after failure.
Userspace would be able to tell how far in the extension chain i915
managed to get to.


But I'm not convinced how practical that is. The answer is pretty much
always -EINVAL (anything else is much less ambiguous) and even then you
have no idea which field tripped EINVAL or why?


Which field tripped -EINVAL is why is always true.

I am not 100% convinced myself, just worry about usability. But I don't 
have an usecase at the moment which would be practically helped with 
knowing which extension failed. In all cases I can think of it's a 
programming error ie. should be caught during development and not happen 
in production.


To add - if we are adding a new extensible uAPI my gut feeling is we 
should provision for reporting which stage failed. I think it is easy 
now, while later it would be much harder.


Regards,

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

Re: [Intel-gfx] [PATCH v2 2/2] drm: i915: Switch to bitmap_zalloc()

2019-03-04 Thread Andy Shevchenko
On Mon, Mar 04, 2019 at 09:41:34AM +, Chris Wilson wrote:
> Quoting Andy Shevchenko (2019-03-04 09:29:08)
> > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > Besides that it returns pointer of bitmap type instead of opaque void *.
> 
> Which is confusing; since we explicitly want unsigned longs, not some
> amorphous bitmap type.

Why? You use it as a bitmap anyway since you are telling below you are using
bit ops like set/clear_bit.

> > if (obj->bit_17 == NULL) {
> > -   obj->bit_17 = kcalloc(BITS_TO_LONGS(page_count),
> > - sizeof(long), GFP_KERNEL);
> > +   obj->bit_17 = bitmap_zalloc(page_count, GFP_KERNEL);
> 
> That feels a bit more of an overreach, as we just use bitops and never
> actually use the bitmap iface.

bitops are _luckily_ part of bitmap iface. bitmap iface has been evolved
specifically the way the existing ops will work on it w/o any change.

> Simply because it kills BITS_TO_LONGS(), even though I do not see why
> the bitmap_[z]alloc and bitmap_free are not inlines...

Because of circular dependencies (hell) in the headers.

> And for this is not the overflow protection of kcalloc silly? We start
> with a large value, factorise it, then check that the two factors do not
> overflow? If it were to overflow, it would overflow in the
> BITS_TO_LONGS() itself.

This just a simple API change w/o functional changes.

> Reviewed-by: Chris Wilson 

Thank you.


-- 
With Best Regards,
Andy Shevchenko


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

Re: [Intel-gfx] [PATCH v2 2/2] drm: i915: Switch to bitmap_zalloc()

2019-03-04 Thread Chris Wilson
Quoting Andy Shevchenko (2019-03-04 09:54:46)
> On Mon, Mar 04, 2019 at 09:41:34AM +, Chris Wilson wrote:
> > Quoting Andy Shevchenko (2019-03-04 09:29:08)
> > > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > > Besides that it returns pointer of bitmap type instead of opaque void *.
> > 
> > Which is confusing; since we explicitly want unsigned longs, not some
> > amorphous bitmap type.
> 
> Why? You use it as a bitmap anyway since you are telling below you are using
> bit ops like set/clear_bit.

I consider that bitmap sits on on top of the bitops iface and so we
should be using the types as defined by bitops. The allusion of "return
pointer of bitmap type" is that it may become an abstract type, ill
suited for the actual use. Just concerns over inferred language.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/selftests/mm: Switch to 
bitmap_zalloc()
URL   : https://patchwork.freedesktop.org/series/57507/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693 -> Patchwork_12357


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live_sanitycheck:
- {fi-icl-y}: PASS -> INCOMPLETE

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_cpu_reloc@basic:
- fi-kbl-7560u:   PASS -> INCOMPLETE [fdo#103665]

  * igt@gem_exec_basic@gtt-bsd2:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57

  * igt@gem_workarounds@basic-read:
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] +57

  * igt@kms_busy@basic-flip-c:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@hdmi-edid-read:
- fi-hsw-peppy:   NOTRUN -> SKIP [fdo#109271] +46

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> SKIP [fdo#109271] +41

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] +1

  * igt@runner@aborted:
- fi-bxt-dsi: NOTRUN -> FAIL [fdo#109516]

  
 Possible fixes 

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

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

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109516]: https://bugs.freedesktop.org/show_bug.cgi?id=109516


Participating hosts (42 -> 40)
--

  Additional (5): fi-bxt-dsi fi-hsw-peppy fi-byt-clapper fi-skl-6600u 
fi-snb-2600 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3 
fi-blb-e6850 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5693 -> Patchwork_12357

  CI_DRM_5693: 87cb56b5fae5e4a1cb77539a9834348605630773 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4869: a958d3f60b7718151fd0bafcdd1e4874262f51b8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12357: e637ea3aab8143d0f2e4b903efa452638f79004f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e637ea3aab81 drm: i915: Switch to bitmap_zalloc()
f2656a280d3b drm/selftests/mm: Switch to bitmap_zalloc()

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Rename i915_load_modeset_init() to i915_modeset_load()

2019-03-04 Thread Jani Nikula
On Fri, 01 Mar 2019, José Roberto de Souza  wrote:
> i915_load_modeset_init() sounds horrible also lets rename it so
> the future cleanup function of it can be easially recognized.

We load the driver, but init modeset. The name implies modeset init at
driver load.

The modeset load/unload sounds a bit odd to me. Even more so with
begin/finish load and begin unload. It's not obvious to me what those
should do. They're not a pattern we have.

I'm not all that averse to renaming stuff in general, but any rename
increases the cognitive burden for a while, and should make things
*easier* to understand. I don't think that's the case in this series.

I can understand i915_load_modeset_init sounding funny. If you insist on
renaming, I'd go with i915_driver_modeset_init. It's in line with the
rest of the functions.

Here are my suggestions for the names:

i915_modeset_load/i915_modeset_begin_load
-> i915_driver_modeset_init

i915_modeset_unload/i915_modeset_begin_unload
-> i915_driver_modeset_cleanup or _fini

i915_modeset_finish_load
-> i915_driver_modeset_init_late


BR,
Jani.


>
> Cc: Lucas De Marchi 
> Cc: Jani Nikula 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c08abdef5eb6..90c77fab3d70 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -639,7 +639,7 @@ static const struct vga_switcheroo_client_ops 
> i915_switcheroo_ops = {
>   .can_switch = i915_switcheroo_can_switch,
>  };
>  
> -static int i915_load_modeset_init(struct drm_device *dev)
> +static int i915_modeset_load(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct pci_dev *pdev = dev_priv->drm.pdev;
> @@ -1748,7 +1748,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   if (ret < 0)
>   goto out_cleanup_mmio;
>  
> - ret = i915_load_modeset_init(&dev_priv->drm);
> + ret = i915_modeset_load(&dev_priv->drm);
>   if (ret < 0)
>   goto out_cleanup_hw;

-- 
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 v1 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread kbuild test robot
Hi Andy,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.0 next-20190301]
[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/Andy-Shevchenko/drm-selftests-mm-Switch-to-bitmap_zalloc/20190304-183335
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=6.4.0 make.cross ARCH=nds32 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/selftests/test-drm_mm.c: In function 'igt_bottomup':
>> drivers/gpu/drm/selftests/test-drm_mm.c:1747:11: error: implicit declaration 
>> of function 'bitmap_zcalloc' [-Werror=implicit-function-declaration]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  ^~
>> drivers/gpu/drm/selftests/test-drm_mm.c:1747:9: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
^
   cc1: some warnings being treated as errors

vim +/bitmap_zcalloc +1747 drivers/gpu/drm/selftests/test-drm_mm.c

  1725  
  1726  static int igt_bottomup(void *ignored)
  1727  {
  1728  const struct insert_mode *bottomup = &insert_modes[BOTTOMUP];
  1729  DRM_RND_STATE(prng, random_seed);
  1730  const unsigned int count = 8192;
  1731  unsigned int size;
  1732  unsigned long *bitmap;
  1733  struct drm_mm mm;
  1734  struct drm_mm_node *nodes, *node, *next;
  1735  unsigned int *order, n, m, o = 0;
  1736  int ret;
  1737  
  1738  /* Like igt_topdown, but instead of searching for the last hole,
  1739   * we search for the first.
  1740   */
  1741  
  1742  ret = -ENOMEM;
  1743  nodes = vzalloc(array_size(count, sizeof(*nodes)));
  1744  if (!nodes)
  1745  goto err;
  1746  
> 1747  bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  1748  if (!bitmap)
  1749  goto err_nodes;
  1750  
  1751  order = drm_random_order(count, &prng);
  1752  if (!order)
  1753  goto err_bitmap;
  1754  
  1755  ret = -EINVAL;
  1756  for (size = 1; size <= 64; size <<= 1) {
  1757  drm_mm_init(&mm, 0, size*count);
  1758  for (n = 0; n < count; n++) {
  1759  if (!expect_insert(&mm, &nodes[n],
  1760 size, 0, n,
  1761 bottomup)) {
  1762  pr_err("bottomup insert failed, size %u 
step %d\n", size, n);
  1763  goto out;
  1764  }
  1765  
  1766  if (!assert_one_hole(&mm, size*(n + 1), 
size*count))
  1767  goto out;
  1768  }
  1769  
  1770  if (!assert_continuous(&mm, size))
  1771  goto out;
  1772  
  1773  drm_random_reorder(order, count, &prng);
  1774  for_each_prime_number_from(n, 1, min(count, max_prime)) 
{
  1775  for (m = 0; m < n; m++) {
  1776  node = &nodes[order[(o + m) % count]];
  1777  drm_mm_remove_node(node);
  1778  __set_bit(node_index(node), bitmap);
  1779  }
  1780  
  1781  for (m = 0; m < n; m++) {
  1782  unsigned int first;
  1783  
  1784  node = &nodes[order[(o + m) % count]];
  1785  if (!expect_insert(&mm, node,
  1786 size, 0, 0,
  1787 bottomup)) {
  1788  pr_err("insert failed, step 
%d/%d\n", m, n);
  1789  goto out;
  1790  }
  1791  
  1792  first = find_first_bit(bitmap, count);
  1793  if (node_index(node) != first) {
  1794  pr_err("node %d/%d not inserted 
into bottom hole, expected %d, found %d\n",
  1795   

Re: [Intel-gfx] [PATCH v1 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread kbuild test robot
Hi Andy,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.0 next-20190301]
[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/Andy-Shevchenko/drm-selftests-mm-Switch-to-bitmap_zalloc/20190304-183335
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=xtensa 

All error/warnings (new ones prefixed by >>):

   drivers/gpu//drm/selftests/test-drm_mm.c: In function 'igt_bottomup':
>> drivers/gpu//drm/selftests/test-drm_mm.c:1747:11: error: implicit 
>> declaration of function 'bitmap_zcalloc'; did you mean 'bitmap_zalloc'? 
>> [-Werror=implicit-function-declaration]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  ^~
  bitmap_zalloc
>> drivers/gpu//drm/selftests/test-drm_mm.c:1747:9: warning: assignment to 
>> 'long unsigned int *' from 'int' makes pointer from integer without a cast 
>> [-Wint-conversion]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
^
   cc1: some warnings being treated as errors

vim +1747 drivers/gpu//drm/selftests/test-drm_mm.c

  1725  
  1726  static int igt_bottomup(void *ignored)
  1727  {
  1728  const struct insert_mode *bottomup = &insert_modes[BOTTOMUP];
  1729  DRM_RND_STATE(prng, random_seed);
  1730  const unsigned int count = 8192;
  1731  unsigned int size;
  1732  unsigned long *bitmap;
  1733  struct drm_mm mm;
  1734  struct drm_mm_node *nodes, *node, *next;
  1735  unsigned int *order, n, m, o = 0;
  1736  int ret;
  1737  
  1738  /* Like igt_topdown, but instead of searching for the last hole,
  1739   * we search for the first.
  1740   */
  1741  
  1742  ret = -ENOMEM;
  1743  nodes = vzalloc(array_size(count, sizeof(*nodes)));
  1744  if (!nodes)
  1745  goto err;
  1746  
> 1747  bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  1748  if (!bitmap)
  1749  goto err_nodes;
  1750  
  1751  order = drm_random_order(count, &prng);
  1752  if (!order)
  1753  goto err_bitmap;
  1754  
  1755  ret = -EINVAL;
  1756  for (size = 1; size <= 64; size <<= 1) {
  1757  drm_mm_init(&mm, 0, size*count);
  1758  for (n = 0; n < count; n++) {
  1759  if (!expect_insert(&mm, &nodes[n],
  1760 size, 0, n,
  1761 bottomup)) {
  1762  pr_err("bottomup insert failed, size %u 
step %d\n", size, n);
  1763  goto out;
  1764  }
  1765  
  1766  if (!assert_one_hole(&mm, size*(n + 1), 
size*count))
  1767  goto out;
  1768  }
  1769  
  1770  if (!assert_continuous(&mm, size))
  1771  goto out;
  1772  
  1773  drm_random_reorder(order, count, &prng);
  1774  for_each_prime_number_from(n, 1, min(count, max_prime)) 
{
  1775  for (m = 0; m < n; m++) {
  1776  node = &nodes[order[(o + m) % count]];
  1777  drm_mm_remove_node(node);
  1778  __set_bit(node_index(node), bitmap);
  1779  }
  1780  
  1781  for (m = 0; m < n; m++) {
  1782  unsigned int first;
  1783  
  1784  node = &nodes[order[(o + m) % count]];
  1785  if (!expect_insert(&mm, node,
  1786 size, 0, 0,
  1787 bottomup)) {
  1788  pr_err("insert failed, step 
%d/%d\n", m, n);
  1789  goto out;
  1790  }
  1791  
  1792  first = find_first_bit(bitmap, count);
  1793  if (node_index(node) != first) {
  1794

[Intel-gfx] [PATCH] drm/i915: Acquire breadcrumb ref before cancelling

2019-03-04 Thread Chris Wilson
We may race the interrupt signaling with retirement, in which case the
order in which we acquire the reference inside the interrupt is vital to
provide the correct barrier against the request being freed in
retirement, i.e. we need to acquire our reference before marking the
breadcrumb as cancelled (as soon as the breadcrumb is cancelled
retirement may drop its reference to the request without serialisation
with the interrupt handler).

<3>[  683.372226] BUG i915_request (Tainted: G U   ): Object 
already free
<3>[  683.372269] 
-

<4>[  683.372323] Disabling lock debugging due to kernel taint
<3>[  683.372393] INFO: Allocated in i915_request_alloc+0x169/0x810 [i915] 
age=0 cpu=2 pid=1420
<3>[  683.372412]   kmem_cache_alloc+0x21c/0x280
<3>[  683.372478]   i915_request_alloc+0x169/0x810 [i915]
<3>[  683.372540]   i915_gem_do_execbuffer+0x84e/0x1ae0 [i915]
<3>[  683.372603]   i915_gem_execbuffer2_ioctl+0x11b/0x420 [i915]
<3>[  683.372617]   drm_ioctl_kernel+0x83/0xf0
<3>[  683.372626]   drm_ioctl+0x2f3/0x3b0
<3>[  683.372636]   do_vfs_ioctl+0xa0/0x6e0
<3>[  683.372645]   ksys_ioctl+0x35/0x60
<3>[  683.372654]   __x64_sys_ioctl+0x11/0x20
<3>[  683.372664]   do_syscall_64+0x55/0x190
<3>[  683.372675]   entry_SYSCALL_64_after_hwframe+0x49/0xbe
<3>[  683.372740] INFO: Freed in i915_request_retire_upto+0xfb/0x2e0 [i915] 
age=0 cpu=0 pid=1419
<3>[  683.372807]   i915_request_retire_upto+0xfb/0x2e0 [i915]
<3>[  683.372870]   i915_request_add+0x3bd/0x9d0 [i915]
<3>[  683.372931]   i915_gem_do_execbuffer+0x141c/0x1ae0 [i915]
<3>[  683.372991]   i915_gem_execbuffer2_ioctl+0x11b/0x420 [i915]
<3>[  683.373001]   drm_ioctl_kernel+0x83/0xf0
<3>[  683.373008]   drm_ioctl+0x2f3/0x3b0
<3>[  683.373015]   do_vfs_ioctl+0xa0/0x6e0
<3>[  683.373023]   ksys_ioctl+0x35/0x60
<3>[  683.373030]   __x64_sys_ioctl+0x11/0x20
<3>[  683.373037]   do_syscall_64+0x55/0x190
<3>[  683.373045]   entry_SYSCALL_64_after_hwframe+0x49/0xbe
<3>[  683.373054] INFO: Slab 0x79bcdd71 objects=30 used=2 
fp=0x6d77b8af flags=0x80010201
<3>[  683.373069] INFO: Object 0x6d77b8af @offset=24000 
fp=0x7b061eab

<3>[  683.373083] Redzone ee47ef28: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373097] Redzone 0cb91471: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373111] Redzone cf2b86ee: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373125] Redzone f1f5a2cd: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373139] Object 6d77b8af: 00 00 00 00 5a 5a 5a 5a 00 3c 49 c0 
ff ff ff ff  .[  683.373153] Object 6f9b6204: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 
5a 5a 5a 5a  
<3>[  683.373167] Object 91410ffb: e0 dd 6b fa 87 9f ff ff e0 dd 6b fa 
87 9f ff ff  ..k...k.
<3>[  683.373181] Object 4cdf799d: 20 de 6b fa 87 9f ff ff 3d 00 00 00 
00 00 00 00   .k.=...
<3>[  683.373195] Object 545afebc: aa b3 00 00 00 00 00 00 0f 00 00 00 
00 00 00 00  
<3>[  683.373209] Object e4a394a8: 25 bd bd 1b 9f 00 00 00 00 00 00 00 
5a 5a 5a 5a  %...
<3>[  683.373223] Object 29a7878a: 00 00 00 00 ad 4e ad de ff ff ff ff 
5a 5a 5a 5a  .N..
<3>[  683.373237] Object d37797b3: ff ff ff ff ff ff ff ff e8 6e 57 c0 
ff ff ff ff  .nW.
<3>[  683.373251] Object d50414f6: 00 b3 c8 8e ff ff ff ff 80 b0 c8 8e 
ff ff ff ff  
<3>[  683.373265] Object c28e8847: 41 01 4b c0 ff ff ff ff 00 00 88 8e 
88 9f ff ff  A.K.
<3>[  683.373279] Object c74212ab: 38 c1 6d 8a 88 9f ff ff 58 21 74 8a 
88 9f ff ff  8.m.X!t.
<3>[  683.373293] Object 0d8012cf: c0 c1 6d 8a 88 9f ff ff 58 79 dd d9 
87 9f ff ff  ..m.Xy..
<3>[  683.373306] Object c9900b91: 98 d0 4e 8a 88 9f ff ff 58 3c e8 9b 
88 9f ff ff  ..N.X<..
<3>[  683.373320] Object 44bb8c3d: 58 3c e8 9b 88 9f ff ff 64 f5 04 00 
00 00 00 00  X<..d...
<3>[  683.373334] Object 180c4cca: 00 00 00 00 ad 4e ad de ff ff ff ff 
5a 5a 5a 5a  .N..
<3>[  683.373348] Object c9044498: ff ff ff ff ff ff ff ff e0 6e 57 c0 
ff ff ff ff  .nW.
<3>[  683.373362] Object 72d0dfb3: 00 00 00 00 00 00 00 00 c0 b1 c8 8e 
ff ff ff ff  
<3>[  683.373376] Object 81f198b9: 55 01 4b c0 ff ff ff ff d8 de 6b fa 
87 9f ff ff  U.K...k.
<3>[  683.373390] Object 6a375a13: d8 de 6b fa 87 9f ff ff cc 05 39 c0 
ff ff ff ff  ..k...9.
<3>[  683.373404] Object b8392dd1: ff ff ff ff 5a 5a 5a 5a 5a 5a 5a 5a 
5a 5a 5a 5a  
<3>[  683.373418] Object e5c1bbcb: 5a 5a 5a 5a 

Re: [Intel-gfx] [PATCH 2/2] drm: Add detection of changing of edid on between suspend and resume

2019-03-04 Thread Maarten Lankhorst
Op 01-03-2019 om 11:01 schreef Gwan-gyeong Mun:
> The hotplug detection routine of drm_helper_hpd_irq_event() can detect
> changing of status of connector, but it can not detect changing of edid.
>
> Following scenario requires detection of changing of edid.
>
>  1) plug display device to a connector
>  2) system suspend
>  3) unplug 1)'s display device and plug the other display device to a
> connector
>  4) system resume
>
> It adds edid check routine when a connector status still remains as
> "connector_status_connected".
>
> v2: Add NULL check before comparing of EDIDs.
> v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan, Mika)
>
> Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate
> Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend
> Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate
> Testcase: igt/kms_chamelium/dp-edid-change-during-suspend
>
> Signed-off-by: Gwan-gyeong Mun 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 6fd08e04b323..036a57d2b29e 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -742,7 +742,16 @@ EXPORT_SYMBOL(drm_kms_helper_poll_fini);
>   * panels.
>   *
>   * This helper function is useful for drivers which can't or don't track 
> hotplug
> - * interrupts for each connector.
> + * interrupts for each connector. And it also supports a detection of 
> changing
> + * of edid on between suspend and resume when a connector status still 
> remains
> + * as "connector_status_connected".
> + *
> + * Following scenario requires detection of changing of edid.
> + *  1) plug display device to a connector
> + *  2) system suspend
> + *  3) unplug 1)'s display device and plug the other display device to a
> +   connector
> + *  4) system resume
>   *
>   * Drivers which support hotplug interrupts for each connector individually 
> and
>   * which have a more fine-grained detect logic should bypass this code and

We already have a drm_connector_update_edid_property(), so we cache edid 
already?

Could we use that, perhaps reworking slightly how edids are updated in i915?
Like drm_connector_update_property_test

The current code feels like a hack. The fact we don't clear old_edid
or free it, makes me worry that your current patch will either use
old_edid after it'd freed, or have the old_edid leaked.

~Maarten

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev4)
URL   : https://patchwork.freedesktop.org/series/56606/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693_full -> Patchwork_12355_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_pwrite@huge-gtt-backwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290] +1

  * igt@i915_pm_rpm@dpms-lpsp:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +6

  * igt@i915_pm_rpm@gem-evict-pwrite:
- shard-skl:  PASS -> INCOMPLETE [fdo#107807]

  * igt@i915_pm_rpm@gem-execbuf-stress-extra-wait:
- shard-skl:  PASS -> INCOMPLETE [fdo#107803] / [fdo#107807]

  * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]

  * igt@kms_atomic_transition@3x-modeset-transitions:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +10

  * igt@kms_atomic_transition@5x-modeset-transitions:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#107956] +1

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_chamelium@dp-edid-read:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_color@pipe-a-degamma:
- shard-skl:  PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_color@pipe-b-ctm-max:
- shard-apl:  PASS -> FAIL [fdo#108147]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +2

  * igt@kms_cursor_crc@cursor-128x42-random:
- shard-skl:  NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl:  PASS -> FAIL [fdo#109350]

  * igt@kms_draw_crc@draw-method-xrgb-render-untiled:
- shard-skl:  PASS -> FAIL [fdo#103184] / [fdo#108472]

  * igt@kms_flip@2x-flip-vs-panning-vs-hang:
- shard-iclb: NOTRUN -> SKIP [fdo#109274]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  NOTRUN -> FAIL [fdo#105363]

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  PASS -> FAIL [fdo#105363]

  * igt@kms_flip@modeset-vs-vblank-race:
- shard-skl:  PASS -> FAIL [fdo#103060]

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-skl:  NOTRUN -> FAIL [fdo#103167] / [fdo#105682]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> SKIP [fdo#109280]

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-cpu:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +6

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +1

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- shard-skl:  NOTRUN -> FAIL [fdo#103191] / [fdo#107362]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  PASS -> SKIP [fdo#109271] +4

  * igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl:  PASS -> FAIL [fdo#103166] +3
- shard-glk:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl:  PASS -> FAIL [fdo#108145]
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  NOTRUN -> FAIL [fdo#107815]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166] +3

  * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +7

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> INCOMPLETE [fdo#103665]

  * igt@kms_setmode@basic:
- shard-iclb: NOTRUN -> FAIL [fdo#99912]

  * igt@kms_sysfs_edid_timing:
- shard-iclb: PASS -> FAIL [fdo#100047]

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-rpm:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@kms_vrr@flip-suspend:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +102

  * 

[Intel-gfx] [PATCH 0/6] Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats

2019-03-04 Thread Swati Sharma
This patch series is for enabling P0xx, Y2xx and Y4xx pixel formats for
intel's i915 driver.

In this patch series, Juha Pekka's patch series Gen10+ P0xx formats
https://patchwork.freedesktop.org/series/56053/ is combined with Swati's
https://patchwork.freedesktop.org/series/55035/ for Gen11+ pixel formats
(Y2xx and Y4xx).

P0xx pixel formats are enabled from GLK whereas Y2xx and Y4xx are enabled
from ICL platform.

These patches enable planar formats YUV420-P010, P012 and  P016
(Intial 3 patches of Juha) for GLK+ platform and packed format YUV422-Y210,
Y212 and Y216 and YUV444-Y410, Y412, Y416 for 10, 12 and 16 bits for ICL+
platforms.

IGT validating all these pixel formats is written by Maarten Lankhorst 
https://patchwork.freedesktop.org/patch/284508/

IGT needs libraries for pixman and cairo to support more than 8bpc. Need 
cairo >= 1.17.2 and pixman-1 >= 0.36.0.

Tested with custom cairo and pixman. P0xx and Y2xx successfully validated for
HDR planes, SDR planes having CRC mismatch (known bug for all YUV formats).

v3: fixed missing tab for XYUV (JP)

Juha-Pekka Heikkila (3):
  drm/i915: Add P010, P012, P016 plane control definitions
  drm/i915: Preparations for enabling P010, P012, P016 formats
  drm/i915: Enable P010, P012, P016 formats for primary and sprite
planes

Swati Sharma (3):
  drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
  drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control
definitions
  drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for
universal planes

 drivers/gpu/drm/drm_fourcc.c  |   6 ++
 drivers/gpu/drm/i915/i915_reg.h   |   9 +++
 drivers/gpu/drm/i915/intel_atomic_plane.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c  |  57 ++--
 drivers/gpu/drm/i915/intel_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_pm.c   |  14 ++--
 drivers/gpu/drm/i915/intel_sprite.c   | 108 --
 include/uapi/drm/drm_fourcc.h |  16 +
 8 files changed, 194 insertions(+), 19 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 1/6] drm/i915: Add P010, P012, P016 plane control definitions

2019-03-04 Thread Swati Sharma
From: Juha-Pekka Heikkila 

Add needed plane control flag definitions for P010, P012 and
P016 formats.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9b482b..ce4ad20 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6602,8 +6602,11 @@ enum {
 #define   PLANE_CTL_FORMAT_YUV422  (0 << 24)
 #define   PLANE_CTL_FORMAT_NV12(1 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_2101010(2 << 24)
+#define   PLANE_CTL_FORMAT_P010(3 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_   (4 << 24)
+#define   PLANE_CTL_FORMAT_P012(5 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_16161616F  (6 << 24)
+#define   PLANE_CTL_FORMAT_P016(7 << 24)
 #define   PLANE_CTL_FORMAT_AYUV(8 << 24)
 #define   PLANE_CTL_FORMAT_INDEXED (12 << 24)
 #define   PLANE_CTL_FORMAT_RGB_565 (14 << 24)
-- 
1.9.1

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

[Intel-gfx] [PATCH 5/6] drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions

2019-03-04 Thread Swati Sharma
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)

Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_reg.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ce4ad20..54bba61 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6612,6 +6612,12 @@ enum {
 #define   PLANE_CTL_FORMAT_RGB_565 (14 << 24)
 #define   ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
 #define   PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define   PLANE_CTL_FORMAT_Y210 (1 << 23)
+#define   PLANE_CTL_FORMAT_Y212 (3 << 23)
+#define   PLANE_CTL_FORMAT_Y216 (5 << 23)
+#define   PLANE_CTL_FORMAT_Y410 (7 << 23)
+#define   PLANE_CTL_FORMAT_Y412 (9 << 23)
+#define   PLANE_CTL_FORMAT_Y416 (0xb << 23)
 #define   PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
 #define   PLANE_CTL_KEY_ENABLE_SOURCE  (1 << 21)
 #define   PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/6] drm/i915: Preparations for enabling P010, P012, P016 formats

2019-03-04 Thread Swati Sharma
From: Juha-Pekka Heikkila 

Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c  | 27 +--
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   | 14 +++---
 drivers/gpu/drm/i915/intel_sprite.c   | 22 +++---
 5 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7961cf0..9d32a6f 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -136,7 +136,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
new_crtc_state->active_planes |= BIT(plane->id);
 
if (new_plane_state->base.visible &&
-   new_plane_state->base.fb->format->format == DRM_FORMAT_NV12)
+   is_planar_yuv_format(new_plane_state->base.fb->format->format))
new_crtc_state->nv12_planes |= BIT(plane->id);
 
if (new_plane_state->base.visible &&
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7c5e84e..61ad775 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2681,6 +2681,12 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+   case PLANE_CTL_FORMAT_P010:
+   return DRM_FORMAT_P010;
+   case PLANE_CTL_FORMAT_P012:
+   return DRM_FORMAT_P012;
+   case PLANE_CTL_FORMAT_P016:
+   return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3179,7 +3185,7 @@ int skl_check_plane_surface(struct intel_plane_state 
*plane_state)
 * Handle the AUX surface first since
 * the main surface setup depends on it.
 */
-   if (fb->format->format == DRM_FORMAT_NV12) {
+   if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
@@ -3604,6 +3610,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+   case DRM_FORMAT_P010:
+   return PLANE_CTL_FORMAT_P010;
+   case DRM_FORMAT_P012:
+   return PLANE_CTL_FORMAT_P012;
+   case DRM_FORMAT_P016:
+   return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -5027,9 +5039,9 @@ u16 skl_scaler_calc_phase(int sub, int scale, bool 
chroma_cosited)
return 0;
}
 
-   if (format && format->format == DRM_FORMAT_NV12 &&
+   if (format && is_planar_yuv_format(format->format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
-   DRM_DEBUG_KMS("NV12: src dimensions not met\n");
+   DRM_DEBUG_KMS("Planar YUV: src dimensions not met\n");
return -EINVAL;
}
 
@@ -5103,7 +5115,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
 
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
if (!icl_is_hdr_plane(intel_plane) &&
-   fb && fb->format->format == DRM_FORMAT_NV12)
+   fb && is_planar_yuv_format(fb->format->format))
need_scaler = true;
 
ret = skl_update_scaler(crtc_state, force_detach,
@@ -5140,6 +5152,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_P010:
+   case DRM_FORMAT_P012:
+   case DRM_FORMAT_P016:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
@@ -11191,7 +11206,7 @@ static int icl_check_nv12_planes(struct 
intel_crtc_state *crtc_state)
}
 
if (!linked_state) {
-   DRM_DEBUG_KMS("Need %d free Y planes for NV12\n",
+   DRM_DEBUG_KMS("Need %d free Y planes for planar YUV\n",
  hweight8(crtc_state->nv12_planes));
 
return -EINVAL;
@@ -13909,7 +13924,7 @@ static void fb_obj_bump_render_priority(struct 
drm_i915_gem_object *obj)
 *or
 *cdclk/crtc_clock
 */
-   mult = pixel_format == DRM_FORMAT_NV12 ? 2 : 3;
+   mult = is_plana

[Intel-gfx] [PATCH 4/6] drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc

2019-03-04 Thread Swati Sharma
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.

Y210:   For each component, valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212:   For each component, valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216:   For each component valid data occupies 16 bits,
doesn't require any padding bits.

First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.

The following pixel formats are packed format that follows 4:4:4
chroma sampling. Channels are arranged in the order UYVA in
increasing memory order.

Y410:   Each color component occupies 10 bits and X component
takes 2 bits, thus each pixel occupies 32 bits.
Y412:   Each color component is 16 bits where valid data
occupies MSB 12 bits. LSB 4 bits are filled with zeroes.
Thus, each pixel occupies 64 bits.
Y416:   Each color component occupies 16 bits for valid data,
doesn't require any padding bits. Thus, each pixel
occupies 64 bits.

v3: fixed missing tab for XYUV (JP)

Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/drm_fourcc.c  |  6 ++
 include/uapi/drm/drm_fourcc.h | 16 
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ba7e19d..45c9882 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -226,6 +226,12 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
+   { .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,  
.num_planes = 1,
  .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 }, 
.block_h = { 2, 0, 0 },
  .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index bab2029..9fa7cf7 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -154,6 +154,22 @@
 #define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* 
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
 
 /*
+ * packed Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0] 
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */
+
+/*
+ * packed Y4xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb except Y410
+ */
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0] 
X:V:Y:U 2:10:10:10 little endian */
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0] 
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [63:0] 
X:V:Y:U 16:16:16:16 little endian */
+
+/*
  * packed YCbCr420 2x2 tiled formats
  * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
  */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://li

[Intel-gfx] [PATCH 6/6] drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes

2019-03-04 Thread Swati Sharma
Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 30 ++
 drivers/gpu/drm/i915/intel_sprite.c  | 60 +++-
 2 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 61ad775..6825267 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2687,6 +2687,18 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
return DRM_FORMAT_P012;
case PLANE_CTL_FORMAT_P016:
return DRM_FORMAT_P016;
+   case PLANE_CTL_FORMAT_Y210:
+   return DRM_FORMAT_Y210;
+   case PLANE_CTL_FORMAT_Y212:
+   return DRM_FORMAT_Y212;
+   case PLANE_CTL_FORMAT_Y216:
+   return DRM_FORMAT_Y216;
+   case PLANE_CTL_FORMAT_Y410:
+   return DRM_FORMAT_Y410;
+   case PLANE_CTL_FORMAT_Y412:
+   return DRM_FORMAT_Y412;
+   case PLANE_CTL_FORMAT_Y416:
+   return DRM_FORMAT_Y416;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3616,6 +3628,18 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_P012;
case DRM_FORMAT_P016:
return PLANE_CTL_FORMAT_P016;
+   case DRM_FORMAT_Y210:
+   return PLANE_CTL_FORMAT_Y210;
+   case DRM_FORMAT_Y212:
+   return PLANE_CTL_FORMAT_Y212;
+   case DRM_FORMAT_Y216:
+   return PLANE_CTL_FORMAT_Y216;
+   case DRM_FORMAT_Y410:
+   return PLANE_CTL_FORMAT_Y410;
+   case DRM_FORMAT_Y412:
+   return PLANE_CTL_FORMAT_Y412;
+   case DRM_FORMAT_Y416:
+   return PLANE_CTL_FORMAT_Y416;
default:
MISSING_CASE(pixel_format);
}
@@ -5155,6 +5179,12 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_Y410:
+   case DRM_FORMAT_Y412:
+   case DRM_FORMAT_Y416:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0db3c5d..89d7bf7 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1816,6 +1816,27 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t icl_plane_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_Y210,
+   DRM_FORMAT_Y212,
+   DRM_FORMAT_Y216,
+   DRM_FORMAT_Y410,
+   DRM_FORMAT_Y412,
+   DRM_FORMAT_Y416,
+};
+
 static const u32 skl_planar_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -1851,6 +1872,31 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_P016,
 };
 
+static const uint32_t icl_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_P010,
+   DRM_FORMAT_P012,
+   DRM_FORMAT_P016,
+   DRM_FORMAT_Y210,
+   DRM_FORMAT_Y212,
+   DRM_FORMAT_Y216,
+   DRM_FORMAT_Y410,
+   DRM_FORMAT_Y412,
+   DRM_FORMAT_Y416,
+};
+
 static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1993,6 +2039,12 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_Y410:
+   case DRM_FORMAT_Y412:
+   case DRM_FORMAT_Y416:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -2133,13 +2185,19 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
 
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
-   

[Intel-gfx] [PATCH 3/6] drm/i915: Enable P010, P012, P016 formats for primary and sprite planes

2019-03-04 Thread Swati Sharma
From: Juha-Pekka Heikkila 

Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 1be7d59..0db3c5d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1832,6 +1832,25 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_NV12,
 };
 
+static const uint32_t glk_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_P010,
+   DRM_FORMAT_P012,
+   DRM_FORMAT_P016,
+};
+
 static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -2114,8 +2133,13 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
 
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
-   formats = skl_planar_formats;
-   num_formats = ARRAY_SIZE(skl_planar_formats);
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+   formats = glk_planar_formats;
+   num_formats = ARRAY_SIZE(glk_planar_formats);
+   } else {
+   formats = skl_planar_formats;
+   num_formats = ARRAY_SIZE(skl_planar_formats);
+   }
} else {
formats = skl_plane_formats;
num_formats = ARRAY_SIZE(skl_plane_formats);
-- 
1.9.1

___
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: Acquire breadcrumb ref before cancelling

2019-03-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Acquire breadcrumb ref before cancelling
URL   : https://patchwork.freedesktop.org/series/57512/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
87cc082b1759 drm/i915: Acquire breadcrumb ref before cancelling
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#14: 
<3>[  683.372226] BUG i915_request (Tainted: G U   ): Object 
already free

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

___
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: Acquire breadcrumb ref before cancelling

2019-03-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Acquire breadcrumb ref before cancelling
URL   : https://patchwork.freedesktop.org/series/57512/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693 -> Patchwork_12358


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_mmap_gtt@basic-copy:
- {fi-icl-y}: PASS -> DMESG-WARN

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_basic@gtt-bsd2:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@gem_workarounds@basic-read:
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] +57

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  * igt@kms_busy@basic-flip-c:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@hdmi-edid-read:
- fi-hsw-peppy:   NOTRUN -> SKIP [fdo#109271] +46

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> SKIP [fdo#109271] +41

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]

  * igt@runner@aborted:
- fi-bxt-dsi: NOTRUN -> FAIL [fdo#109516]

  
 Possible fixes 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  * igt@i915_selftest@live_objects:
- {fi-icl-y}: INCOMPLETE [fdo#107713] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

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

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109516]: https://bugs.freedesktop.org/show_bug.cgi?id=109516
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (42 -> 40)
--

  Additional (5): fi-bxt-dsi fi-hsw-peppy fi-byt-clapper fi-skl-6600u 
fi-snb-2600 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3 
fi-pnv-d510 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5693 -> Patchwork_12358

  CI_DRM_5693: 87cb56b5fae5e4a1cb77539a9834348605630773 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4869: a958d3f60b7718151fd0bafcdd1e4874262f51b8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12358: 87cc082b1759daa369e3273eecf137c4ab2cd529 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

87cc082b1759 drm/i915: Acquire breadcrumb ref before cancelling

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)
URL   : https://patchwork.freedesktop.org/series/56606/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
dc7b63022f48 drm/i915: Add P010, P012, P016 plane control definitions
f3c20c560ac9 drm/i915: Preparations for enabling P010, P012, P016 formats
5a405a3f3b1a drm/i915: Enable P010, P012, P016 formats for primary and sprite 
planes
-:22: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#22: FILE: drivers/gpu/drm/i915/intel_sprite.c:1835:
+static const uint32_t glk_planar_formats[] = {

total: 0 errors, 0 warnings, 1 checks, 40 lines checked
99c57cdcbd0b drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
-:50: WARNING:LONG_LINE: line over 100 characters
#50: FILE: drivers/gpu/drm/drm_fourcc.c:229:
+   { .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:51: WARNING:LONG_LINE: line over 100 characters
#51: FILE: drivers/gpu/drm/drm_fourcc.c:230:
+   { .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:52: WARNING:LONG_LINE: line over 100 characters
#52: FILE: drivers/gpu/drm/drm_fourcc.c:231:
+   { .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },

-:53: WARNING:LONG_LINE: line over 100 characters
#53: FILE: drivers/gpu/drm/drm_fourcc.c:232:
+   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:54: WARNING:LONG_LINE: line over 100 characters
#54: FILE: drivers/gpu/drm/drm_fourcc.c:233:
+   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:55: WARNING:LONG_LINE: line over 100 characters
#55: FILE: drivers/gpu/drm/drm_fourcc.c:234:
+   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

-:71: WARNING:LONG_LINE_COMMENT: line over 100 characters
#71: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */

-:72: WARNING:LONG_LINE_COMMENT: line over 100 characters
#72: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */

-:73: WARNING:LONG_LINE_COMMENT: line over 100 characters
#73: FILE: include/uapi/drm/drm_fourcc.h:162:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0] 
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */

-:79: WARNING:LONG_LINE_COMMENT: line over 100 characters
#79: FILE: include/uapi/drm/drm_fourcc.h:168:
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0] 
X:V:Y:U 2:10:10:10 little endian */

-:80: WARNING:LONG_LINE_COMMENT: line over 100 characters
#80: FILE: include/uapi/drm/drm_fourcc.h:169:
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0] 
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */

-:81: WARNING:LONG_LINE_COMMENT: line over 100 characters
#81: FILE: include/uapi/drm/drm_fourcc.h:170:
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [63:0] 
X:V:Y:U 16:16:16:16 little endian */

total: 0 errors, 12 warnings, 0 checks, 34 lines checked
0fc776288d7d drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control 
definitions
9455280cd26c drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:75: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#75: FILE: drivers/gpu/drm/i915/intel_sprite.c:1819:
+static const uint32_t icl_plane_formats[] = {

-:103: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#103: FILE: drivers/gpu/drm/i915/intel_sprite.c:1875:
+static const uint32_t icl_planar_formats[] = {

total: 0 errors, 1 warnings, 2 checks, 138 lines checked

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)
URL   : https://patchwork.freedesktop.org/series/56606/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add P010, P012, P016 plane control definitions
Okay!

Commit: drm/i915: Preparations for enabling P010, P012, P016 formats
-O:drivers/gpu/drm/i915/intel_display.c:13915:21: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_display.c:13915:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_display.c:13930:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_display.c:13930:21: warning: expression using 
sizeof(void)

Commit: drm/i915: Enable P010, P012, P016 formats for primary and sprite planes
Okay!

Commit: drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
Okay!

Commit: drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions
Okay!

Commit: drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
Okay!

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: refactor transcoders reporting on error state

2019-03-04 Thread Kahola, Mika
Looks ok.

On Fri, 2019-02-22 at 15:02 -0800, Lucas De Marchi wrote:
> Instead of keeping track of the number of transcoders, loop through
> all
> the interesting ones and check if there is a correspondent offset.
> 
> Cc: Rodrigo Vivi 

Reviewed-by: Mika Kahola 

> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b1d63c32ca94..9dfb99195144 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -16374,8 +16374,6 @@ struct intel_display_error_state {
>  
>   u32 power_well_driver;
>  
> - int num_transcoders;
> -
>   struct intel_cursor_error_state {
>   u32 control;
>   u32 position;
> @@ -16400,6 +16398,7 @@ struct intel_display_error_state {
>   } plane[I915_MAX_PIPES];
>  
>   struct intel_transcoder_error_state {
> + bool available;
>   bool power_domain_on;
>   enum transcoder cpu_transcoder;
>  
> @@ -16426,6 +16425,8 @@ intel_display_capture_error_state(struct
> drm_i915_private *dev_priv)
>   };
>   int i;
>  
> + BUILD_BUG_ON(ARRAY_SIZE(transcoders) != ARRAY_SIZE(error-
> >transcoder));
> +
>   if (!HAS_DISPLAY(dev_priv))
>   return NULL;
>  
> @@ -16466,14 +16467,13 @@ intel_display_capture_error_state(struct
> drm_i915_private *dev_priv)
>   error->pipe[i].stat = I915_READ(PIPESTAT(i));
>   }
>  
> - /* Note: this does not include DSI transcoders. */
> - error->num_transcoders = INTEL_INFO(dev_priv)->num_pipes;
> - if (HAS_DDI(dev_priv))
> - error->num_transcoders++; /* Account for eDP. */
> -
> - for (i = 0; i < error->num_transcoders; i++) {
> + for (i = 0; i < ARRAY_SIZE(error->transcoder); i++) {
>   enum transcoder cpu_transcoder = transcoders[i];
>  
> + if (!INTEL_INFO(dev_priv)-
> >trans_offsets[cpu_transcoder])
> + continue;
> +
> + error->transcoder[i].available = true;
>   error->transcoder[i].power_domain_on =
>   __intel_display_power_is_enabled(dev_priv,
>   POWER_DOMAIN_TRANSCODER(cpu_transcoder)
> );
> @@ -16537,7 +16537,10 @@ intel_display_print_error_state(struct
> drm_i915_error_state_buf *m,
>   err_printf(m, "  BASE: %08x\n", error->cursor[i].base);
>   }
>  
> - for (i = 0; i < error->num_transcoders; i++) {
> + for (i = 0; i < ARRAY_SIZE(error->transcoder); i++) {
> + if (!error->transcoder[i].available)
> + continue;
> +
>   err_printf(m, "CPU transcoder: %s\n",
>  transcoder_name(error-
> >transcoder[i].cpu_transcoder));
>   err_printf(m, "  Power: %s\n",
___
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: allow platforms without eDP transcoder

2019-03-04 Thread Kahola, Mika
On Fri, 2019-03-01 at 15:56 -0800, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 06:17:13AM -0800, Mika Kahola wrote:
> > Looks allright.
> > 
> > On Fri, 2019-02-22 at 15:02 -0800, Lucas De Marchi wrote:
> > > Define a HAS_TRANSCODER_EDP() macro that checks if we have
> > > defined an
> > > offset for this transcoder. This allows platforms to be defined
> > > without
> > > eDP transcoder.
> > > 
> > > Cc: Mika Kahola 
> > > Cc: Imre Deak 
> > > Cc: Rodrigo Vivi 
> > 
> > Reviewed-by: Mika Kahola 
> 
> humn.. this depends on the first patch. Is this r-b for both?
I reviewed the first patch too. It looked ok so I gave my r-b on that
one too.

Cheers,
Mika
> 
> Lucas De Marchi
> 
> > 
> > > Signed-off-by: Lucas De Marchi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  | 1 +
> > >  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> > >  drivers/gpu/drm/i915/intel_display.c | 5 -
> > >  3 files changed, 8 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index cc09caf3870e..a8e9f0cf20f5 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2519,6 +2519,7 @@ static inline unsigned int
> > > i915_sg_segment_size(void)
> > >  #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)-
> > > > display.has_ddi)
> > > 
> > >  #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)-
> > > > has_fpga_dbg)
> > > 
> > >  #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)-
> > > > display.has_psr)
> > > 
> > > +#define HAS_TRANSCODER_EDP(dev_priv)  (INTEL_INFO(dev_priv)-
> > > > trans_offsets[TRANSCODER_EDP] != 0)
> > > 
> > >  #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)-
> > > > has_rc6)
> > > 
> > >  #define HAS_RC6p(dev_priv)(INTEL_INFO(dev_priv)-
> > > > has_rc6p)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index ea83071a22c4..8eeffa027b74 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1911,7 +1911,7 @@ bool
> > > intel_ddi_connector_get_hw_state(struct
> > > intel_connector *intel_connector)
> > >   goto out;
> > >   }
> > > 
> > > - if (port == PORT_A)
> > > + if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A)
> > >   cpu_transcoder = TRANSCODER_EDP;
> > >   else
> > >   cpu_transcoder = (enum transcoder) pipe;
> > > @@ -1973,7 +1973,7 @@ static void
> > > intel_ddi_get_encoder_pipes(struct
> > > intel_encoder *encoder,
> > >   if (!(tmp & DDI_BUF_CTL_ENABLE))
> > >   goto out;
> > > 
> > > - if (port == PORT_A) {
> > > + if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A) {
> > >   tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
> > > 
> > >   switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
> > > @@ -3856,7 +3856,7 @@ static int intel_ddi_compute_config(struct
> > > intel_encoder *encoder,
> > >   enum port port = encoder->port;
> > >   int ret;
> > > 
> > > - if (port == PORT_A)
> > > + if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A)
> > >   pipe_config->cpu_transcoder = TRANSCODER_EDP;
> > > 
> > >   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_HDMI))
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 9dfb99195144..8bf4bdf2006a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -9688,7 +9688,7 @@ static bool hsw_get_transcoder_state(struct
> > > intel_crtc *crtc,
> > >   struct drm_device *dev = crtc->base.dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   enum intel_display_power_domain power_domain;
> > > - unsigned long panel_transcoder_mask = BIT(TRANSCODER_EDP);
> > > + unsigned long panel_transcoder_mask = 0;
> > >   unsigned long enabled_panel_transcoders = 0;
> > >   enum transcoder panel_transcoder;
> > >   u32 tmp;
> > > @@ -9697,6 +9697,9 @@ static bool hsw_get_transcoder_state(struct
> > > intel_crtc *crtc,
> > >   panel_transcoder_mask |=
> > >   BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1);
> > > 
> > > + if (HAS_TRANSCODER_EDP(dev_priv))
> > > + panel_transcoder_mask |= BIT(TRANSCODER_EDP);
> > > +
> > >   /*
> > >* The pipe->transcoder mapping is fixed with the exception of
> > > the eDP
> > >* and DSI transcoders handled below.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)
URL   : https://patchwork.freedesktop.org/series/56606/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693 -> Patchwork_12359


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56606/revisions/5/mbox/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_basic@gtt-bsd2:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57

  * igt@gem_workarounds@basic-read:
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] +57

  * igt@i915_module_load@reload:
- fi-blb-e6850:   NOTRUN -> INCOMPLETE [fdo#107718]

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   PASS -> SKIP [fdo#109271]

  * igt@i915_pm_rpm@basic-rte:
- fi-bsw-kefka:   PASS -> FAIL [fdo#108800]

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  * igt@kms_busy@basic-flip-c:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2600:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@hdmi-edid-read:
- fi-hsw-peppy:   NOTRUN -> SKIP [fdo#109271] +46

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> SKIP [fdo#109271] +41

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]

  * igt@kms_psr@primary_mmap_gtt:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +8

  * igt@runner@aborted:
- fi-bxt-dsi: NOTRUN -> FAIL [fdo#109516]

  
 Possible fixes 

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

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

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109516]: https://bugs.freedesktop.org/show_bug.cgi?id=109516
  [fdo#109779]: https://bugs.freedesktop.org/show_bug.cgi?id=109779


Participating hosts (42 -> 41)
--

  Additional (5): fi-bxt-dsi fi-hsw-peppy fi-byt-clapper fi-skl-6600u 
fi-snb-2600 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3 
fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5693 -> Patchwork_12359

  CI_DRM_5693: 87cb56b5fae5e4a1cb77539a9834348605630773 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4869: a958d3f60b7718151fd0bafcdd1e4874262f51b8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12359: 9455280cd26c998d49921139b65675fa3052a335 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9455280cd26c drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for 
universal planes
0fc776288d7d drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control 
definitions
99c57cdcbd0b drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
5a405a3f3b1a drm/i915: Enable P010, P012, P016 formats for primary and sprite 
planes
f3c20c560ac9 drm/i915: Preparations for enabling P010, P012, P016 formats
dc7b63022f48 drm/i915: Add P010, P012, P016 plane control definitions

== Logs ==

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

Re: [Intel-gfx] [PATCH 14/17] drm/tegra: Convert to using __drm_atomic_helper_crtc_reset() for reset.

2019-03-04 Thread Thierry Reding
On Fri, Mar 01, 2019 at 01:56:24PM +0100, Maarten Lankhorst wrote:
> Convert tegra to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(),
> call it directly for freeing the old state.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: linux-te...@vger.kernel.org
> ---
>  drivers/gpu/drm/tegra/dc.c | 30 +++---
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 607a6ea17ecc..57c88d78cdaa 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -1153,25 +1153,6 @@ static void tegra_dc_destroy(struct drm_crtc *crtc)
>   drm_crtc_cleanup(crtc);
>  }
>  
> -static void tegra_crtc_reset(struct drm_crtc *crtc)
> -{
> - struct tegra_dc_state *state;
> -
> - if (crtc->state)
> - __drm_atomic_helper_crtc_destroy_state(crtc->state);
> -
> - kfree(crtc->state);
> - crtc->state = NULL;
> -
> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = &state->base;
> - crtc->state->crtc = crtc;
> - }
> -
> - drm_crtc_vblank_reset(crtc);
> -}
> -
>  static struct drm_crtc_state *
>  tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
>  {
> @@ -1198,6 +1179,17 @@ static void tegra_crtc_atomic_destroy_state(struct 
> drm_crtc *crtc,
>   kfree(state);
>  }
>  
> +static void tegra_crtc_reset(struct drm_crtc *crtc)
> +{
> + struct tegra_dc_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
> +
> + if (crtc->state)
> + tegra_crtc_atomic_destroy_state(crtc, crtc->state);
> +
> + __drm_atomic_helper_crtc_reset(crtc, &state->base);
> + drm_crtc_vblank_reset(crtc);
> +}
> +

I would preferred a predeclaration of tegra_crtc_atomic_destroy_state()
in this case because the implementations are in the same order as their
use in tegra_crtc_funcs, but I think I can live with it, so either way:

Acked-by: Thierry Reding 


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

[Intel-gfx] [PATCH] drm/i915: Fix the state checker for ICL Y planes

2019-03-04 Thread Ville Syrjala
From: Ville Syrjälä 

The plane used to scan out NV12 luma on ICL is logically
off but actually on. Fix the state checker to account for this.

Cc: Imre Deak 
Cc: Maarten Lankhorst 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109457
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7c5e84ef5171..b49e789b747e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12589,7 +12589,8 @@ intel_verify_planes(struct intel_atomic_state *state)
 
for_each_new_intel_plane_in_state(state, plane,
  plane_state, i)
-   assert_plane(plane, plane_state->base.visible);
+   assert_plane(plane, plane_state->slave ||
+plane_state->base.visible);
 }
 
 static void
-- 
2.19.2

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/selftests/mm: Switch to bitmap_zalloc()

2019-03-04 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/selftests/mm: Switch to 
bitmap_zalloc()
URL   : https://patchwork.freedesktop.org/series/57507/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693_full -> Patchwork_12357_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gen3_render_tiledy_blits:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +16

  * igt@i915_pm_rpm@dpms-lpsp:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +6

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107807]

  * igt@i915_selftest@live_contexts:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@i915_selftest@live_workarounds:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108954]

  * igt@kms_atomic_transition@4x-modeset-transitions-nonblocking-fencing:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_atomic_transition@5x-modeset-transitions:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#107956] +1

  * igt@kms_busy@extended-pageflip-hang-newfb-render-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_color@pipe-b-ctm-max:
- shard-apl:  PASS -> FAIL [fdo#108147]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +2

  * igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl:  PASS -> FAIL [fdo#109350]

  * igt@kms_fbcon_fbt@psr:
- shard-skl:  NOTRUN -> FAIL [fdo#103833]

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  PASS -> INCOMPLETE [fdo#109507]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-pwrite:
- shard-glk:  PASS -> FAIL [fdo#103167] +2

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-cpu:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +6

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl:  PASS -> FAIL [fdo#108145]
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +1
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-skl:  NOTRUN -> FAIL [fdo#103166] / [fdo#107815]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166] +2

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> FAIL [fdo#109016]

  * igt@kms_setmode@basic:
- shard-apl:  PASS -> FAIL [fdo#99912]

  * igt@kms_sysfs_edid_timing:
- shard-skl:  NOTRUN -> FAIL [fdo#100047]

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-rpm:
- shard-apl:  PASS -> FAIL [fdo#104894] +1

  * igt@kms_vrr@flip-suspend:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +100

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries_display_off:
- shard-skl:  INCOMPLETE [fdo#104108] -> PASS +1

  * igt@i915_pm_rpm@debugfs-read:
- shard-skl:  INCOMPLETE [fdo#107807] -> PASS

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  FAIL [fdo#106510] / [fdo#108145] -> PASS

  * igt@kms_cursor_crc@cursor-64x64-sliding:
- shard-apl:  FAIL [fdo#103232] -> PASS +1

  * igt@kms_cursor_crc@cursor-alpha-transparent:
- shard-skl:  FAIL [fdo#109350] -> PASS

  * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-ytiled:
- shard-skl:  FAIL [fdo#103184] -> PASS

  * igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-apl:  INCOMPLETE [fdo#103927] -> PASS

  * igt@kms_flip_tiling@flip-changes-tiling-y:
- shard-skl:  FAIL [fdo#107931] / [fdo#108303] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt:
- shard-skl:  FAIL [fdo#103167] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-prim

[Intel-gfx] [PATCH] drm/i915: Simplify i830 DVO 2x clock handling

2019-03-04 Thread Ville Syrjala
From: Ville Syrjälä 

Let's just always enable the DVO 2x clock on i830. This way we don't
have to track if DVO is being used or not. The spec does suggest we
should disable the clock when it isn't needed, but this does appear
to work just fine.

This removes another crtc->config usage.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7c5e84ef5171..ac0af94369f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1441,19 +1441,6 @@ static void chv_enable_pll(struct intel_crtc *crtc,
}
 }
 
-static int intel_num_dvo_pipes(struct drm_i915_private *dev_priv)
-{
-   struct intel_crtc *crtc;
-   int count = 0;
-
-   for_each_intel_crtc(&dev_priv->drm, crtc) {
-   count += crtc->base.state->active &&
-   intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DVO);
-   }
-
-   return count;
-}
-
 static void i9xx_enable_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *crtc_state)
 {
@@ -1468,26 +1455,12 @@ static void i9xx_enable_pll(struct intel_crtc *crtc,
if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
assert_panel_unlocked(dev_priv, crtc->pipe);
 
-   /* Enable DVO 2x clock on both PLLs if necessary */
-   if (IS_I830(dev_priv) && intel_num_dvo_pipes(dev_priv) > 0) {
-   /*
-* It appears to be important that we don't enable this
-* for the current pipe before otherwise configuring the
-* PLL. No idea how this should be handled if multiple
-* DVO outputs are enabled simultaneosly.
-*/
-   dpll |= DPLL_DVO_2X_MODE;
-   I915_WRITE(DPLL(!crtc->pipe),
-  I915_READ(DPLL(!crtc->pipe)) | DPLL_DVO_2X_MODE);
-   }
-
/*
 * Apparently we need to have VGA mode enabled prior to changing
 * the P1/P2 dividers. Otherwise the DPLL will keep using the old
 * dividers, even though the register value does change.
 */
-   I915_WRITE(reg, 0);
-
+   I915_WRITE(reg, dpll & ~DPLL_VGA_MODE_DIS);
I915_WRITE(reg, dpll);
 
/* Wait for the clocks to stabilize. */
@@ -1520,16 +1493,6 @@ static void i9xx_disable_pll(const struct 
intel_crtc_state *crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
-   /* Disable DVO 2x clock on both PLLs if necessary */
-   if (IS_I830(dev_priv) &&
-   intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DVO) &&
-   !intel_num_dvo_pipes(dev_priv)) {
-   I915_WRITE(DPLL(PIPE_B),
-  I915_READ(DPLL(PIPE_B)) & ~DPLL_DVO_2X_MODE);
-   I915_WRITE(DPLL(PIPE_A),
-  I915_READ(DPLL(PIPE_A)) & ~DPLL_DVO_2X_MODE);
-   }
-
/* Don't disable pipe or pipe PLLs if needed */
if (IS_I830(dev_priv))
return;
@@ -7494,7 +7457,19 @@ static void i8xx_compute_dpll(struct intel_crtc *crtc,
dpll |= PLL_P2_DIVIDE_BY_4;
}
 
-   if (!IS_I830(dev_priv) &&
+   /*
+* Bspec:
+* "[Almador Errata}: For the correct operation of the muxed DVO pins
+*  (GDEVSELB/ I 2 Cdata, GIRDBY/I 2 CClk) and (GFRAMEB/DVI_Data,
+*  GTRDYB/DVI_Clk): Bit 31 (DPLL VCO Enable) and Bit 30 (2X Clock
+*  Enable) must be set to “1” in both the DPLL A Control Register
+*  (06014h-06017h) and DPLL B Control Register (06018h-0601Bh)."
+*
+* For simplicity We simply keep both bits always enabled in
+* both DPLLS. The spec says we should disable the DVO 2X clock
+* when not needed, but this seems to work fine in practice.
+*/
+   if (IS_I830(dev_priv) ||
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DVO))
dpll |= DPLL_DVO_2X_MODE;
 
@@ -8218,14 +8193,6 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
}
pipe_config->dpll_hw_state.dpll = I915_READ(DPLL(crtc->pipe));
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
-   /*
-* DPLL_DVO_2X_MODE must be enabled for both DPLLs
-* on 830. Filter it out here so that we don't
-* report errors due to that.
-*/
-   if (IS_I830(dev_priv))
-   pipe_config->dpll_hw_state.dpll &= ~DPLL_DVO_2X_MODE;
-
pipe_config->dpll_hw_state.fp0 = I915_READ(FP0(crtc->pipe));
pipe_config->dpll_hw_state.fp1 = I915_READ(FP1(crtc->pipe));
} else {
@@ -15613,7 +15580,7 @@ void i830_enable_pipe(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 

Re: [Intel-gfx] [PATCH 15/17] drm/vc4: Convert to using __drm_atomic_helper_crtc_reset() for reset.

2019-03-04 Thread Maarten Lankhorst
Op 01-03-2019 om 23:47 schreef Eric Anholt:
> Maarten Lankhorst  writes:
>
>> Convert vc4 to using __drm_atomic_helper_crtc_reset(), instead of
>> writing its own version. Instead of open coding destroy_state(),
>> call it directly for freeing the old state.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Eric Anholt 
>> ---
>>  drivers/gpu/drm/vc4/vc4_crtc.c | 9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
>> index e7c04a9eb219..fdf21594b050 100644
>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
>> @@ -1041,12 +1041,13 @@ static void vc4_crtc_destroy_state(struct drm_crtc 
>> *crtc,
>>  static void
>>  vc4_crtc_reset(struct drm_crtc *crtc)
>>  {
>> -if (crtc->state)
>> -vc4_crtc_destroy_state(crtc->state);
>> +struct vc4_crtc_state *crtc_state =
>> +kzalloc(sizeof(*crtc_state), GFP_KERNEL);
>>  
>> -crtc->state = kzalloc(sizeof(struct vc4_crtc_state), GFP_KERNEL);
>>  if (crtc->state)
>> -crtc->state->crtc = crtc;
>> +vc4_crtc_destroy_state(crtc, crtc->state);
>> +
>> +__drm_atomic_helper_crtc_reset(crtc, &crtc_state->base);
> Wouldn't it be much easier if __drm_atomic_helper_crtc_reset took in a
> new state and destroyed the old state for you?  It seems like hardly a
> helper as is.

Yes it would, but the plane/connector reset is the same. If you want to convert 
them all it would be nice. :)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix the state checker for ICL Y planes

2019-03-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix the state checker for ICL Y planes
URL   : https://patchwork.freedesktop.org/series/57518/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5694 -> Patchwork_12360


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   NOTRUN -> INCOMPLETE [fdo#107718]

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  PASS -> FAIL [fdo#108511]
- fi-hsw-4770:PASS -> INCOMPLETE [fdo#107807]

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   PASS -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   SKIP [fdo#109271] -> PASS

  * igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900:   FAIL [fdo#108800] -> PASS

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: DMESG-FAIL [fdo#103182] -> PASS

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380


Participating hosts (46 -> 40)
--

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


Build changes
-

* Linux: CI_DRM_5694 -> Patchwork_12360

  CI_DRM_5694: daab510ef99070d4974e8408f34b465be5c3c0b7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4869: a958d3f60b7718151fd0bafcdd1e4874262f51b8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12360: 1f40bc4723d5f98d777dbef250e9ce890ed15810 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1f40bc4723d5 drm/i915: Fix the state checker for ICL Y planes

== Logs ==

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

[Intel-gfx] [RFT i-g-t] lib/i915: Assert mmap size alignment

2019-03-04 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Fishing for fails...

/*
mmap(2) mandates size is page aligned so check this in our wrappers.
*/

Signed-off-by: Tvrtko Ursulin 
---
 lib/i915/gem_mman.c |  4 
 lib/igt_fb.c| 14 --
 tests/kms_ccs.c | 14 --
 tests/kms_psr.c |  8 
 4 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 3cf9a6bbdb31..084dbb3b3678 100644
--- a/lib/i915/gem_mman.c
+++ b/lib/i915/gem_mman.c
@@ -57,6 +57,8 @@ void *__gem_mmap__gtt(int fd, uint32_t handle, uint64_t size, 
unsigned prot)
struct drm_i915_gem_mmap_gtt mmap_arg;
void *ptr;
 
+   igt_assert(!(size & 4095));
+
memset(&mmap_arg, 0, sizeof(mmap_arg));
mmap_arg.handle = handle;
if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_GTT, &mmap_arg))
@@ -162,6 +164,8 @@ static void
 {
struct drm_i915_gem_mmap arg;
 
+   igt_assert(!(size & 4095));
+
memset(&arg, 0, sizeof(arg));
arg.handle = handle;
arg.offset = offset;
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 9dca2a4603ce..82f0a41631c1 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -1494,7 +1494,7 @@ static void free_linear_mapping(struct fb_blit_upload 
*blit)
struct igt_fb *fb = blit->fb;
struct fb_blit_linear *linear = &blit->linear;
 
-   gem_munmap(linear->map, linear->fb.size);
+   gem_munmap(linear->map, ALIGN(linear->fb.size, 4096));
gem_set_domain(fd, linear->fb.gem_handle,
   I915_GEM_DOMAIN_GTT, 0);
 
@@ -1544,7 +1544,8 @@ static void setup_linear_mapping(int fd, struct igt_fb 
*fb, struct fb_blit_linea
 
/* Setup cairo context */
linear->map = gem_mmap__cpu(fd, linear->fb.gem_handle,
-   0, linear->fb.size, PROT_READ | PROT_WRITE);
+   0, ALIGN(linear->fb.size, 4096),
+   PROT_READ | PROT_WRITE);
 }
 
 static void create_cairo_surface__blit(int fd, struct igt_fb *fb)
@@ -1588,7 +1589,7 @@ int igt_dirty_fb(int fd, struct igt_fb *fb)
 
 static void unmap_bo(struct igt_fb *fb, void *ptr)
 {
-   gem_munmap(ptr, fb->size);
+   gem_munmap(ptr, ALIGN(fb->size, 4096));
 
if (fb->is_dumb)
igt_dirty_fb(fb->fd, fb);
@@ -1604,6 +1605,7 @@ static void destroy_cairo_surface__gtt(void *arg)
 
 static void *map_bo(int fd, struct igt_fb *fb)
 {
+   size_t size = ALIGN(fb->size, 4096);
void *ptr;
 
if (is_i915_device(fd))
@@ -1611,13 +1613,13 @@ static void *map_bo(int fd, struct igt_fb *fb)
   I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
 
if (fb->is_dumb)
-   ptr = kmstest_dumb_map_buffer(fd, fb->gem_handle, fb->size,
+   ptr = kmstest_dumb_map_buffer(fd, fb->gem_handle, size,
  PROT_READ | PROT_WRITE);
else if (is_i915_device(fd))
-   ptr = gem_mmap__gtt(fd, fb->gem_handle, fb->size,
+   ptr = gem_mmap__gtt(fd, fb->gem_handle, size,
PROT_READ | PROT_WRITE);
else if (is_vc4_device(fd))
-   ptr = igt_vc4_mmap_bo(fd, fb->gem_handle, fb->size,
+   ptr = igt_vc4_mmap_bo(fd, fb->gem_handle, size,
  PROT_READ | PROT_WRITE);
else
igt_assert(false);
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index 1ed2b4a08c5d..1b92527ee50d 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -196,15 +196,16 @@ static void render_fb(data_t *data, uint32_t gem_handle, 
unsigned int size,
  enum test_fb_flags fb_flags,
  int height, unsigned int stride)
 {
-   uint32_t *ptr;
-   unsigned int half_height, half_size;
uint32_t uncompressed_color = data->plane ? GREEN : RED;
uint32_t compressed_color =
data->plane ? COMPRESSED_GREEN : COMPRESSED_RED;
+   size_t mmap_size = ALIGN(size, 4096);
uint32_t bad_color = RED;
+   unsigned int half_height, half_size;
+   uint32_t *ptr;
int i;
 
-   ptr = gem_mmap__cpu(data->drm_fd, gem_handle, 0, size,
+   ptr = gem_mmap__cpu(data->drm_fd, gem_handle, 0, mmap_size,
PROT_READ | PROT_WRITE);
 
if (fb_flags & FB_COMPRESSED) {
@@ -243,7 +244,7 @@ static void render_fb(data_t *data, uint32_t gem_handle, 
unsigned int size,
}
}
 
-   munmap(ptr, size);
+   munmap(ptr, mmap_size);
 }
 
 static unsigned int
@@ -259,6 +260,7 @@ static void render_ccs(data_t *data, uint32_t gem_handle,
   uint32_t offset, uint32_t size,
   int height, unsigned int ccs_stride)
 {
+   size_t mmap_size = ALIGN(size, 4096);
unsigned int half_height, ccs_half_height;
uint8_t *ptr;
int i;
@@ -266,7 +268,7 @@ static void render

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Acquire breadcrumb ref before cancelling

2019-03-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Acquire breadcrumb ref before cancelling
URL   : https://patchwork.freedesktop.org/series/57512/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693_full -> Patchwork_12358_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_pwrite@huge-gtt-backwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290] +1

  * igt@i915_pm_rpm@gem-execbuf-stress:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +10

  * igt@i915_selftest@live_contexts:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_atomic_transition@3x-modeset-transitions:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +13

  * igt@kms_busy@basic-modeset-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#107956] +2

  * igt@kms_chamelium@dp-edid-read:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-128x42-random:
- shard-skl:  NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl:  PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  PASS -> FAIL [fdo#105767]

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled:
- shard-skl:  PASS -> FAIL [fdo#103184]

  * igt@kms_fbcon_fbt@psr:
- shard-skl:  NOTRUN -> FAIL [fdo#103833]

  * igt@kms_flip@2x-flip-vs-panning-vs-hang:
- shard-iclb: NOTRUN -> SKIP [fdo#109274]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  NOTRUN -> FAIL [fdo#105363]

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-skl:  NOTRUN -> FAIL [fdo#103167] / [fdo#105682]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> SKIP [fdo#109280]

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167]

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- shard-skl:  NOTRUN -> FAIL [fdo#103191] / [fdo#107362]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-apl:  PASS -> FAIL [fdo#108948]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl:  NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl:  PASS -> FAIL [fdo#108145]
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  NOTRUN -> FAIL [fdo#107815]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-skl:  NOTRUN -> FAIL [fdo#103166] / [fdo#107815]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-apl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166] +3

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> INCOMPLETE [fdo#103665]

  * igt@kms_setmode@basic:
- shard-apl:  PASS -> FAIL [fdo#99912]

  * igt@kms_sysfs_edid_timing:
- shard-skl:  NOTRUN -> FAIL [fdo#100047]

  * igt@kms_universal_plane@cursor-fb-leak-pipe-d:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_universal_plane@universal-plane-pipe-b-functional:
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@kms_vrr@flip-suspend:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +136

  * igt@perf_pmu@busy-idle-check-all-bcs0:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@prime_busy@before-bsd2:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +31

  * igt@prime_nv_pcopy@test3_4:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +12

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries_display_off:
- shard-skl:  INCOMPLETE [fdo#104108] -> PASS +1

 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Simplify i830 DVO 2x clock handling

2019-03-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Simplify i830 DVO 2x clock handling
URL   : https://patchwork.freedesktop.org/series/57520/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5694 -> Patchwork_12361


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-icl-u2:  PASS -> FAIL [fdo#103375]

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   PASS -> SKIP [fdo#109271]

  * igt@i915_pm_rpm@basic-rte:
- fi-bsw-kefka:   PASS -> FAIL [fdo#108800]

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720]

  * igt@kms_busy@basic-flip-c:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +48

  * igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] / 
[fdo#109799]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   SKIP [fdo#109271] -> PASS

  * igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900:   FAIL [fdo#108800] -> PASS

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

  
 Warnings 

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: DMESG-FAIL [fdo#103182] -> FAIL [fdo#103182]

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

  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
  [fdo#109799]: https://bugs.freedesktop.org/show_bug.cgi?id=109799


Participating hosts (46 -> 41)
--

  Additional (1): fi-icl-y 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5694 -> Patchwork_12361

  CI_DRM_5694: daab510ef99070d4974e8408f34b465be5c3c0b7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4869: a958d3f60b7718151fd0bafcdd1e4874262f51b8 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12361: e3e055e0d9ad2ac6debaae39103260fb6356cfba @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e3e055e0d9ad drm/i915: Simplify i830 DVO 2x clock handling

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 0/7] drm/tinydrm: Remove tinydrm_device

2019-03-04 Thread Noralf Trønnes


Den 25.02.2019 15.42, skrev Noralf Trønnes:
> This patchset is part of the effort to remove tinydrm.ko. It removes
> struct tinydrm_device and tinydrm.h.
> 
> Only one change in this version and that is expanding the driver
> example.
> 
> The drm_dev_unplug() dependency series has been applied together with
> some patches from the previous version.
> 
> I've cc'ed intel-gfx so the Intel CI can verify the parent device ref
> patch.
> 
> Noralf.
> 
> Noralf Trønnes (7):
>   drm/drv: Hold ref on parent device during drm_device lifetime
>   drm: Add devm_drm_dev_init()
>   drm/drv: DOC: Add driver example code
>   drm/tinydrm/repaper: Drop using tinydrm_device
>   drm/tinydrm: Drop using tinydrm_device
>   drm/tinydrm: Remove tinydrm_device
>   drm/tinydrm: Use drm_dev_enter/exit()
> 

Series is applied to drm-misc-next, thanks for reviewing!

Noralf.

>  Documentation/driver-model/devres.txt |   3 +
>  Documentation/gpu/tinydrm.rst |  32 +---
>  Documentation/gpu/todo.rst|   4 -
>  drivers/gpu/drm/drm_drv.c | 176 +-
>  drivers/gpu/drm/tinydrm/core/Makefile |   2 +-
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c   | 169 -
>  .../gpu/drm/tinydrm/core/tinydrm-helpers.c|   2 +
>  drivers/gpu/drm/tinydrm/hx8357d.c |  49 -
>  drivers/gpu/drm/tinydrm/ili9225.c |  63 ++-
>  drivers/gpu/drm/tinydrm/ili9341.c |  49 -
>  drivers/gpu/drm/tinydrm/mi0283qt.c|  49 -
>  drivers/gpu/drm/tinydrm/mipi-dbi.c| 109 ---
>  drivers/gpu/drm/tinydrm/repaper.c | 130 +
>  drivers/gpu/drm/tinydrm/st7586.c  | 129 -
>  drivers/gpu/drm/tinydrm/st7735r.c |  49 -
>  include/drm/drm_drv.h |   3 +
>  include/drm/tinydrm/mipi-dbi.h|  26 ++-
>  include/drm/tinydrm/tinydrm.h |  42 -
>  18 files changed, 688 insertions(+), 398 deletions(-)
>  delete mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
>  delete mode 100644 include/drm/tinydrm/tinydrm.h
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [RFT i-g-t] lib/i915: Assert mmap size alignment

2019-03-04 Thread Chris Wilson
Quoting Tvrtko Ursulin (2019-03-04 14:11:31)
> From: Tvrtko Ursulin 
> 
> Fishing for fails...
> 
> /*
> mmap(2) mandates size is page aligned so check this in our wrappers.
> */
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  lib/i915/gem_mman.c |  4 
>  lib/igt_fb.c| 14 --
>  tests/kms_ccs.c | 14 --
>  tests/kms_psr.c |  8 
>  4 files changed, 24 insertions(+), 16 deletions(-)
> 
> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> index 3cf9a6bbdb31..084dbb3b3678 100644
> --- a/lib/i915/gem_mman.c
> +++ b/lib/i915/gem_mman.c
> @@ -57,6 +57,8 @@ void *__gem_mmap__gtt(int fd, uint32_t handle, uint64_t 
> size, unsigned prot)
> struct drm_i915_gem_mmap_gtt mmap_arg;
> void *ptr;
>  
> +   igt_assert(!(size & 4095));

Fwiw, it's probably best if we had some kind of IGT_BUG_ON() that caused
a much more visible explosion than a mere test failure.

#define IGT_BUG_ON(cond) if (!(cond)) raise(SIGILL)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix the state checker for ICL Y planes

2019-03-04 Thread Imre Deak
On Mon, Mar 04, 2019 at 03:12:17PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> The plane used to scan out NV12 luma on ICL is logically
> off but actually on. Fix the state checker to account for this.
> 
> Cc: Imre Deak 
> Cc: Maarten Lankhorst 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109457
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7c5e84ef5171..b49e789b747e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12589,7 +12589,8 @@ intel_verify_planes(struct intel_atomic_state *state)
>  
>   for_each_new_intel_plane_in_state(state, plane,
> plane_state, i)
> - assert_plane(plane, plane_state->base.visible);
> + assert_plane(plane, plane_state->slave ||
> +  plane_state->base.visible);

Looks like we don't have proper readout for such linked planes either,
but that's a separate issue. The change looks ok:

Reviewed-by: Imre Deak 

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix the state checker for ICL Y planes

2019-03-04 Thread Maarten Lankhorst
Op 04-03-2019 om 15:45 schreef Imre Deak:
> On Mon, Mar 04, 2019 at 03:12:17PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä 
>>
>> The plane used to scan out NV12 luma on ICL is logically
>> off but actually on. Fix the state checker to account for this.
>>
>> Cc: Imre Deak 
>> Cc: Maarten Lankhorst 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109457
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 7c5e84ef5171..b49e789b747e 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12589,7 +12589,8 @@ intel_verify_planes(struct intel_atomic_state *state)
>>  
>>  for_each_new_intel_plane_in_state(state, plane,
>>plane_state, i)
>> -assert_plane(plane, plane_state->base.visible);
>> +assert_plane(plane, plane_state->slave ||
>> + plane_state->base.visible);
> Looks like we don't have proper readout for such linked planes either,
> but that's a separate issue. The change looks ok:
>
> Reviewed-by: Imre Deak 

Reviewed-by: Maarten Lankhorst 

The lack of readout was intentional, I don't think we will ever be able to 
inherit nv12 planes from the bios. :)

But if we ever implement full plane validation, yeah that will be missing..

~Maarten

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix the state checker for ICL Y planes

2019-03-04 Thread Ville Syrjälä
On Mon, Mar 04, 2019 at 04:45:28PM +0200, Imre Deak wrote:
> On Mon, Mar 04, 2019 at 03:12:17PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > The plane used to scan out NV12 luma on ICL is logically
> > off but actually on. Fix the state checker to account for this.
> > 
> > Cc: Imre Deak 
> > Cc: Maarten Lankhorst 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109457
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7c5e84ef5171..b49e789b747e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12589,7 +12589,8 @@ intel_verify_planes(struct intel_atomic_state 
> > *state)
> >  
> > for_each_new_intel_plane_in_state(state, plane,
> >   plane_state, i)
> > -   assert_plane(plane, plane_state->base.visible);
> > +   assert_plane(plane, plane_state->slave ||
> > +plane_state->base.visible);
> 
> Looks like we don't have proper readout for such linked planes either,
> but that's a separate issue.

We have no real plane state readout for any plane. The only slight
exception is the initial_plane_config() stuff.

> The change looks ok:
> 
> Reviewed-by: Imre Deak 
> 
> >  }
> >  
> >  static void
> > -- 
> > 2.19.2
> > 

-- 
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 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

2019-03-04 Thread Heikki Krogerus
Hi Hans,

On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote:
> Hi Heikki,
> 
> On 28-02-19 15:47, Heikki Krogerus wrote:
> > Hi Hans,
> > 
> > On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 28-02-19 10:15, Heikki Krogerus wrote:
> 
> 
> 
> > > > I've been thinking about this... Do we actually need to link the
> > > > correct drm_connector to the Type-C connector? Perhaps we can make
> > > > this work by just linking the GFX device to the Type-C connector.
> > > 
> > > What use is it to the kms driver if it gets an event there is a DP
> > > hotplug with x lanes and orientation foo, if we are not telling it
> > > on which DP port it is ? kms devices already have multiple DP ports
> > > and more then one could be hooked-up to type-c connectors.
> > 
> > I was looking at this series. You walk trough every DP port in the
> > system when the DP alt mode driver broadcasts the event, but maybe
> > that's different. Never mind.
> 
> Right, my "simple / naive" solution simply tells the kms driver to
> check all DP ports for connection state changes, similar to how
> running "xrandr" under Xorg causes the kms driver to re-check the
> connection status of all ports. Actually running xrandr under Xorg
> after plugging in the cable, is how I did my initial DP over Type-C
> testing on the GPD win.
> 
> But once we start passing extra-info, I believe the kms driver needs
> to know to which connector that info belongs.
> 
> 
> 
> > > > Well, I don't think we can deny the GPU driver (in this case) the
> > > > information that we have and that is relevant to it, just because it
> > > > seems difficult to deliver that information to the right location.
> > > 
> > > Right, but this does not require a tight-coupling. My original
> > > proposal can do this if we pass a data struct with an identifier
> > > for the DP port for which the event is to the notifier. I suggest using
> > > a string for identifier, something like: ":00:02.0/DP-1" this
> > > event struct could then also contain all the info we want to pass.
> > 
> > I do agree that we should not tie the objects (device entries)
> > representing these components in kernel together, but I assume that we
> > agree now that the connection between the two - the USB Type-C
> > connector and the DisplayPort - must be described somewhere, either in
> > firmware or build-in? So I guess we are talking implementation details
> > here, right?
> 
> Right.
> 
> > If that is the case...
> > 
> > That string identifier you proposed would basically provide the
> > details about the connection, so if we know those details, we might as
> > well use "normal" ways to describe the connection and just extract
> > them in runtime in the function that our DP alt mode driver calls. I
> > think the connection has to be defined in i915 on CHT in any case.
> 
> Interesting, I think the connection should be described in the fwnode
> for the fusb302 device for the CHT/GPD win case. Specifically I think
> this fits well as a property of the dp altmode.

OK, you are correct. I was stupidly still thinking about the driver
loading order, but the order does not matter.

> > The DP alt mode driver should definitely not need to pass anything
> > else to the notifier other than handle to itself (actually, handle
> > straight to the port device would be better) as an identifier. The
> > notifier function needs to be the one that determines the actual
> > connection using that handle. Even if the target DP is described using
> > a string like you propose, then that string has to come from
> > somewhere, most likely from a device property. The notifier function
> > can just as well extract it, we don't need to pass it separately.
> > 
> > Here's my suggestion for function prototype:
> > 
> > int drm_typec_dp_notification(struct device *typec_port_dev,
> >struct typec_displayport_data *data);
> 
> How about instead of the port_dev we pass in the altmode object and
> we have a method to get the fwnode for the altmode? Then the
> drm_typec_dp_notification() function can get info from that fwnode
> to implement the connection finding you describe below:

We can pass the altmode object, np, but let's not decide which fwnode
we'll ultimately use. I'm still leaning towards the connector node.

> > So that function finds the connection between typec_port_dev and the
> > correct DP in runtime, possibly by letting i915 (or what ever GPU
> > driver) to do that. Once the function is done, it decrements any ref
> > counts that it incremented before returning.
> > 
> > That struct typec_displayport_data has all the information we have -
> > the current pin assignment from the Configure VDO, HPD IRQ from the
> > last Status Update, etc. - so it needs to be passed as payload to the
> > notifier.
> 
> Ack.
> 
> So I believe that this discussion ties into the discussion from the:
> "[PATCH 0/2] platform/x86: intel_cht_int33fe: Start using sof

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

2019-03-04 Thread Rodrigo Siqueira
The last few weeks, I have been dive into the page flip and vblank with
the goal to learn how the user space interact with DRM; because of this,
I am studying the kms_flip code. As a result, I noticed a bunch of
cleanups that could be useful for improving the overall quality of
kms_flip. This patchset can be seen in two parts:

 1. Eliminates unreachable tests
 2. Basic cleanups with the goal to improve the code readability

In particular, the patch number three enables kms_flip to work without
any issue in any non-intel drivers.

Rodrigo Siqueira (7):
  kms_flip: Removes unreachable code related to TEST_RPM
  kms_flip: Removes unreachable code related to TEST_TS_CONT
  kms_flip: Fix warning related to i915 gem dependence
  kms_flip: Remove unreachable condition in wait_for_events
  kms_flip: remove magic constant in run_test_on_crtc_set()
  kms_flip: Rework set_mode()
  kms_flip: Standardize return value for fb_is_bound

 tests/kms_flip.c | 88 +---
 1 file changed, 31 insertions(+), 57 deletions(-)

-- 
2.21.0


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

[Intel-gfx] [PATCH i-g-t 1/7] kms_flip: Removes unreachable code related to TEST_RPM

2019-03-04 Thread Rodrigo Siqueira
This commit removes the code related to TEST_RPM test because the
kms_flip never sets this flags, i.e., TEST_RPM is not used. Take a look
at commit 07a3fccf to see why this flag is never set.

Signed-off-by: Rodrigo Siqueira 
---
 tests/kms_flip.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 798fc4e8..f769d30e 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -68,7 +68,6 @@
 #define TEST_ENOENT(1 << 22)
 #define TEST_FENCE_STRESS  (1 << 23)
 #define TEST_VBLANK_RACE   (1 << 24)
-#define TEST_RPM   (1 << 25)
 #define TEST_SUSPEND   (1 << 26)
 #define TEST_TS_CONT   (1 << 27)
 #define TEST_BO_TOOBIG (1 << 28)
@@ -809,9 +808,6 @@ static unsigned int run_test_step(struct test_output *o)
 "failed to disable output: %s\n",
 strerror(errno));
 
-   if (o->flags & TEST_RPM)
-   
igt_assert(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED));
-
if (o->flags & TEST_SUSPEND)
igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
  SUSPEND_TEST_NONE);
@@ -1321,9 +1317,6 @@ static int run_test(int duration, int flags)
 
igt_require((flags & TEST_HANG) == 0 || !is_wedged(drm_fd));
 
-   if (flags & TEST_RPM)
-   igt_require(igt_setup_runtime_pm());
-
resources = drmModeGetResources(drm_fd);
igt_require(resources);
 
@@ -1570,10 +1563,6 @@ int main(int argc, char **argv)
if (tests[i].flags & TEST_NO_2X_OUTPUT)
continue;
 
-   /* code doesn't disable all crtcs, so skip rpm tests */
-   if (tests[i].flags & TEST_RPM)
-   continue;
-
igt_subtest_f( "2x-%s", tests[i].name)
run_pair(tests[i].duration, tests[i].flags);
}
@@ -1592,10 +1581,6 @@ int main(int argc, char **argv)
if (tests[i].flags & TEST_NO_2X_OUTPUT)
continue;
 
-   /* code doesn't disable all crtcs, so skip rpm tests */
-   if (tests[i].flags & TEST_RPM)
-   continue;
-
igt_subtest_f( "2x-%s-interruptible", tests[i].name)
run_pair(tests[i].duration, tests[i].flags);
}
-- 
2.21.0


-- 
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo


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

[Intel-gfx] [PATCH i-g-t 2/7] kms_flip: Removes unreachable code related to TEST_TS_CONT

2019-03-04 Thread Rodrigo Siqueira
This commit removes the code related to TEST_TS_CONT test because the
kms_flip never sets this flags, i.e., TEST_TS_CONT is not used. Take a
look at commit 07a3fccf to see why this flag is never set.

Signed-off-by: Rodrigo Siqueira 
---
 tests/kms_flip.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index f769d30e..0d261b77 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -69,7 +69,6 @@
 #define TEST_FENCE_STRESS  (1 << 23)
 #define TEST_VBLANK_RACE   (1 << 24)
 #define TEST_SUSPEND   (1 << 26)
-#define TEST_TS_CONT   (1 << 27)
 #define TEST_BO_TOOBIG (1 << 28)
 
 #define TEST_BASIC (1 << 30)
@@ -497,21 +496,6 @@ static void check_state(const struct test_output *o, const 
struct event_state *e
 "unexpected %s seq %u, should be >= %u\n",
 es->name, es->current_seq, es->last_seq + 
o->seq_step);
 
-   /* Check that the vblank frame didn't wrap unexpectedly. */
-   if (o->flags & TEST_TS_CONT) {
-   /* Ignore seq_step here since vblank waits time out immediately
-* when we kill the crtc. */
-   igt_assert_f(es->current_seq - es->last_seq >= 0,
-"unexpected %s seq %u, should be >= %u\n",
-es->name, es->current_seq, es->last_seq);
-   igt_assert_f(es->current_seq - es->last_seq <= 150,
-"unexpected %s seq %u, should be < %u\n",
-es->name, es->current_seq, es->last_seq + 150);
-
-   igt_debug("testing ts continuity: Current frame %u, old frame 
%u\n",
- es->current_seq, es->last_seq);
-   }
-
if (o->flags & TEST_CHECK_TS) {
double elapsed, expected;
 
-- 
2.21.0


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

[Intel-gfx] [PATCH i-g-t 3/7] kms_flip: Fix warning related to i915 gem dependence

2019-03-04 Thread Rodrigo Siqueira
In the kms_flip tests has an igt_fixture that allocates memory for i915
driver with “drm_intel_bufmgr_gem_init()”, which produces the following
warning:

 IGT-Version: 1.23-g8d81c2c2 (x86_64) (Linux: 5.0.0-rc7-VKMS-RULES+ x86_64)
 Using monotonic timestamps
 DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
 Assuming 131072kB available aperture size.
 May lead to reduced performance or incorrect rendering.
 get chip id failed: -1 [22]

This commit handles this specific dependence with the i915 driver which
make the kms_flip logs better.

Signed-off-by: Rodrigo Siqueira 
---
 tests/kms_flip.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 0d261b77..57138ec1 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1528,10 +1528,12 @@ int main(int argc, char **argv)
igt_install_exit_handler(kms_flip_exit_handler);
get_timestamp_format();
 
-   bufmgr = drm_intel_bufmgr_gem_init(drm_fd, 4096);
-   if (bufmgr) {
-   devid = intel_get_drm_devid(drm_fd);
-   batch = intel_batchbuffer_alloc(bufmgr, devid);
+   if (is_i915_device(drm_fd)) {
+   bufmgr = drm_intel_bufmgr_gem_init(drm_fd, 4096);
+   if (bufmgr) {
+   devid = intel_get_drm_devid(drm_fd);
+   batch = intel_batchbuffer_alloc(bufmgr, devid);
+   }
}
}
 
-- 
2.21.0


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

[Intel-gfx] [PATCH i-g-t 4/7] kms_flip: Remove unreachable condition in wait_for_events

2019-03-04 Thread Rodrigo Siqueira
In the function wait_for_events() has a double check in the select()
function return as described below:

  igt_assert_f(ret >= 0,
"select error (errno %i)\n", errno);
  igt_assert_f(ret > 0,
"select timed out or error (ret %d)\n", ret);

Note that the second assert condition will not be reached because of the
first assertion. This commit removes the code duplication and update the
error message.

Signed-off-by: Rodrigo Siqueira 
---
 tests/kms_flip.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 57138ec1..9ef77de9 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1014,9 +1014,7 @@ static unsigned int wait_for_events(struct test_output *o)
} while (ret < 0 && errno == EINTR);
 
igt_assert_f(ret >= 0,
-"select error (errno %i)\n", errno);
-   igt_assert_f(ret > 0,
-"select timed out or error (ret %d)\n", ret);
+"select error: %s (%d))\n", strerror(errno), ret);
igt_assert_f(!FD_ISSET(0, &fds),
 "no fds active, breaking\n");
 
-- 
2.21.0


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

[Intel-gfx] [PATCH i-g-t 5/7] kms_flip: Remove magic constant in run_test_on_crtc_set()

2019-03-04 Thread Rodrigo Siqueira
The function run_test_on_crtc_set() expects a parameter named crtc_count
which slight changes the behavior of the test. If this crtc_count is
‘1’, the test will run in a single CRTC; otherwise, it will run in two
different CRTC. However, this function uses hardcoded literal 1 and 2
for each case. This patch creates two constant with the goal to improve
the readability.

Signed-off-by: Rodrigo Siqueira 
---
 tests/kms_flip.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 9ef77de9..42ae3ebc 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -76,6 +76,9 @@
 #define EVENT_FLIP (1 << 0)
 #define EVENT_VBLANK   (1 << 1)
 
+#define RUN_TEST   1
+#define RUN_PAIR   2
+
 #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
 #define DRM_CAP_TIMESTAMP_MONOTONIC 6
 #endif
@@ -1164,7 +1167,7 @@ static void run_test_on_crtc_set(struct test_output *o, 
int *crtc_idxs,
int i;
 
switch (crtc_count) {
-   case 1:
+   case RUN_TEST:
connector_find_preferred_mode(o->_connector[0], crtc_idxs[0], 
o);
if (!o->mode_valid)
return;
@@ -1175,7 +1178,7 @@ static void run_test_on_crtc_set(struct test_output *o, 
int *crtc_idxs,
 
kmstest_connector_type_str(o->kconnector[0]->connector_type),
 o->kconnector[0]->connector_type_id);
break;
-   case 2:
+   case RUN_PAIR:
connector_find_compatible_mode(crtc_idxs[0], crtc_idxs[1], o);
if (!o->mode_valid)
return;
@@ -1341,7 +1344,7 @@ static int run_test(int duration, int flags)
o.depth = 24;
 
crtc_idx = n;
-   run_test_on_crtc_set(&o, &crtc_idx, 1, duration);
+   run_test_on_crtc_set(&o, &crtc_idx, RUN_TEST, duration);
}
}
 
@@ -1410,7 +1413,8 @@ static int run_pair(int duration, int flags)
crtc_idxs[0] = n;
crtc_idxs[1] = m;
 
-   run_test_on_crtc_set(&o, crtc_idxs, 2,
+   run_test_on_crtc_set(&o, crtc_idxs,
+RUN_PAIR,
 duration);
}
}
-- 
2.21.0


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

[Intel-gfx] [PATCH i-g-t 6/7] kms_flip: Rework set_mode()

2019-03-04 Thread Rodrigo Siqueira
This patch removes the duplicate code inside the function set_mode().

Signed-off-by: Rodrigo Siqueira 
---
 tests/kms_flip.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 42ae3ebc..de3ab600 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -609,22 +609,24 @@ static bool is_wedged(int fd)
 
 static int set_mode(struct test_output *o, uint32_t fb, int x, int y)
 {
-   int n;
+   int n, ret;
 
for (n = o->count - 1; n >= 0; n--) {
+   uint32_t buffer_id = fb, x_crtc = x, y_crtc = y;
+   uint32_t *conn = &o->_connector[n];
+   int count = 1;
+   drmModeModeInfoPtr mode = &o->kmode[n];
+
if (fb == 0) {
-   int ret = drmModeSetCrtc(drm_fd, o->_crtc[n],
-0, 0, 0,
-0, 0, 0);
-   if (ret)
-   return ret;
-   } else {
-   int ret = drmModeSetCrtc(drm_fd, o->_crtc[n],
-fb, x, y,
-&o->_connector[n], 1, 
&o->kmode[n]);
-   if (ret)
-   return ret;
+   buffer_id = x_crtc = y_crtc = count = 0;
+   conn = NULL; mode = NULL;
}
+
+   ret = drmModeSetCrtc(drm_fd, o->_crtc[n],
+buffer_id, x_crtc, y_crtc,
+conn, count, mode);
+   if (ret)
+   return ret;
}
 
return 0;
-- 
2.21.0


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

[Intel-gfx] [PATCH i-g-t 7/7] kms_flip: Standardize return value for fb_is_bound

2019-03-04 Thread Rodrigo Siqueira
The function fb_is_bound() mix integer value with booleans for handling
the return value. This commit standardizes the return value of
fb_is_bound() for using only booleans.

Signed-off-by: Rodrigo Siqueira 
---
 tests/kms_flip.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index de3ab600..abfdd363 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -947,8 +947,7 @@ static void paint_flip_mode(struct igt_fb *fb, bool 
odd_frame)
igt_put_cairo_ctx(drm_fd, fb, cr);
 }
 
-static int
-fb_is_bound(struct test_output *o, int fb)
+static bool fb_is_bound(struct test_output *o, int fb)
 {
int n;
 
@@ -958,7 +957,7 @@ fb_is_bound(struct test_output *o, int fb)
};
 
if (drmIoctl(drm_fd, DRM_IOCTL_MODE_GETCRTC, &mode))
-   return 0;
+   return false;
 
if (!mode.mode_valid || mode.fb_id != fb)
return false;
-- 
2.21.0


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

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)

2019-03-04 Thread Patchwork
== Series Details ==

Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats (rev5)
URL   : https://patchwork.freedesktop.org/series/56606/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5693_full -> Patchwork_12359_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- shard-skl:  NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773]

  * igt@gem_pwrite@huge-gtt-backwards:
- shard-iclb: NOTRUN -> SKIP [fdo#109290] +1

  * igt@i915_pm_rpm@fences-dpms:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]

  * igt@i915_pm_rpm@modeset-lpsp-stress:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +4

  * igt@i915_selftest@live_contexts:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_atomic_transition@4x-modeset-transitions-nonblocking-fencing:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_chamelium@dp-edid-read:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_color@pipe-c-legacy-gamma:
- shard-apl:  PASS -> FAIL [fdo#104782]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +2

  * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled:
- shard-skl:  PASS -> FAIL [fdo#103184]

  * igt@kms_fbcon_fbt@psr:
- shard-skl:  NOTRUN -> FAIL [fdo#103833]

  * igt@kms_flip@2x-flip-vs-panning-vs-hang:
- shard-iclb: NOTRUN -> SKIP [fdo#109274]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +2

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> SKIP [fdo#109280]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-glk:  PASS -> FAIL [fdo#103167]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_plane@pixel-format-pipe-c-planes:
- shard-apl:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  PASS -> SKIP [fdo#109271] +4

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl:  NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-skl:  NOTRUN -> FAIL [fdo#103166] / [fdo#107815]

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-glk:  PASS -> FAIL [fdo#103166] +2

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166]

  * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +7

  * igt@kms_setmode@basic:
- shard-apl:  PASS -> FAIL [fdo#99912]
- shard-iclb: NOTRUN -> FAIL [fdo#99912]

  * igt@kms_sysfs_edid_timing:
- shard-skl:  NOTRUN -> FAIL [fdo#100047]

  * igt@kms_universal_plane@cursor-fb-leak-pipe-d:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_vblank@pipe-c-ts-continuation-modeset-rpm:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@kms_vrr@flip-suspend:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +79

  * igt@prime_busy@before-bsd2:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +31

  * igt@tools_test@tools_test:
- shard-iclb: PASS -> SKIP [fdo#109352]

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries_display_off:
- shard-skl:  INCOMPLETE [fdo#104108] -> PASS +1

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS

  * igt@kms_atomic_transition@1x-modeset-transitions-fencing:
- shard-skl:  FAIL [fdo#107815] / [fdo#108470] -> PASS

  * igt@kms_ccs@pipe-a-crc-primary-basic:
- shard-skl:  FAIL [fdo#107725] -> PASS

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  FAIL [fdo#106510] / [fdo#108145] -> PASS +1

  * igt@kms_color@pipe-b-legacy-gamma:
- shard-apl:  FAIL [fdo#104782] -> PASS

  * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-ytiled:
- shard-skl:  FAIL [fdo#103184] -

Re: [Intel-gfx] [PATCH] drm/i915: Simplify i830 DVO 2x clock handling

2019-03-04 Thread Chris Wilson
Quoting Ville Syrjala (2019-03-04 13:41:13)
> From: Ville Syrjälä 
> 
> Let's just always enable the DVO 2x clock on i830. This way we don't
> have to track if DVO is being used or not. The spec does suggest we
> should disable the clock when it isn't needed, but this does appear
> to work just fine.

And after i830, 2X_MODE seems to be the default? Whereas the only reason
for i830 being special is that both pipes must be using the same mode,
ergo we didn't do either (or something like that).

> This removes another crtc->config usage.
> 
> Signed-off-by: Ville Syrjälä 
> ---
> @@ -1468,26 +1455,12 @@ static void i9xx_enable_pll(struct intel_crtc *crtc,
> /*
>  * Apparently we need to have VGA mode enabled prior to changing
>  * the P1/P2 dividers. Otherwise the DPLL will keep using the old
>  * dividers, even though the register value does change.
>  */
> -   I915_WRITE(reg, 0);
> -
> +   I915_WRITE(reg, dpll & ~DPLL_VGA_MODE_DIS);

This looks to be a separate tweak?

> I915_WRITE(reg, dpll);
>  
> /* Wait for the clocks to stabilize. */

> @@ -7494,7 +7457,19 @@ static void i8xx_compute_dpll(struct intel_crtc *crtc,
> dpll |= PLL_P2_DIVIDE_BY_4;
> }
>  
> -   if (!IS_I830(dev_priv) &&
> +   /*
> +* Bspec:
> +* "[Almador Errata}: For the correct operation of the muxed DVO pins
> +*  (GDEVSELB/ I 2 Cdata, GIRDBY/I 2 CClk) and (GFRAMEB/DVI_Data,
> +*  GTRDYB/DVI_Clk): Bit 31 (DPLL VCO Enable) and Bit 30 (2X Clock
> +*  Enable) must be set to “1” in both the DPLL A Control Register
> +*  (06014h-06017h) and DPLL B Control Register (06018h-0601Bh)."
> +*
> +* For simplicity We simply keep both bits always enabled in
> +* both DPLLS. The spec says we should disable the DVO 2X clock
> +* when not needed, but this seems to work fine in practice.
> +*/
> +   if (IS_I830(dev_priv) ||
> intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DVO))
> dpll |= DPLL_DVO_2X_MODE;

Is VGA/CRT a native encoder? That might be a useful test to check that
still works.

I couldn't see anything you missed for DPLL_DVO_2X_MODE, so happy that
this does what it says on the tin, and I trust that you actually ran
this on an i830...

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Rename i915_load_modeset_init() to i915_modeset_load()

2019-03-04 Thread Lucas De Marchi

On Mon, Mar 04, 2019 at 01:00:40PM +0200, Jani Nikula wrote:

On Fri, 01 Mar 2019, José Roberto de Souza  wrote:

i915_load_modeset_init() sounds horrible also lets rename it so
the future cleanup function of it can be easially recognized.


We load the driver, but init modeset. The name implies modeset init at
driver load.

The modeset load/unload sounds a bit odd to me. Even more so with
begin/finish load and begin unload. It's not obvious to me what those
should do. They're not a pattern we have.

I'm not all that averse to renaming stuff in general, but any rename
increases the cognitive burden for a while, and should make things
*easier* to understand. I don't think that's the case in this series.

I can understand i915_load_modeset_init sounding funny. If you insist on
renaming, I'd go with i915_driver_modeset_init. It's in line with the
rest of the functions.

Here are my suggestions for the names:

i915_modeset_load/i915_modeset_begin_load
-> i915_driver_modeset_init

i915_modeset_unload/i915_modeset_begin_unload
-> i915_driver_modeset_cleanup or _fini

i915_modeset_finish_load
-> i915_driver_modeset_init_late


+1 for the name suggestions

Lucas De Marchi




BR,
Jani.




Cc: Lucas De Marchi 
Cc: Jani Nikula 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c08abdef5eb6..90c77fab3d70 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -639,7 +639,7 @@ static const struct vga_switcheroo_client_ops 
i915_switcheroo_ops = {
.can_switch = i915_switcheroo_can_switch,
 };

-static int i915_load_modeset_init(struct drm_device *dev)
+static int i915_modeset_load(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
@@ -1748,7 +1748,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_mmio;

-   ret = i915_load_modeset_init(&dev_priv->drm);
+   ret = i915_modeset_load(&dev_priv->drm);
if (ret < 0)
goto out_cleanup_hw;


--
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 01/12] drm/i915: Store DIMM rank information as a number

2019-03-04 Thread Jani Nikula
On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Life will be easier later if we have the ranks stored
> as a bare number.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 92 +++--
>  drivers/gpu/drm/i915/i915_drv.h | 11 ++--
>  2 files changed, 45 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c6354f6cdbdb..48c6bc44072d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1068,28 +1068,28 @@ static void intel_sanitize_options(struct 
> drm_i915_private *dev_priv)
>   intel_gvt_sanitize_options(dev_priv);
>  }
>  
> -static enum dram_rank skl_get_dimm_rank(u8 size, u32 rank)
> +static int skl_get_dimm_ranks(u8 size, u32 rank)
>  {
>   if (size == 0)
> - return I915_DRAM_RANK_INVALID;
> + return 0;
>   if (rank == SKL_DRAM_RANK_SINGLE)
> - return I915_DRAM_RANK_SINGLE;
> + return 1;
>   else if (rank == SKL_DRAM_RANK_DUAL)
> - return I915_DRAM_RANK_DUAL;
> + return 2;
>  
> - return I915_DRAM_RANK_INVALID;
> + return 0;
>  }
>  
>  static bool
> -skl_is_16gb_dimm(enum dram_rank rank, u8 size, u8 width)
> +skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
>  {
> - if (rank == I915_DRAM_RANK_SINGLE && width == 8 && size == 16)
> + if (ranks == 1 && width == 8 && size == 16)
>   return true;
> - else if (rank == I915_DRAM_RANK_DUAL && width == 8 && size == 32)
> + else if (ranks == 2 && width == 8 && size == 32)
>   return true;
> - else if (rank == SKL_DRAM_RANK_SINGLE && width == 16 && size == 8)
> + else if (ranks == 1 && width == 16 && size == 8)
>   return true;
> - else if (rank == SKL_DRAM_RANK_DUAL && width == 16 && size == 16)
> + else if (ranks == 2 && width == 16 && size == 16)
>   return true;
>  
>   return false;
> @@ -1120,28 +1120,24 @@ skl_dram_get_channel_info(struct dram_channel_info 
> *ch, u32 val)
>  
>   tmp_l = val & SKL_DRAM_RANK_MASK;
>   tmp_s = s_val & SKL_DRAM_RANK_MASK;
> - ch->l_info.rank = skl_get_dimm_rank(ch->l_info.size, tmp_l);
> - ch->s_info.rank = skl_get_dimm_rank(ch->s_info.size, tmp_s);
> -
> - if (ch->l_info.rank == I915_DRAM_RANK_DUAL ||
> - ch->s_info.rank == I915_DRAM_RANK_DUAL)
> - ch->rank = I915_DRAM_RANK_DUAL;
> - else if (ch->l_info.rank == I915_DRAM_RANK_SINGLE &&
> -  ch->s_info.rank == I915_DRAM_RANK_SINGLE)
> - ch->rank = I915_DRAM_RANK_DUAL;
> + ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
> + ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
> +
> + if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
> + ch->ranks = 2;
> + else if (ch->l_info.ranks == 1 && ch->s_info.ranks == 1)
> + ch->ranks = 2;
>   else
> - ch->rank = I915_DRAM_RANK_SINGLE;
> + ch->ranks = 1;
>  
> - ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.rank, ch->l_info.size,
> + ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
>   ch->l_info.width) ||
> -skl_is_16gb_dimm(ch->s_info.rank, ch->s_info.size,
> +skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
>   ch->s_info.width);
>  
> - DRM_DEBUG_KMS("(size:width:rank) L(%dGB:X%d:%s) S(%dGB:X%d:%s)\n",
> -   ch->l_info.size, ch->l_info.width,
> -   ch->l_info.rank ? "dual" : "single",
> -   ch->s_info.size, ch->s_info.width,
> -   ch->s_info.rank ? "dual" : "single");

I don't understand how the above ternary operators could ever have
produced the right results before.

> + DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
> +   ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
> +   ch->s_info.size, ch->s_info.width, ch->s_info.ranks);

%u instead of %d? Ditto for all debug prints.

Reviewed-by: Jani Nikula 


>  
>   return 0;
>  }
> @@ -1154,7 +1150,7 @@ intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
>   (ch0->s_info.size == 0 ||
>(ch0->l_info.size == ch0->s_info.size &&
> ch0->l_info.width == ch0->s_info.width &&
> -   ch0->l_info.rank == ch0->s_info.rank)));
> +   ch0->l_info.ranks == ch0->s_info.ranks)));
>  }
>  
>  static int
> @@ -1185,13 +1181,12 @@ skl_dram_get_channels_info(struct drm_i915_private 
> *dev_priv)
>* will be same as if single rank memory, so consider single rank
>* memory.
>*/
> - if (ch0.rank == I915_DRAM_RANK_SINGLE ||
> - ch1.rank == I915_DRAM_RANK_SINGLE)
> - dram_info->rank = I915_DRAM_

Re: [Intel-gfx] [PATCH] drm/i915: Simplify i830 DVO 2x clock handling

2019-03-04 Thread Ville Syrjälä
On Mon, Mar 04, 2019 at 03:52:30PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-03-04 13:41:13)
> > From: Ville Syrjälä 
> > 
> > Let's just always enable the DVO 2x clock on i830. This way we don't
> > have to track if DVO is being used or not. The spec does suggest we
> > should disable the clock when it isn't needed, but this does appear
> > to work just fine.
> 
> And after i830, 2X_MODE seems to be the default? Whereas the only reason
> for i830 being special is that both pipes must be using the same mode,
> ergo we didn't do either (or something like that).

Post i830 the hw was fixed so we only have to enable the 2x clock
when the pipe is driving a DVO port. Driving the CRT and LVDS ports
does not require the 2x clock.

> 
> > This removes another crtc->config usage.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> > @@ -1468,26 +1455,12 @@ static void i9xx_enable_pll(struct intel_crtc *crtc,
> > /*
> >  * Apparently we need to have VGA mode enabled prior to changing
> >  * the P1/P2 dividers. Otherwise the DPLL will keep using the old
> >  * dividers, even though the register value does change.
> >  */
> > -   I915_WRITE(reg, 0);
> > -
> > +   I915_WRITE(reg, dpll & ~DPLL_VGA_MODE_DIS);
> 
> This looks to be a separate tweak?

I didn't want to termporarily disable the DPLL, even for a miniscule
amount of time. Since the old code did work I suppose it's not
really needed, but this seems more consistent with the whole premise
of keeping both DPLLs on all the time.

I suppose I could extract this to a separate patch for clarity.

> 
> > I915_WRITE(reg, dpll);
> >  
> > /* Wait for the clocks to stabilize. */
> 
> > @@ -7494,7 +7457,19 @@ static void i8xx_compute_dpll(struct intel_crtc 
> > *crtc,
> > dpll |= PLL_P2_DIVIDE_BY_4;
> > }
> >  
> > -   if (!IS_I830(dev_priv) &&
> > +   /*
> > +* Bspec:
> > +* "[Almador Errata}: For the correct operation of the muxed DVO 
> > pins
> > +*  (GDEVSELB/ I 2 Cdata, GIRDBY/I 2 CClk) and (GFRAMEB/DVI_Data,
> > +*  GTRDYB/DVI_Clk): Bit 31 (DPLL VCO Enable) and Bit 30 (2X Clock
> > +*  Enable) must be set to “1” in both the DPLL A Control Register
> > +*  (06014h-06017h) and DPLL B Control Register (06018h-0601Bh)."
> > +*
> > +* For simplicity We simply keep both bits always enabled in
> > +* both DPLLS. The spec says we should disable the DVO 2X clock
> > +* when not needed, but this seems to work fine in practice.
> > +*/
> > +   if (IS_I830(dev_priv) ||
> > intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DVO))
> > dpll |= DPLL_DVO_2X_MODE;
> 
> Is VGA/CRT a native encoder? That might be a useful test to check that
> still works.

Yes, and yes it still works.

> 
> I couldn't see anything you missed for DPLL_DVO_2X_MODE, so happy that
> this does what it says on the tin, and I trust that you actually ran
> this on an i830...

Indeed I did. And I also tested the 's/0/dpll & ~DPLL_VGA_MODE_DIS/'
change on my ctg as those are known to suffer from the p1/p2 dividers
not latching issue. The new sequence still forces p1/p2 to latch.

> 
> Reviewed-by: Chris Wilson 

Thanks. 

-- 
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] drm/i915: Acquire breadcrumb ref before cancelling

2019-03-04 Thread Tvrtko Ursulin


On 04/03/2019 11:41, Chris Wilson wrote:

We may race the interrupt signaling with retirement, in which case the
order in which we acquire the reference inside the interrupt is vital to
provide the correct barrier against the request being freed in
retirement, i.e. we need to acquire our reference before marking the
breadcrumb as cancelled (as soon as the breadcrumb is cancelled
retirement may drop its reference to the request without serialisation
with the interrupt handler).

<3>[  683.372226] BUG i915_request (Tainted: G U   ): Object 
already free
<3>[  683.372269] 
-

<4>[  683.372323] Disabling lock debugging due to kernel taint
<3>[  683.372393] INFO: Allocated in i915_request_alloc+0x169/0x810 [i915] 
age=0 cpu=2 pid=1420
<3>[  683.372412] kmem_cache_alloc+0x21c/0x280
<3>[  683.372478] i915_request_alloc+0x169/0x810 [i915]
<3>[  683.372540] i915_gem_do_execbuffer+0x84e/0x1ae0 [i915]
<3>[  683.372603] i915_gem_execbuffer2_ioctl+0x11b/0x420 [i915]
<3>[  683.372617] drm_ioctl_kernel+0x83/0xf0
<3>[  683.372626] drm_ioctl+0x2f3/0x3b0
<3>[  683.372636] do_vfs_ioctl+0xa0/0x6e0
<3>[  683.372645] ksys_ioctl+0x35/0x60
<3>[  683.372654] __x64_sys_ioctl+0x11/0x20
<3>[  683.372664] do_syscall_64+0x55/0x190
<3>[  683.372675] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<3>[  683.372740] INFO: Freed in i915_request_retire_upto+0xfb/0x2e0 [i915] 
age=0 cpu=0 pid=1419
<3>[  683.372807] i915_request_retire_upto+0xfb/0x2e0 [i915]
<3>[  683.372870] i915_request_add+0x3bd/0x9d0 [i915]
<3>[  683.372931] i915_gem_do_execbuffer+0x141c/0x1ae0 [i915]
<3>[  683.372991] i915_gem_execbuffer2_ioctl+0x11b/0x420 [i915]
<3>[  683.373001] drm_ioctl_kernel+0x83/0xf0
<3>[  683.373008] drm_ioctl+0x2f3/0x3b0
<3>[  683.373015] do_vfs_ioctl+0xa0/0x6e0
<3>[  683.373023] ksys_ioctl+0x35/0x60
<3>[  683.373030] __x64_sys_ioctl+0x11/0x20
<3>[  683.373037] do_syscall_64+0x55/0x190
<3>[  683.373045] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<3>[  683.373054] INFO: Slab 0x79bcdd71 objects=30 used=2 
fp=0x6d77b8af flags=0x80010201
<3>[  683.373069] INFO: Object 0x6d77b8af @offset=24000 
fp=0x7b061eab

<3>[  683.373083] Redzone ee47ef28: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373097] Redzone 0cb91471: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373111] Redzone cf2b86ee: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373125] Redzone f1f5a2cd: bb bb bb bb bb bb bb bb bb bb bb bb 
bb bb bb bb  
<3>[  683.373139] Object 6d77b8af: 00 00 00 00 5a 5a 5a 5a 00 3c 49 c0 ff 
ff ff ff  .[  683.373153] Object 6f9b6204: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 
5a 5a 5a 5a  
<3>[  683.373167] Object 91410ffb: e0 dd 6b fa 87 9f ff ff e0 dd 6b fa 
87 9f ff ff  ..k...k.
<3>[  683.373181] Object 4cdf799d: 20 de 6b fa 87 9f ff ff 3d 00 00 00 
00 00 00 00   .k.=...
<3>[  683.373195] Object 545afebc: aa b3 00 00 00 00 00 00 0f 00 00 00 
00 00 00 00  
<3>[  683.373209] Object e4a394a8: 25 bd bd 1b 9f 00 00 00 00 00 00 00 
5a 5a 5a 5a  %...
<3>[  683.373223] Object 29a7878a: 00 00 00 00 ad 4e ad de ff ff ff ff 
5a 5a 5a 5a  .N..
<3>[  683.373237] Object d37797b3: ff ff ff ff ff ff ff ff e8 6e 57 c0 
ff ff ff ff  .nW.
<3>[  683.373251] Object d50414f6: 00 b3 c8 8e ff ff ff ff 80 b0 c8 8e 
ff ff ff ff  
<3>[  683.373265] Object c28e8847: 41 01 4b c0 ff ff ff ff 00 00 88 8e 
88 9f ff ff  A.K.
<3>[  683.373279] Object c74212ab: 38 c1 6d 8a 88 9f ff ff 58 21 74 8a 
88 9f ff ff  8.m.X!t.
<3>[  683.373293] Object 0d8012cf: c0 c1 6d 8a 88 9f ff ff 58 79 dd d9 
87 9f ff ff  ..m.Xy..
<3>[  683.373306] Object c9900b91: 98 d0 4e 8a 88 9f ff ff 58 3c e8 9b 88 
9f ff ff  ..N.X<..
<3>[  683.373320] Object 44bb8c3d: 58 3c e8 9b 88 9f ff ff 64 f5 04 00 00 
00 00 00  X<..d...
<3>[  683.373334] Object 180c4cca: 00 00 00 00 ad 4e ad de ff ff ff ff 
5a 5a 5a 5a  .N..
<3>[  683.373348] Object c9044498: ff ff ff ff ff ff ff ff e0 6e 57 c0 
ff ff ff ff  .nW.
<3>[  683.373362] Object 72d0dfb3: 00 00 00 00 00 00 00 00 c0 b1 c8 8e 
ff ff ff ff  
<3>[  683.373376] Object 81f198b9: 55 01 4b c0 ff ff ff ff d8 de 6b fa 
87 9f ff ff  U.K...k.
<3>[  683.373390] Object 6a375a13: d8 de 6b fa 87 9f ff ff cc 05 39 c0 
ff ff ff ff  ..k...9.
<3>[  683.373404] Object b8392dd1: ff ff ff ff 5a 5a 5a 5a 5a 5a 5a 5

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Extract functions to derive SKL+ DIMM info

2019-03-04 Thread Jani Nikula
On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Make the code less repetitive by extracting a few small helpers.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 68 +
>  1 file changed, 43 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 48c6bc44072d..b94bf475b04c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1068,16 +1068,42 @@ static void intel_sanitize_options(struct 
> drm_i915_private *dev_priv)
>   intel_gvt_sanitize_options(dev_priv);
>  }
>  
> -static int skl_get_dimm_ranks(u8 size, u32 rank)
> +static int skl_get_dimm_size(u16 val)
>  {
> - if (size == 0)
> + return val & SKL_DRAM_SIZE_MASK;
> +}
> +
> +static int skl_get_dimm_width(u16 val)
> +{
> + if (skl_get_dimm_size(val) == 0)
>   return 0;
> - if (rank == SKL_DRAM_RANK_SINGLE)
> - return 1;
> - else if (rank == SKL_DRAM_RANK_DUAL)
> - return 2;
>  
> - return 0;
> + switch (val & SKL_DRAM_WIDTH_MASK) {
> + case SKL_DRAM_WIDTH_X8:
> + case SKL_DRAM_WIDTH_X16:
> + case SKL_DRAM_WIDTH_X32:
> + val = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
> + return 8 << val;
> + default:
> + MISSING_CASE(val);
> + return 0;
> + }
> +}
> +
> +static int skl_get_dimm_ranks(u16 val)
> +{
> + if (skl_get_dimm_size(val) == 0)
> + return 0;
> +
> + switch (val & SKL_DRAM_RANK_MASK) {
> + case SKL_DRAM_RANK_SINGLE:
> + case SKL_DRAM_RANK_DUAL:
> + val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
> + return val + 1;
> + default:
> + MISSING_CASE(val);
> + return 0;
> + }

I don't much care for this dual use of both the macro and then the
calculation. I'd either just calculate, or return pre-calculated values
from the cases, not both. The missing cases can also never happen.

But it all checks out, so

Reviewed-by: Jani Nikula 


>  }
>  
>  static bool
> @@ -1098,30 +1124,22 @@ skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
>  static int
>  skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
>  {
> - u32 tmp_l, tmp_s;
> - u32 s_val = val >> SKL_DRAM_S_SHIFT;
> + u16 tmp_l, tmp_s;
>  
> - if (!val)
> - return -EINVAL;
> + tmp_l = val & 0x;
> + tmp_s = val >> 16;
>  
> - tmp_l = val & SKL_DRAM_SIZE_MASK;
> - tmp_s = s_val & SKL_DRAM_SIZE_MASK;
> + ch->l_info.size = skl_get_dimm_size(tmp_l);
> + ch->s_info.size = skl_get_dimm_size(tmp_s);
>  
> - if (tmp_l == 0 && tmp_s == 0)
> + if (ch->l_info.size == 0 && ch->s_info.size == 0)
>   return -EINVAL;
>  
> - ch->l_info.size = tmp_l;
> - ch->s_info.size = tmp_s;
> -
> - tmp_l = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
> - tmp_s = (s_val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
> - ch->l_info.width = (1 << tmp_l) * 8;
> - ch->s_info.width = (1 << tmp_s) * 8;
> + ch->l_info.width = skl_get_dimm_width(tmp_l);
> + ch->s_info.width = skl_get_dimm_width(tmp_s);
>  
> - tmp_l = val & SKL_DRAM_RANK_MASK;
> - tmp_s = s_val & SKL_DRAM_RANK_MASK;
> - ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
> - ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
> + ch->l_info.ranks = skl_get_dimm_ranks(tmp_l);
> + ch->s_info.ranks = skl_get_dimm_ranks(tmp_s);
>  
>   if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
>   ch->ranks = 2;

-- 
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] drm/i915: Acquire breadcrumb ref before cancelling

2019-03-04 Thread Chris Wilson
Quoting Tvrtko Ursulin (2019-03-04 16:26:56)
> 
> On 04/03/2019 11:41, Chris Wilson wrote:
> > We may race the interrupt signaling with retirement, in which case the
> > order in which we acquire the reference inside the interrupt is vital to
> > provide the correct barrier against the request being freed in
> > retirement, i.e. we need to acquire our reference before marking the
> > breadcrumb as cancelled (as soon as the breadcrumb is cancelled
> > retirement may drop its reference to the request without serialisation
> > with the interrupt handler).
[snip]
> Reviewed-by: Tvrtko Ursulin 

Ta. The scary thought is that the bugs will only get more subtle!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Store DIMM rank information as a number

2019-03-04 Thread Ville Syrjälä
On Mon, Mar 04, 2019 at 06:17:50PM +0200, Jani Nikula wrote:
> On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Life will be easier later if we have the ranks stored
> > as a bare number.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 92 +++--
> >  drivers/gpu/drm/i915/i915_drv.h | 11 ++--
> >  2 files changed, 45 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index c6354f6cdbdb..48c6bc44072d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1068,28 +1068,28 @@ static void intel_sanitize_options(struct 
> > drm_i915_private *dev_priv)
> > intel_gvt_sanitize_options(dev_priv);
> >  }
> >  
> > -static enum dram_rank skl_get_dimm_rank(u8 size, u32 rank)
> > +static int skl_get_dimm_ranks(u8 size, u32 rank)
> >  {
> > if (size == 0)
> > -   return I915_DRAM_RANK_INVALID;
> > +   return 0;
> > if (rank == SKL_DRAM_RANK_SINGLE)
> > -   return I915_DRAM_RANK_SINGLE;
> > +   return 1;
> > else if (rank == SKL_DRAM_RANK_DUAL)
> > -   return I915_DRAM_RANK_DUAL;
> > +   return 2;
> >  
> > -   return I915_DRAM_RANK_INVALID;
> > +   return 0;
> >  }
> >  
> >  static bool
> > -skl_is_16gb_dimm(enum dram_rank rank, u8 size, u8 width)
> > +skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
> >  {
> > -   if (rank == I915_DRAM_RANK_SINGLE && width == 8 && size == 16)
> > +   if (ranks == 1 && width == 8 && size == 16)
> > return true;
> > -   else if (rank == I915_DRAM_RANK_DUAL && width == 8 && size == 32)
> > +   else if (ranks == 2 && width == 8 && size == 32)
> > return true;
> > -   else if (rank == SKL_DRAM_RANK_SINGLE && width == 16 && size == 8)
> > +   else if (ranks == 1 && width == 16 && size == 8)
> > return true;
> > -   else if (rank == SKL_DRAM_RANK_DUAL && width == 16 && size == 16)
> > +   else if (ranks == 2 && width == 16 && size == 16)
> > return true;
> >  
> > return false;
> > @@ -1120,28 +1120,24 @@ skl_dram_get_channel_info(struct dram_channel_info 
> > *ch, u32 val)
> >  
> > tmp_l = val & SKL_DRAM_RANK_MASK;
> > tmp_s = s_val & SKL_DRAM_RANK_MASK;
> > -   ch->l_info.rank = skl_get_dimm_rank(ch->l_info.size, tmp_l);
> > -   ch->s_info.rank = skl_get_dimm_rank(ch->s_info.size, tmp_s);
> > -
> > -   if (ch->l_info.rank == I915_DRAM_RANK_DUAL ||
> > -   ch->s_info.rank == I915_DRAM_RANK_DUAL)
> > -   ch->rank = I915_DRAM_RANK_DUAL;
> > -   else if (ch->l_info.rank == I915_DRAM_RANK_SINGLE &&
> > -ch->s_info.rank == I915_DRAM_RANK_SINGLE)
> > -   ch->rank = I915_DRAM_RANK_DUAL;
> > +   ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
> > +   ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
> > +
> > +   if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
> > +   ch->ranks = 2;
> > +   else if (ch->l_info.ranks == 1 && ch->s_info.ranks == 1)
> > +   ch->ranks = 2;
> > else
> > -   ch->rank = I915_DRAM_RANK_SINGLE;
> > +   ch->ranks = 1;
> >  
> > -   ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.rank, ch->l_info.size,
> > +   ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
> > ch->l_info.width) ||
> > -  skl_is_16gb_dimm(ch->s_info.rank, ch->s_info.size,
> > +  skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
> > ch->s_info.width);
> >  
> > -   DRM_DEBUG_KMS("(size:width:rank) L(%dGB:X%d:%s) S(%dGB:X%d:%s)\n",
> > - ch->l_info.size, ch->l_info.width,
> > - ch->l_info.rank ? "dual" : "single",
> > - ch->s_info.size, ch->s_info.width,
> > - ch->s_info.rank ? "dual" : "single");
> 
> I don't understand how the above ternary operators could ever have
> produced the right results before.

Good point. I didn't even notice :)

> 
> > +   DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
> > + ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
> > + ch->s_info.size, ch->s_info.width, ch->s_info.ranks);
> 
> %u instead of %d? Ditto for all debug prints.

Doesn't really matter for these small values. But no harm in %u either
so might as well I suppose.

> 
> Reviewed-by: Jani Nikula 
> 
> 
> >  
> > return 0;
> >  }
> > @@ -1154,7 +1150,7 @@ intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
> > (ch0->s_info.size == 0 ||
> >  (ch0->l_info.size == ch0->s_info.size &&
> >   ch0->l_info.width == ch0->s_info.width &&
> > - ch0->l_info.rank == ch0->s_info.rank)));
> > + ch0->l_info.ranks == ch0->s_info.ranks)));
> >  }
> >  
> >  static int
> > @@ -1185,13 +1181,1

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Forcing a modeset when resetting HDMI link

2019-03-04 Thread Ville Syrjälä
On Fri, Mar 01, 2019 at 04:33:49PM -0800, José Roberto de Souza wrote:
> With fastboot enabled in gen9+ it broke the HDMI reset as just
> setting mode_changed to true causes a fastset and here we want a full
> modeset that will disable and then enable the encoder of this HDMI
> link actually, so setting connectors_changed instead that will cause
> modeset as desired.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Ville Syrjälä 

The two other questionable places seem to be:

* intel_digital_connector_atomic_check()
  Looks like this is currently broken as we don't do infoframe/audio
  updates from the .update_pipe() hook yet. Also we have no
  .update_pipe() for pre-ddi platforms.

* intel_modeset_all_pipes()
  Should work because we set the flag after the modeset->fastset
  downgrade has occurred. Might make sense to change this one as
  well though, just to avoid copy paste errors in the future.

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c22ddde2dfc1..d329f0c206ec 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3973,7 +3973,7 @@ static int modeset_pipe(struct drm_crtc *crtc,
>   goto out;
>   }
>  
> - crtc_state->mode_changed = true;
> + crtc_state->connectors_changed = true;
>  
>   ret = drm_atomic_commit(state);
>  out:
> -- 
> 2.21.0

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

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Extract functions to derive SKL+ DIMM info

2019-03-04 Thread Ville Syrjälä
On Mon, Mar 04, 2019 at 06:32:25PM +0200, Jani Nikula wrote:
> On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Make the code less repetitive by extracting a few small helpers.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 68 +
> >  1 file changed, 43 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 48c6bc44072d..b94bf475b04c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1068,16 +1068,42 @@ static void intel_sanitize_options(struct 
> > drm_i915_private *dev_priv)
> > intel_gvt_sanitize_options(dev_priv);
> >  }
> >  
> > -static int skl_get_dimm_ranks(u8 size, u32 rank)
> > +static int skl_get_dimm_size(u16 val)
> >  {
> > -   if (size == 0)
> > +   return val & SKL_DRAM_SIZE_MASK;
> > +}
> > +
> > +static int skl_get_dimm_width(u16 val)
> > +{
> > +   if (skl_get_dimm_size(val) == 0)
> > return 0;
> > -   if (rank == SKL_DRAM_RANK_SINGLE)
> > -   return 1;
> > -   else if (rank == SKL_DRAM_RANK_DUAL)
> > -   return 2;
> >  
> > -   return 0;
> > +   switch (val & SKL_DRAM_WIDTH_MASK) {
> > +   case SKL_DRAM_WIDTH_X8:
> > +   case SKL_DRAM_WIDTH_X16:
> > +   case SKL_DRAM_WIDTH_X32:
> > +   val = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
> > +   return 8 << val;
> > +   default:
> > +   MISSING_CASE(val);
> > +   return 0;
> > +   }
> > +}
> > +
> > +static int skl_get_dimm_ranks(u16 val)
> > +{
> > +   if (skl_get_dimm_size(val) == 0)
> > +   return 0;
> > +
> > +   switch (val & SKL_DRAM_RANK_MASK) {
> > +   case SKL_DRAM_RANK_SINGLE:
> > +   case SKL_DRAM_RANK_DUAL:
> > +   val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
> > +   return val + 1;
> > +   default:
> > +   MISSING_CASE(val);
> > +   return 0;
> > +   }
> 
> I don't much care for this dual use of both the macro and then the
> calculation. I'd either just calculate, or return pre-calculated values
> from the cases, not both. The missing cases can also never happen.

I generally lean toward the arithmetic option myself, and I did
consider it here as well. I suppose I ended up being swayed
slightly towards the other end of the spectrum by the potential
documentation value of the case labels. And so I ended up
somewhere in the middle.

> 
> But it all checks out, so
> 
> Reviewed-by: Jani Nikula 
> 
> 
> >  }
> >  
> >  static bool
> > @@ -1098,30 +1124,22 @@ skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
> >  static int
> >  skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
> >  {
> > -   u32 tmp_l, tmp_s;
> > -   u32 s_val = val >> SKL_DRAM_S_SHIFT;
> > +   u16 tmp_l, tmp_s;
> >  
> > -   if (!val)
> > -   return -EINVAL;
> > +   tmp_l = val & 0x;
> > +   tmp_s = val >> 16;
> >  
> > -   tmp_l = val & SKL_DRAM_SIZE_MASK;
> > -   tmp_s = s_val & SKL_DRAM_SIZE_MASK;
> > +   ch->l_info.size = skl_get_dimm_size(tmp_l);
> > +   ch->s_info.size = skl_get_dimm_size(tmp_s);
> >  
> > -   if (tmp_l == 0 && tmp_s == 0)
> > +   if (ch->l_info.size == 0 && ch->s_info.size == 0)
> > return -EINVAL;
> >  
> > -   ch->l_info.size = tmp_l;
> > -   ch->s_info.size = tmp_s;
> > -
> > -   tmp_l = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
> > -   tmp_s = (s_val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
> > -   ch->l_info.width = (1 << tmp_l) * 8;
> > -   ch->s_info.width = (1 << tmp_s) * 8;
> > +   ch->l_info.width = skl_get_dimm_width(tmp_l);
> > +   ch->s_info.width = skl_get_dimm_width(tmp_s);
> >  
> > -   tmp_l = val & SKL_DRAM_RANK_MASK;
> > -   tmp_s = s_val & SKL_DRAM_RANK_MASK;
> > -   ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
> > -   ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
> > +   ch->l_info.ranks = skl_get_dimm_ranks(tmp_l);
> > +   ch->s_info.ranks = skl_get_dimm_ranks(tmp_s);
> >  
> > if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
> > ch->ranks = 2;
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
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 1/5] drm/i915/vlv: Move czclk to intel_pm

2019-03-04 Thread Ville Syrjälä
On Fri, Mar 01, 2019 at 04:49:31PM -0800, José Roberto de Souza wrote:
> Moving VLV/CHV/BYT czclk to intel_pm as it is a core clock used as
> base by several other GPU blocks including GT.
> 
> BSpec: 14370
> 
> Cc: Lucas De Marchi 
> Cc: Jani Nikula 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 12 
>  drivers/gpu/drm/i915/intel_pm.c  | 10 ++
>  2 files changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7c5e84ef5171..91a8ee611b12 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -180,17 +180,6 @@ int vlv_get_cck_clock_hpll(struct drm_i915_private 
> *dev_priv,
>dev_priv->hpll_freq);
>  }
>  
> -static void intel_update_czclk(struct drm_i915_private *dev_priv)
> -{
> - if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> - return;
> -
> - dev_priv->czclk_freq = vlv_get_cck_clock_hpll(dev_priv, "czclk",
> -   CCK_CZ_CLOCK_CONTROL);
> -
> - DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
> -}
> -
>  static inline u32 /* units of 100MHz */
>  intel_fdi_link_freq(struct drm_i915_private *dev_priv,
>   const struct intel_crtc_state *pipe_config)
> @@ -15533,7 +15522,6 @@ int intel_modeset_init(struct drm_device *dev)
>   intel_shared_dpll_init(dev);
>   intel_update_fdi_pll_freq(dev_priv);
>  
> - intel_update_czclk(dev_priv);
>   intel_modeset_init_hw(dev);

Is is here because intel_modeset_init_hw() needs it.

>  
>   intel_hdcp_component_init(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9c97a95c1816..cd363fa47cbc 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7622,6 +7622,14 @@ static void vlv_init_gpll_ref_freq(struct 
> drm_i915_private *dev_priv)
>dev_priv->gt_pm.rps.gpll_ref_freq);
>  }
>  
> +static void vlv_update_czclk(struct drm_i915_private *dev_priv)
> +{
> + dev_priv->czclk_freq = vlv_get_cck_clock_hpll(dev_priv, "czclk",
> +   CCK_CZ_CLOCK_CONTROL);
> +
> + DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
> +}
> +
>  static void valleyview_init_gt_powersave(struct drm_i915_private *dev_priv)
>  {
>   struct intel_rps *rps = &dev_priv->gt_pm.rps;
> @@ -7629,6 +7637,7 @@ static void valleyview_init_gt_powersave(struct 
> drm_i915_private *dev_priv)
>  
>   valleyview_setup_pctx(dev_priv);
>  
> + vlv_update_czclk(dev_priv);

This is far too late AFAICS. Also putting it into gt/gem specific code
is equally wrong as having it in the modeset code.

>   vlv_init_gpll_ref_freq(dev_priv);
>  
>   val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
> @@ -7675,6 +7684,7 @@ static void cherryview_init_gt_powersave(struct 
> drm_i915_private *dev_priv)
>  
>   cherryview_setup_pctx(dev_priv);
>  
> + vlv_update_czclk(dev_priv);
>   vlv_init_gpll_ref_freq(dev_priv);
>  
>   mutex_lock(&dev_priv->sb_lock);
> -- 
> 2.21.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 1/5] drm/i915/vlv: Move czclk to intel_pm

2019-03-04 Thread Ville Syrjälä
On Mon, Mar 04, 2019 at 06:57:15PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 01, 2019 at 04:49:31PM -0800, José Roberto de Souza wrote:
> > Moving VLV/CHV/BYT czclk to intel_pm as it is a core clock used as
> > base by several other GPU blocks including GT.
> > 
> > BSpec: 14370
> > 
> > Cc: Lucas De Marchi 
> > Cc: Jani Nikula 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 12 
> >  drivers/gpu/drm/i915/intel_pm.c  | 10 ++
> >  2 files changed, 10 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7c5e84ef5171..91a8ee611b12 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -180,17 +180,6 @@ int vlv_get_cck_clock_hpll(struct drm_i915_private 
> > *dev_priv,
> >  dev_priv->hpll_freq);
> >  }
> >  
> > -static void intel_update_czclk(struct drm_i915_private *dev_priv)
> > -{
> > -   if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> > -   return;
> > -
> > -   dev_priv->czclk_freq = vlv_get_cck_clock_hpll(dev_priv, "czclk",
> > - CCK_CZ_CLOCK_CONTROL);
> > -
> > -   DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
> > -}
> > -
> >  static inline u32 /* units of 100MHz */
> >  intel_fdi_link_freq(struct drm_i915_private *dev_priv,
> > const struct intel_crtc_state *pipe_config)
> > @@ -15533,7 +15522,6 @@ int intel_modeset_init(struct drm_device *dev)
> > intel_shared_dpll_init(dev);
> > intel_update_fdi_pll_freq(dev_priv);
> >  
> > -   intel_update_czclk(dev_priv);
> > intel_modeset_init_hw(dev);
> 
> Is is here because intel_modeset_init_hw() needs it.

No, actually it doesn't. Dang, I'm starting to forget the details. It
is needed by modeset code when it comes time to actually reprogam
cdclk.

> 
> >  
> > intel_hdcp_component_init(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 9c97a95c1816..cd363fa47cbc 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7622,6 +7622,14 @@ static void vlv_init_gpll_ref_freq(struct 
> > drm_i915_private *dev_priv)
> >  dev_priv->gt_pm.rps.gpll_ref_freq);
> >  }
> >  
> > +static void vlv_update_czclk(struct drm_i915_private *dev_priv)
> > +{
> > +   dev_priv->czclk_freq = vlv_get_cck_clock_hpll(dev_priv, "czclk",
> > + CCK_CZ_CLOCK_CONTROL);
> > +
> > +   DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
> > +}
> > +
> >  static void valleyview_init_gt_powersave(struct drm_i915_private *dev_priv)
> >  {
> > struct intel_rps *rps = &dev_priv->gt_pm.rps;
> > @@ -7629,6 +7637,7 @@ static void valleyview_init_gt_powersave(struct 
> > drm_i915_private *dev_priv)
> >  
> > valleyview_setup_pctx(dev_priv);
> >  
> > +   vlv_update_czclk(dev_priv);
> 
> This is far too late AFAICS. Also putting it into gt/gem specific code
> is equally wrong as having it in the modeset code.

So this last argument still holds. We should put it into some common
code. Maybe we need some kind of clock_init() thing.

> 
> > vlv_init_gpll_ref_freq(dev_priv);
> >  
> > val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
> > @@ -7675,6 +7684,7 @@ static void cherryview_init_gt_powersave(struct 
> > drm_i915_private *dev_priv)
> >  
> > cherryview_setup_pctx(dev_priv);
> >  
> > +   vlv_update_czclk(dev_priv);
> > vlv_init_gpll_ref_freq(dev_priv);
> >  
> > mutex_lock(&dev_priv->sb_lock);
> > -- 
> > 2.21.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel

-- 
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 4/5] drm/i915: Move rawclck, power_domain and irq un/initialization from modeset functions

2019-03-04 Thread Ville Syrjälä
On Fri, Mar 01, 2019 at 04:49:34PM -0800, José Roberto de Souza wrote:
> The initialization of those componentes is required by the GEM/GT not
> only display so lets move then to a more the appropriate place.
> 
> Cc: Lucas De Marchi 
> Cc: Jani Nikula 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  | 39 
>  drivers/gpu/drm/i915/intel_display.c |  7 -
>  2 files changed, 23 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index cc07259ec946..2b5ce764e694 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -691,24 +691,15 @@ static int i915_modeset_load(struct drm_device *dev)
>   if (ret)
>   goto cleanup_vga_client;
>  
> - /* must happen before intel_power_domains_init_hw() on VLV/CHV */
> - intel_update_rawclk(dev_priv);
> -
> - intel_power_domains_init_hw(dev_priv, false);
> -
>   intel_csr_ucode_init(dev_priv);
>  
> - ret = intel_irq_install(dev_priv);
> - if (ret)
> - goto cleanup_csr;
> -
>   intel_setup_gmbus(dev_priv);
>  
>   /* Important: The output setup functions called by modeset_init need
>* working irqs for e.g. gmbus and dp aux transfers. */
>   ret = intel_modeset_init(dev);
>   if (ret)
> - goto cleanup_irq;
> + goto cleanup_gmbus;
>  
>   ret = i915_gem_init(dev_priv);
>   if (ret)
> @@ -736,12 +727,9 @@ static int i915_modeset_load(struct drm_device *dev)
>   i915_gem_fini(dev_priv);
>  cleanup_modeset:
>   intel_modeset_cleanup(dev);
> -cleanup_irq:
> - drm_irq_uninstall(dev);
> +cleanup_gmbus:
>   intel_teardown_gmbus(dev_priv);
> -cleanup_csr:
>   intel_csr_ucode_fini(dev_priv);
> - intel_power_domains_fini_hw(dev_priv);
>   vga_switcheroo_unregister_client(pdev);
>  cleanup_vga_client:
>   vga_client_register(pdev, NULL, NULL, NULL);
> @@ -1765,9 +1753,18 @@ int i915_driver_load(struct pci_dev *pdev, const 
> struct pci_device_id *ent)
>   if (ret < 0)
>   goto out_cleanup_mmio;
>  
> + /* must happen before intel_power_domains_init_hw() on VLV/CHV */
> + intel_update_rawclk(dev_priv);
> +
> + intel_power_domains_init_hw(dev_priv, false);
> +
> + ret = intel_irq_install(dev_priv);
> + if (ret)
> + goto out_cleanup_power;

What are the steps we're reordering wrt. irq enable and
why is it OK to reorder them?

> +
>   ret = i915_modeset_load(&dev_priv->drm);
>   if (ret < 0)
> - goto out_cleanup_hw;
> + goto out_cleanup_irq;
>  
>   i915_driver_register(dev_priv);
>  
> @@ -1777,7 +1774,10 @@ int i915_driver_load(struct pci_dev *pdev, const 
> struct pci_device_id *ent)
>  
>   return 0;
>  
> -out_cleanup_hw:
> +out_cleanup_irq:
> + drm_irq_uninstall(&dev_priv->drm);
> +out_cleanup_power:
> + intel_power_domains_fini_hw(dev_priv);
>   i915_driver_cleanup_hw(dev_priv);
>  out_cleanup_mmio:
>   i915_driver_cleanup_mmio(dev_priv);
> @@ -1810,6 +1810,13 @@ void i915_driver_unload(struct drm_device *dev)
>  
>   intel_gvt_cleanup(dev_priv);
>  
> + /*
> +  * Interrupts and polling as the first thing to avoid creating havoc.
> +  * Too much stuff here (turning of connectors, ...) would
> +  * experience fancy races otherwise.
> +  */
> + intel_irq_uninstall(dev_priv);

This too seems slightly questionable considering the flush_workqueue()
etc. in intel_modeset_cleanup(). Can we be sure all modeset activity has
in fact finished sufficiently to no require interrupts?

> +
>   i915_modeset_unload(dev);
>  
>   /* Free error state after interrupts are fully disabled. */
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7963348f1c64..5158e8ecb9ed 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -16364,13 +16364,6 @@ void intel_modeset_cleanup(struct drm_device *dev)
>   flush_work(&dev_priv->atomic_helper.free_work);
>   WARN_ON(!llist_empty(&dev_priv->atomic_helper.free_list));
>  
> - /*
> -  * Interrupts and polling as the first thing to avoid creating havoc.
> -  * Too much stuff here (turning of connectors, ...) would
> -  * experience fancy races otherwise.
> -  */
> - intel_irq_uninstall(dev_priv);
> -
>   /*
>* Due to the hpd irq storm handling the hotplug work can re-arm the
>* poll handlers. Hence disable polling after hpd handling is shut down.
> -- 
> 2.21.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix the state checker for ICL Y planes

2019-03-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix the state checker for ICL Y planes
URL   : https://patchwork.freedesktop.org/series/57518/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5694_full -> Patchwork_12360_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs1-dirty-switch:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109281]

  * igt@gem_mocs_settings@mocs-reset-bsd2:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +188

  * igt@gem_mocs_settings@mocs-settings-ctx-render:
- shard-iclb: NOTRUN -> SKIP [fdo#109287] +1

  * igt@gem_pread@stolen-snoop:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +80

  * igt@gem_pwrite@huge-cpu-fbr:
- shard-iclb: NOTRUN -> SKIP [fdo#109290]

  * igt@gen3_render_tiledy_blits:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +31

  * igt@kms_atomic_transition@1x-modeset-transitions-fencing:
- shard-skl:  PASS -> FAIL [fdo#107815] / [fdo#108470]

  * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +1

  * igt@kms_busy@extended-pageflip-hang-newfb-render-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_ccs@pipe-a-crc-primary-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107725]

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  PASS -> FAIL [fdo#106510] / [fdo#108145] +1

  * igt@kms_color@pipe-a-degamma:
- shard-skl:  NOTRUN -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_color@pipe-b-legacy-gamma:
- shard-apl:  PASS -> FAIL [fdo#104782]

  * igt@kms_content_protection@atomic-dpms:
- shard-kbl:  NOTRUN -> FAIL [fdo#108739]

  * igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-skl:  NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-512x170-offscreen:
- shard-iclb: NOTRUN -> SKIP [fdo#109279]

  * igt@kms_cursor_legacy@cursora-vs-flipb-atomic-transitions-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +2

  * igt@kms_draw_crc@draw-method-rgb565-render-ytiled:
- shard-iclb: NOTRUN -> FAIL [fdo#103184]

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled:
- shard-skl:  NOTRUN -> FAIL [fdo#103184] / [fdo#103232]

  * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled:
- shard-skl:  NOTRUN -> FAIL [fdo#103184]

  * igt@kms_draw_crc@draw-method-xrgb-render-untiled:
- shard-skl:  NOTRUN -> FAIL [fdo#103184] / [fdo#108472]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  PASS -> FAIL [fdo#105363]

  * igt@kms_flip@plain-flip-ts-check-interruptible:
- shard-skl:  NOTRUN -> FAIL [fdo#100368]

  * igt@kms_flip_tiling@flip-y-tiled:
- shard-skl:  PASS -> FAIL [fdo#108303]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-apl:  PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-pwrite:
- shard-glk:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-pgflip-blt:
- shard-skl:  NOTRUN -> FAIL [fdo#103167] +6

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-shrfb-pgflip-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +4

  * igt@kms_plane@plane-panning-bottom-right-pipe-a-planes:
- shard-skl:  NOTRUN -> FAIL [fdo#103166] +1

  * igt@kms_plane@plane-panning-top-left-pipe-a-planes:
- shard-skl:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  PASS -> FAIL [fdo#107815]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166]

  * igt@kms_universal_plane@disable-primary-vs-flip-pipe-d:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +20

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-kbl:  NOTRUN -> FAIL [fdo#104894]

  * igt@perf_pmu@

Re: [Intel-gfx] [PATCH v2 03/12] drm/i915: Polish skl_is_16gb_dimm()

2019-03-04 Thread Jani Nikula
On Tue, 26 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Pass the dimm struct to skl_is_16gb_dimm() rather than passing each
> value separately. And let's replace the hardcoded set of values with
> some simple arithmetic.
>
> Also fix the byte vs. bit inconsistency in the debug message,
> and polish the wording otherwise as well.
>
> v2: Deobfuscate the math (Chris)

Took me longer than I'd like to wrap my head around this, but looks
good.

Reviewed-by: Jani Nikula 


>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 28 
>  drivers/gpu/drm/i915/i915_drv.h |  8 +---
>  2 files changed, 17 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b94bf475b04c..d84f3485e775 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1068,6 +1068,11 @@ static void intel_sanitize_options(struct 
> drm_i915_private *dev_priv)
>   intel_gvt_sanitize_options(dev_priv);
>  }
>  
> +static int intel_dimm_num_devices(const struct dram_dimm_info *dimm)
> +{
> + return dimm->ranks * 64 / (dimm->width ?: 1);
> +}
> +
>  static int skl_get_dimm_size(u16 val)
>  {
>   return val & SKL_DRAM_SIZE_MASK;
> @@ -1107,18 +1112,10 @@ static int skl_get_dimm_ranks(u16 val)
>  }
>  
>  static bool
> -skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
> +skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
>  {
> - if (ranks == 1 && width == 8 && size == 16)
> - return true;
> - else if (ranks == 2 && width == 8 && size == 32)
> - return true;
> - else if (ranks == 1 && width == 16 && size == 8)
> - return true;
> - else if (ranks == 2 && width == 16 && size == 16)
> - return true;
> -
> - return false;
> + /* Convert total GB to Gb per DRAM device */
> + return 8 * dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
>  }
>  
>  static int
> @@ -1148,10 +1145,9 @@ skl_dram_get_channel_info(struct dram_channel_info 
> *ch, u32 val)
>   else
>   ch->ranks = 1;
>  
> - ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
> - ch->l_info.width) ||
> -skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
> - ch->s_info.width);
> + ch->is_16gb_dimm =
> + skl_is_16gb_dimm(&ch->l_info) ||
> + skl_is_16gb_dimm(&ch->s_info);
>  
>   DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
> ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
> @@ -1369,7 +1365,7 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
>   sprintf(bandwidth_str, "unknown");
>   DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
> bandwidth_str, dram_info->num_channels);
> - DRM_DEBUG_KMS("DRAM ranks: %d, 16GB-dimm:%s\n",
> + DRM_DEBUG_KMS("DRAM ranks: %d, 16Gb DIMMs: %s\n",
> dram_info->ranks, yesno(dram_info->is_16gb_dimm));
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c9cb13a6edaf..fcde09934bb5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2065,10 +2065,12 @@ struct drm_i915_private {
>*/
>  };
>  
> +struct dram_dimm_info {
> + u8 size, width, ranks;
> +};
> +
>  struct dram_channel_info {
> - struct info {
> - u8 size, width, ranks;
> - } l_info, s_info;
> + struct dram_dimm_info l_info, s_info;
>   u8 ranks;
>   bool is_16gb_dimm;
>  };

-- 
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 v2 04/12] drm/i915: Extract BXT DIMM helpers

2019-03-04 Thread Jani Nikula
On Tue, 26 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Polish the bxt DIMM parsing by extracting a few small helpers.
>
> v2: Use struct dram_dimm_info
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 93 ++---
>  1 file changed, 62 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index d84f3485e775..f948d475bdf4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1243,6 +1243,59 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
>   return 0;
>  }
>  
> +static int bxt_get_dimm_size(u32 val)
> +{
> + switch (val & BXT_DRAM_SIZE_MASK) {
> + case BXT_DRAM_SIZE_4GB:
> + return 4;
> + case BXT_DRAM_SIZE_6GB:
> + return 6;
> + case BXT_DRAM_SIZE_8GB:
> + return 8;
> + case BXT_DRAM_SIZE_12GB:
> + return 12;
> + case BXT_DRAM_SIZE_16GB:
> + return 16;
> + default:
> + MISSING_CASE(val);
> + return 0;
> + }
> +}
> +
> +static int bxt_get_dimm_width(u32 val)
> +{
> + if (!bxt_get_dimm_size(val))
> + return 0;
> +
> + val = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
> +
> + return 8 << val;
> +}
> +
> +static int bxt_get_dimm_ranks(u32 val)
> +{
> + if (!bxt_get_dimm_size(val))
> + return 0;
> +
> + switch (val & BXT_DRAM_RANK_MASK) {
> + case BXT_DRAM_RANK_SINGLE:
> + return 1;
> + case BXT_DRAM_RANK_DUAL:
> + return 2;
> + default:
> + MISSING_CASE(val);
> + return 0;
> + }
> +}
> +
> +static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
> +   u32 val)
> +{
> + dimm->size = bxt_get_dimm_size(val);
> + dimm->width = bxt_get_dimm_width(val);
> + dimm->ranks = bxt_get_dimm_ranks(val);
> +}
> +
>  static int
>  bxt_get_dram_info(struct drm_i915_private *dev_priv)
>  {
> @@ -1271,41 +1324,19 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
>* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
>*/
>   for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
> - u8 size, width, ranks;
> - u32 tmp;
> + struct dram_dimm_info dimm;
>  
>   val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
>   if (val == 0x)
>   continue;
>  
>   dram_info->num_channels++;
> - tmp = val & BXT_DRAM_RANK_MASK;
> -
> - if (tmp == BXT_DRAM_RANK_SINGLE)
> - ranks = 1;
> - else if (tmp == BXT_DRAM_RANK_DUAL)
> - ranks = 2;
> - else
> - ranks = 0;
> -
> - tmp = val & BXT_DRAM_SIZE_MASK;
> - if (tmp == BXT_DRAM_SIZE_4GB)
> - size = 4;
> - else if (tmp == BXT_DRAM_SIZE_6GB)
> - size = 6;
> - else if (tmp == BXT_DRAM_SIZE_8GB)
> - size = 8;
> - else if (tmp == BXT_DRAM_SIZE_12GB)
> - size = 12;
> - else if (tmp == BXT_DRAM_SIZE_16GB)
> - size = 16;
> - else
> - size = 0;
> -
> - tmp = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
> - width = (1 << tmp) * 8;
> - DRM_DEBUG_KMS("dram size:%dGB width:X%d ranks:%d\n",
> -   size, width, ranks);
> +
> + bxt_get_dimm_info(&dimm, val);
> +
> + DRM_DEBUG_KMS("CH%d DIMM size: %d GB, width: X%d, ranks: %d\n",
> +   i - BXT_D_CR_DRP0_DUNIT_START,
> +   dimm.size, dimm.width, dimm.ranks);
>  
>   /*
>* If any of the channel is single rank channel,
> @@ -1313,8 +1344,8 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
>* memory, so consider single rank memory.
>*/
>   if (dram_info->ranks == 0)
> - dram_info->ranks = ranks;
> - else if (ranks == 1)
> + dram_info->ranks = dimm.ranks;
> + else if (dimm.ranks == 1)
>   dram_info->ranks = 1;
>   }

-- 
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.IGT: success for drm/i915: Simplify i830 DVO 2x clock handling

2019-03-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Simplify i830 DVO 2x clock handling
URL   : https://patchwork.freedesktop.org/series/57520/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5694_full -> Patchwork_12361_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_mocs_settings@mocs-reset-bsd2:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +189

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +99

  * igt@gen3_render_tiledy_blits:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +26

  * igt@i915_pm_rpm@fences:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +25

  * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8

  * igt@kms_busy@extended-pageflip-hang-newfb-render-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#107956] +1

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-apl:  PASS -> FAIL [fdo#106510] / [fdo#108145]

  * igt@kms_color@pipe-b-legacy-gamma:
- shard-apl:  PASS -> FAIL [fdo#104782]

  * igt@kms_content_protection@atomic-dpms:
- shard-kbl:  NOTRUN -> FAIL [fdo#108739]

  * igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108]

  * igt@kms_cursor_crc@cursor-256x85-offscreen:
- shard-skl:  PASS -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-skl:  NOTRUN -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-glk:  PASS -> FAIL [fdo#109350]

  * igt@kms_cursor_crc@cursor-alpha-transparent:
- shard-skl:  PASS -> FAIL [fdo#109350]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  PASS -> FAIL [fdo#105363]

  * igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt:
- shard-skl:  PASS -> FAIL [fdo#105682]

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt:
- shard-skl:  PASS -> FAIL [fdo#103167]

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- shard-skl:  PASS -> FAIL [fdo#103191] / [fdo#107362]

  * igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#106885]

  * igt@kms_plane@plane-panning-top-left-pipe-a-planes:
- shard-skl:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  PASS -> FAIL [fdo#107815]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_universal_plane@disable-primary-vs-flip-pipe-d:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +20

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- shard-kbl:  NOTRUN -> FAIL [fdo#104894]

  * igt@kms_vblank@pipe-c-ts-continuation-modeset-rpm:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@prime_nv_test@i915_import_gtt_mmap:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +4

  
 Possible fixes 

  * igt@kms_chv_cursor_fail@pipe-b-256x256-left-edge:
- shard-skl:  FAIL [fdo#104671] -> PASS

  * igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl:  FAIL [fdo#103232] -> PASS +1

  * igt@kms_draw_crc@draw-method-xrgb2101010-blt-untiled:
- shard-skl:  FAIL [fdo#103184] / [fdo#108472] -> PASS

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled:
- shard-skl:  FAIL [fdo#103184] -> PASS

  * igt@kms_flip_tiling@flip-changes-tiling-y:
- shard-skl:  FAIL [fdo#107931] / [fdo#108303] -> PASS

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  DMESG-FAIL [fdo#105763] -> PASS

  * igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl:  FAIL [fdo#109016] -> PASS

  * igt@kms_setmode@basic:
- shard-kbl:  FAIL [fdo#99912] -> PASS

  
 Warnings 

  * igt@kms_cursor_crc@cursor-128x42-random:
- shard-kbl:  FAIL [fdo#103232] -> DMESG-FAIL [fdo#103232] / 
[fdo#103558] / [fdo#105602]

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-kbl:  FAIL [fdo#103167] / [fdo#105682] -> DMESG-FAIL 
[f

Re: [Intel-gfx] [PATCH v4 4/9] drm/i915/psr: Drop test for EDP in CRTC when forcing commit

2019-03-04 Thread Rodrigo Vivi
On Fri, Mar 01, 2019 at 05:34:51PM -0800, José Roberto de Souza wrote:
> If has_psr is set it means that CRTC has a EDP panel attached so it
> can be dropped, also has_psr is better than check for EDP output
> alone as it will avoid set mode_changed when PSR is not supported in
> panel or with current modeset.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 

indeed protected by sink_support only getting set on edp init
connector flow..


Reviewed-by: Rodrigo Vivi 



> ---
>  drivers/gpu/drm/i915/intel_psr.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 6175b1d2e0c8..2d9f64c362e2 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -981,9 +981,7 @@ static int intel_psr_fastset_force(struct 
> drm_i915_private *dev_priv)
>  
>   intel_crtc_state = to_intel_crtc_state(crtc_state);
>  
> - if (crtc_state->active &&
> - intel_crtc_has_type(intel_crtc_state, INTEL_OUTPUT_EDP) &&
> - intel_crtc_state->has_psr) {
> + if (crtc_state->active && intel_crtc_state->has_psr) {
>   /* Mark mode as changed to trigger a pipe->update() */
>   crtc_state->mode_changed = true;
>   break;
> -- 
> 2.21.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 8/9] drm/i915/psr: Set idle frames to maximum while getting pipe CRC

2019-03-04 Thread Dhinakaran Pandiyan
On Fri, 2019-03-01 at 17:34 -0800, José Roberto de Souza wrote:
> Increase the idle frames to activate PSR1 to avoid CRC timeouts, as
> soon as pipe CRC is enabled it will avoid PSR1 to activate but if
> PSR1 is activate before that, hardware goes to lower power states
> that inhibits CRC calculations causing CRC timeout errors in IGT
> tests.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 17 +++--
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 453af7438e67..e336f758e481 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -521,6 +521,7 @@ struct i915_psr {
>   bool sink_not_reliable;
>   bool irq_aux_error;
>   u16 su_x_granularity;
> + bool crc_enabled;
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index d3e3996551c6..b237d96db277 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -452,6 +452,16 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
>* frames, we'll go with 9 frames for now
>*/
>   idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> + 1);
> +
> + /*
> +  * Increase the idle frames to active PSR1 to avoid CRC
> timeouts, as
> +  * soon as pipe CRC is enabled it will avoid PSR1 to activate
> but if
> +  * PSR1 is activate before that, hardware goes to lower power
> states
> +  * that inhibits CRC calculations.
> +  */
> + if (dev_priv->psr.crc_enabled)
> + idle_frames = 0xf;

My understanding was only the enable bit can be changed when PSR is
enabled. Does this work?

> +
>   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;

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

Re: [Intel-gfx] [PATCH v4 5/9] drm/i915/crc: Make IPS workaround generic

2019-03-04 Thread Rodrigo Vivi
On Fri, Mar 01, 2019 at 05:34:52PM -0800, José Roberto de Souza wrote:
> Other features like PSR2 also needs to be disabled while getting CRC
> so lets rename ips_force_disable to crc_enabled, drop all this checks
> for pipe A and HSW and BDW and make it generic and
> hsw_compute_ips_config() will take care of all the checks removed
> from here.
> 
> v2: Renaming and parameter changes to the functions that prepares the
> commit (Ville)
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 

nice clean-up.

Reviewed-by: Rodrigo Vivi 



> ---
>  drivers/gpu/drm/i915/intel_display.c  | 10 --
>  drivers/gpu/drm/i915/intel_drv.h  |  3 +-
>  drivers/gpu/drm/i915/intel_pipe_crc.c | 47 +++
>  3 files changed, 29 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 816e8f124b3b..328967c642b3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6751,7 +6751,13 @@ static bool hsw_compute_ips_config(struct 
> intel_crtc_state *crtc_state)
>   if (!hsw_crtc_state_ips_capable(crtc_state))
>   return false;
>  
> - if (crtc_state->ips_force_disable)
> + /*
> +  * When IPS gets enabled, the pipe CRC changes. Since IPS gets
> +  * enabled and disabled dynamically based on package C states,
> +  * user space can't make reliable use of the CRCs, so let's just
> +  * completely disable it.
> +  */
> + if (crtc_state->crc_enabled)
>   return false;
>  
>   /* IPS should be fine as long as at least one plane is enabled. */
> @@ -11684,7 +11690,7 @@ clear_intel_crtc_state(struct intel_crtc_state 
> *crtc_state)
>   saved_state->shared_dpll = crtc_state->shared_dpll;
>   saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
>   saved_state->pch_pfit.force_thru = crtc_state->pch_pfit.force_thru;
> - saved_state->ips_force_disable = crtc_state->ips_force_disable;
> + saved_state->crc_enabled = crtc_state->crc_enabled;
>   if (IS_G4X(dev_priv) ||
>   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   saved_state->wm = crtc_state->wm;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5412373e2f98..2be64529e4a2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -999,7 +999,8 @@ struct intel_crtc_state {
>   struct intel_link_m_n fdi_m_n;
>  
>   bool ips_enabled;
> - bool ips_force_disable;
> +
> + bool crc_enabled;
>  
>   bool enable_fbc;
>  
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index 53d4ec68d3c4..af64597c5c6e 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -280,15 +280,15 @@ static int ilk_pipe_crc_ctl_reg(enum 
> intel_pipe_crc_source *source,
>   return 0;
>  }
>  
> -static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
> -   bool enable)
> +static void
> +intel_crtc_crc_setup_workarounds(struct intel_crtc *crtc, bool enable)
>  {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   struct drm_device *dev = &dev_priv->drm;
> - struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
>   struct intel_crtc_state *pipe_config;
>   struct drm_atomic_state *state;
>   struct drm_modeset_acquire_ctx ctx;
> - int ret = 0;
> + int ret;
>  
>   drm_modeset_acquire_init(&ctx, 0);
>  
> @@ -307,17 +307,9 @@ static void hsw_pipe_A_crc_wa(struct drm_i915_private 
> *dev_priv,
>   goto put_state;
>   }
>  
> - if (HAS_IPS(dev_priv)) {
> - /*
> -  * When IPS gets enabled, the pipe CRC changes. Since IPS gets
> -  * enabled and disabled dynamically based on package C states,
> -  * user space can't make reliable use of the CRCs, so let's just
> -  * completely disable it.
> -  */
> - pipe_config->ips_force_disable = enable;
> - }
> + pipe_config->crc_enabled = enable;
>  
> - if (IS_HASWELL(dev_priv)) {
> + if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A) {
>   pipe_config->pch_pfit.force_thru = enable;
>   if (pipe_config->cpu_transcoder == TRANSCODER_EDP &&
>   pipe_config->pch_pfit.enabled != enable)
> @@ -343,8 +335,7 @@ static void hsw_pipe_A_crc_wa(struct drm_i915_private 
> *dev_priv,
>  static int ivb_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
>   enum pipe pipe,
>   enum intel_pipe_crc_source *source,
> - u32 *val,
> - bool set_wa)
> + u32 *val)
>  {
>   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO

Re: [Intel-gfx] [PATCH v4 6/9] drm/i915: Disable PSR2 while getting pipe CRC

2019-03-04 Thread Rodrigo Vivi
On Fri, Mar 01, 2019 at 05:34:53PM -0800, José Roberto de Souza wrote:
> When PSR2 is active aka after the number of frames programmed in
> PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> interruptions causing IGT tests to fail due timeout.
> 
> This same behavior don't happen with PSR1, as soon as pipe CRC is
> enabled it blocks PSR1 activation so CRC calculation continues to
> happens normaly.
> 
> This patch also set mode_changed as true when PSR is available to
> force atomic check functions to compute new PSR state, otherwise PSR2
> would not be disabled.

Oh, this part was confusing... I was about to ask has_psr2 below,
and then I read the commit message again to understand it.

it probably deserved a separated patch...
or at least a comment on the code...

but, up to you, makes sense now

Reviewed-by: Rodrigo Vivi 


> 
> v4: Only setting mode_changed if has_psr is set(Dhinakaran)
> 
> v3: Reusing intel_crtc_crc_prepare() and crc_enabled, only setting
> mode_changed if it can do PSR.
> 
> v2: Changed commit description to describe that PSR2 inhibit CRC
> calculations.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
>  drivers/gpu/drm/i915/intel_psr.c  | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index af64597c5c6e..c17f02b88453 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -307,6 +307,7 @@ intel_crtc_crc_setup_workarounds(struct intel_crtc *crtc, 
> bool enable)
>   goto put_state;
>   }
>  
> + pipe_config->base.mode_changed = pipe_config->has_psr;
>   pipe_config->crc_enabled = enable;
>  
>   if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A) {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2d9f64c362e2..73453d89a841 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   return false;
>   }
>  
> + if (crtc_state->crc_enabled)
> + return false;
> +
>   return true;
>  }
>  
> -- 
> 2.21.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 8/9] drm/i915/psr: Set idle frames to maximum while getting pipe CRC

2019-03-04 Thread Souza, Jose
On Mon, 2019-03-04 at 10:31 -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2019-03-01 at 17:34 -0800, José Roberto de Souza wrote:
> > Increase the idle frames to activate PSR1 to avoid CRC timeouts, as
> > soon as pipe CRC is enabled it will avoid PSR1 to activate but if
> > PSR1 is activate before that, hardware goes to lower power states
> > that inhibits CRC calculations causing CRC timeout errors in IGT
> > tests.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_psr.c | 17 +++--
> >  2 files changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 453af7438e67..e336f758e481 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -521,6 +521,7 @@ struct i915_psr {
> > bool sink_not_reliable;
> > bool irq_aux_error;
> > u16 su_x_granularity;
> > +   bool crc_enabled;
> >  };
> >  
> >  enum intel_pch {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index d3e3996551c6..b237d96db277 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -452,6 +452,16 @@ static void hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> >  * frames, we'll go with 9 frames for now
> >  */
> > idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > + 1);
> > +
> > +   /*
> > +* Increase the idle frames to active PSR1 to avoid CRC
> > timeouts, as
> > +* soon as pipe CRC is enabled it will avoid PSR1 to activate
> > but if
> > +* PSR1 is activate before that, hardware goes to lower power
> > states
> > +* that inhibits CRC calculations.
> > +*/
> > +   if (dev_priv->psr.crc_enabled)
> > +   idle_frames = 0xf;
> 
> My understanding was only the enable bit can be changed when PSR is
> enabled. Does this work?

That is true, the additional changes in intel_psr_update() will disable
and then enable PSR with this new idle_frames.

> 
> > +
> > val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 7/9] drm/i915: Drop redundant checks to update PSR state

2019-03-04 Thread Rodrigo Vivi
On Fri, Mar 01, 2019 at 05:34:54PM -0800, José Roberto de Souza wrote:
> All of this checks are redudant and can be removed as the if bellow
> already takes care when there is no changes in the state.

is it just redundant or does it really change the behaviour for PSR2
as needed?

code seems right, explanation here not so sure...
but if this is really right and I am missing something feel
free to use:


Reviewed-by: Rodrigo Vivi 

otherwise please change the msg.

Thanks,
Rodrigo.

> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 73453d89a841..d3e3996551c6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -878,15 +878,11 @@ void intel_psr_update(struct intel_dp *intel_dp,
>   if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
>   goto unlock;
>  
> - if (psr->enabled) {
> - if (!enable || psr2_enable != psr->psr2_enabled)
> - intel_psr_disable_locked(intel_dp);
> - }
> + if (psr->enabled)
> + intel_psr_disable_locked(intel_dp);
>  
> - if (enable) {
> - if (!psr->enabled || psr2_enable != psr->psr2_enabled)
> - intel_psr_enable_locked(dev_priv, crtc_state);
> - }
> + if (enable)
> + intel_psr_enable_locked(dev_priv, crtc_state);
>  
>  unlock:
>   mutex_unlock(&dev_priv->psr.lock);
> -- 
> 2.21.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915: Enable PSR2 by default

2019-03-04 Thread Rodrigo Vivi
On Fri, Mar 01, 2019 at 05:34:56PM -0800, José Roberto de Souza wrote:
> The support for PSR2 was polished, IGT tests for PSR2 was added and
> it was tested performing regular user workloads like browsing,
> editing documents and compiling Linux, so it is time to enable it by
> default and enjoy even more power-savings.
> 
> Cc: Rodrigo Vivi 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 

\o/ !

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_psr.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index b237d96db277..116c8b50ee78 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -80,9 +80,6 @@ static bool intel_psr2_enabled(struct drm_i915_private 
> *dev_priv,
>   case I915_PSR_DEBUG_DISABLE:
>   case I915_PSR_DEBUG_FORCE_PSR1:
>   return false;
> - case I915_PSR_DEBUG_DEFAULT:
> - if (i915_modparams.enable_psr <= 0)
> - return false;
>   default:
>   return crtc_state->has_psr2;
>   }
> -- 
> 2.21.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 7/9] drm/i915: Drop redundant checks to update PSR state

2019-03-04 Thread Dhinakaran Pandiyan
On Mon, 2019-03-04 at 10:42 -0800, Rodrigo Vivi wrote:
> On Fri, Mar 01, 2019 at 05:34:54PM -0800, José Roberto de Souza
> wrote:
> > All of this checks are redudant and can be removed as the if bellow
> > already takes care when there is no changes in the state.
> 
> is it just redundant or does it really change the behaviour for PSR2
> as needed?

I have the same question now that I read José's response to patch 8/9.
At first, I ignored reading this patch because it included the word
"redundant" in the commit message :)

> 
> code seems right, explanation here not so sure...
> but if this is really right and I am missing something feel
> free to use:
> 
> 
> Reviewed-by: Rodrigo Vivi 
> 
> otherwise please change the msg.
> 
> Thanks,
> Rodrigo.
> 
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 73453d89a841..d3e3996551c6 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -878,15 +878,11 @@ void intel_psr_update(struct intel_dp
> > *intel_dp,
> > if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
> > goto unlock;
> >  
> > -   if (psr->enabled) {
> > -   if (!enable || psr2_enable != psr->psr2_enabled)
> > -   intel_psr_disable_locked(intel_dp);
> > -   }
> > +   if (psr->enabled)
> > +   intel_psr_disable_locked(intel_dp);
> >  
> > -   if (enable) {
> > -   if (!psr->enabled || psr2_enable != psr->psr2_enabled)
> > -   intel_psr_enable_locked(dev_priv, crtc_state);
> > -   }
> > +   if (enable)
> > +   intel_psr_enable_locked(dev_priv, crtc_state);
> >  
> >  unlock:
> > mutex_unlock(&dev_priv->psr.lock);
> > -- 
> > 2.21.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v2 05/12] drm/i915: Fix DRAM size reporting for BXT

2019-03-04 Thread Jani Nikula
On Tue, 26 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> The BXT DUNIT register tells us the size of each DRAM device
> in Gb. We want to report the size of the whole DIMM in GB, so
> that it matches how we report it for non-LP platforms.
>
> v2: Deobfuscate the math (Chris)
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f948d475bdf4..08fb1b1502a0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1291,9 +1291,14 @@ static int bxt_get_dimm_ranks(u32 val)
>  static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
> u32 val)
>  {
> - dimm->size = bxt_get_dimm_size(val);
>   dimm->width = bxt_get_dimm_width(val);
>   dimm->ranks = bxt_get_dimm_ranks(val);
> +
> + /*
> +  * Size in register is Gb per DRAM device. Convert to total
> +  * GB to match the way we report this for non-LP platforms.
> +  */
> + dimm->size = bxt_get_dimm_size(val) * intel_dimm_num_devices(dimm) / 8;

I wouldn't object to {bxt,skl}_get_dimm_size() having a comment about
the unit. Also wouldn't object to renaming the BXT_DRAM_SIZE_GB
macros to GBIT. Even Gb vs. GB seems too subtle at times.

Anyway,

Reviewed-by: Jani Nikula 



>  }
>  
>  static int

-- 
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 v4 8/9] drm/i915/psr: Set idle frames to maximum while getting pipe CRC

2019-03-04 Thread Dhinakaran Pandiyan
On Mon, 2019-03-04 at 10:40 -0800, Souza, Jose wrote:
> On Mon, 2019-03-04 at 10:31 -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2019-03-01 at 17:34 -0800, José Roberto de Souza wrote:
> > > Increase the idle frames to activate PSR1 to avoid CRC timeouts,
> > > as
> > > soon as pipe CRC is enabled it will avoid PSR1 to activate but if
> > > PSR1 is activate before that, hardware goes to lower power states
> > > that inhibits CRC calculations causing CRC timeout errors in IGT
> > > tests.

Okay, so you are solving the case where PSR is already active when we
want CRCs. How does modifying the idle frame count help if PSR is
already active? 

The commit also says PSR does not become active if CRCs were already
enabled (idle count should not matter here). In that case, just
disabling and re-enabling should be good, isn't it? Or perhaps, just
doing a psr_flush() would do the same job?

> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/intel_psr.c | 17 +++--
> > >  2 files changed, 16 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 453af7438e67..e336f758e481 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -521,6 +521,7 @@ struct i915_psr {
> > >   bool sink_not_reliable;
> > >   bool irq_aux_error;
> > >   u16 su_x_granularity;
> > > + bool crc_enabled;
> > >  };
> > >  
> > >  enum intel_pch {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index d3e3996551c6..b237d96db277 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -452,6 +452,16 @@ static void hsw_activate_psr1(struct
> > > intel_dp
> > > *intel_dp)
> > >* frames, we'll go with 9 frames for now
> > >*/
> > >   idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > > + 1);
> > > +
> > > + /*
> > > +  * Increase the idle frames to active PSR1 to avoid CRC
> > > timeouts, as
> > > +  * soon as pipe CRC is enabled it will avoid PSR1 to activate
> > > but if
> > > +  * PSR1 is activate before that, hardware goes to lower power
> > > states
> > > +  * that inhibits CRC calculations.
> > > +  */
> > > + if (dev_priv->psr.crc_enabled)
> > > + idle_frames = 0xf;
> > 
> > My understanding was only the enable bit can be changed when PSR is
> > enabled. Does this work?
> 
> That is true, the additional changes in intel_psr_update() will
> disable
> and then enable PSR with this new idle_frames.
> 
> > 
> > > +
> > >   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;

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

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Use dram_dimm_info more

2019-03-04 Thread Jani Nikula
On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Reduce the code duplication a bit by sharing the same
> code for parsing both DIMMs on a channel.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 44 ++---
>  1 file changed, 24 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9c1ff3eb5775..3d6a08e907e3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1112,25 +1112,30 @@ skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
>   return dimm->size * dimm->width / (8 * dimm->ranks ?: 1) == 16;
>  }
>  
> -static int
> -skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
> +static void
> +skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
> +int channel, char dimm_name, u16 val)

Personally I think using chars like this for dimm_name is an unnecessary
micro-optimization for const char * of length 1. But *shrug*.

Reviewed-by: Jani Nikula 

PS. What a horrible, horrible diff to review this change produced!


>  {
> - u16 tmp_l, tmp_s;
> + dimm->size = skl_get_dimm_size(val);
> + dimm->width = skl_get_dimm_width(val);
> + dimm->ranks = skl_get_dimm_ranks(val);
>  
> - tmp_l = val & 0x;
> - tmp_s = val >> 16;
> + DRM_DEBUG_KMS("CH%d DIMM %c size: %d GB, width: X%d, ranks: %d, 16Gb 
> DIMMs: %s\n",
> +   channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
> +   yesno(skl_is_16gb_dimm(dimm)));
> +}
>  
> - ch->l_info.size = skl_get_dimm_size(tmp_l);
> - ch->s_info.size = skl_get_dimm_size(tmp_s);
> +static int
> +skl_dram_get_channel_info(struct dram_channel_info *ch,
> +   int channel, u32 val)
> +{
> + skl_dram_get_dimm_info(&ch->l_info, channel, 'L', val & 0x);
> + skl_dram_get_dimm_info(&ch->s_info, channel, 'S', val >> 16);
>  
> - if (ch->l_info.size == 0 && ch->s_info.size == 0)
> + if (ch->l_info.size == 0 && ch->s_info.size == 0) {
> + DRM_DEBUG_KMS("CH%d not populated\n", channel);
>   return -EINVAL;
> -
> - ch->l_info.width = skl_get_dimm_width(tmp_l);
> - ch->s_info.width = skl_get_dimm_width(tmp_s);
> -
> - ch->l_info.ranks = skl_get_dimm_ranks(tmp_l);
> - ch->s_info.ranks = skl_get_dimm_ranks(tmp_s);
> + }
>  
>   if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
>   ch->ranks = 2;
> @@ -1143,9 +1148,8 @@ skl_dram_get_channel_info(struct dram_channel_info *ch, 
> u32 val)
>   skl_is_16gb_dimm(&ch->l_info) ||
>   skl_is_16gb_dimm(&ch->s_info);
>  
> - DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
> -   ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
> -   ch->s_info.size, ch->s_info.width, ch->s_info.ranks);
> + DRM_DEBUG_KMS("CH%d ranks: %d, 16Gb DIMMs: %s\n",
> +   channel, ch->ranks, yesno(ch->is_16gb_dimm));
>  
>   return 0;
>  }
> @@ -1165,17 +1169,17 @@ static int
>  skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
>  {
>   struct dram_info *dram_info = &dev_priv->dram_info;
> - struct dram_channel_info ch0, ch1;
> + struct dram_channel_info ch0 = {}, ch1 = {};
>   u32 val_ch0, val_ch1;
>   int ret;
>  
>   val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> - ret = skl_dram_get_channel_info(&ch0, val_ch0);
> + ret = skl_dram_get_channel_info(&ch0, 0, val_ch0);
>   if (ret == 0)
>   dram_info->num_channels++;
>  
>   val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> - ret = skl_dram_get_channel_info(&ch1, val_ch1);
> + ret = skl_dram_get_channel_info(&ch1, 1, val_ch1);
>   if (ret == 0)
>   dram_info->num_channels++;

-- 
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 10/17] drm/msm: Convert to using __drm_atomic_helper_crtc_reset() for reset.

2019-03-04 Thread Sean Paul
On Fri, Mar 01, 2019 at 01:56:20PM +0100, Maarten Lankhorst wrote:
> Convert msm to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding
> destroy_state(), call it directly for freeing the old state.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Rob Clark 
> Cc: Sean Paul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  6 ++---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 28 +--
>  2 files changed, 13 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index b776fca571f3..eb156cb73dd4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -753,14 +753,12 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc, 
> bool async)
>  
>  static void dpu_crtc_reset(struct drm_crtc *crtc)
>  {
> - struct dpu_crtc_state *cstate;
> + struct dpu_crtc_state *cstate = kzalloc(sizeof(*cstate), GFP_KERNEL);
>  
>   if (crtc->state)
>   dpu_crtc_destroy_state(crtc, crtc->state);
>  
> - crtc->state = kzalloc(sizeof(*cstate), GFP_KERNEL);
> - if (crtc->state)
> - crtc->state->crtc = crtc;
> + __drm_atomic_helper_crtc_reset(crtc, &cstate->base);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> index b0cf63c4e3d7..bf24a08feab9 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> @@ -1002,23 +1002,6 @@ mdp5_crtc_atomic_print_state(struct drm_printer *p,
>   drm_printf(p, "\tcmd_mode=%d\n", mdp5_cstate->cmd_mode);
>  }
>  
> -static void mdp5_crtc_reset(struct drm_crtc *crtc)
> -{
> - struct mdp5_crtc_state *mdp5_cstate;
> -
> - if (crtc->state) {
> - __drm_atomic_helper_crtc_destroy_state(crtc->state);
> - kfree(to_mdp5_crtc_state(crtc->state));
> - }
> -
> - mdp5_cstate = kzalloc(sizeof(*mdp5_cstate), GFP_KERNEL);
> -
> - if (mdp5_cstate) {
> - mdp5_cstate->base.crtc = crtc;
> - crtc->state = &mdp5_cstate->base;
> - }
> -}
> -
>  static struct drm_crtc_state *
>  mdp5_crtc_duplicate_state(struct drm_crtc *crtc)
>  {
> @@ -1046,6 +1029,17 @@ static void mdp5_crtc_destroy_state(struct drm_crtc 
> *crtc, struct drm_crtc_state
>   kfree(mdp5_cstate);
>  }
>  
> +static void mdp5_crtc_reset(struct drm_crtc *crtc)
> +{
> + struct mdp5_crtc_state *mdp5_cstate =
> + mdp5_cstate = kzalloc(sizeof(*mdp5_cstate), GFP_KERNEL);

Assigned twice for good measure ;)

> +
> + if (crtc->state)
> + mdp5_crtc_destroy_state(crtc, crtc->state);
> +
> + __drm_atomic_helper_crtc_reset(crtc, &mdp5_cstate->base);
> +}
> +
>  static const struct drm_crtc_funcs mdp5_crtc_funcs = {
>   .set_config = drm_atomic_helper_set_config,
>   .destroy = mdp5_crtc_destroy,
> -- 
> 2.20.1
> 

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix bit name in PP_STATUS register

2019-03-04 Thread Ville Syrjälä
On Fri, Mar 01, 2019 at 05:14:04PM -0800, Lucas De Marchi wrote:
> According to the spec PP_SEQUENCE_STATE_ON_S1_1 is the correct name, so
> just rename it.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c9b482bc6433..c9b868347481 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4723,7 +4723,7 @@ enum {
>  #define   PP_SEQUENCE_STATE_OFF_S0_2 (0x2 << 0)
>  #define   PP_SEQUENCE_STATE_OFF_S0_3 (0x3 << 0)
>  #define   PP_SEQUENCE_STATE_ON_IDLE  (0x8 << 0)
> -#define   PP_SEQUENCE_STATE_ON_S1_0  (0x9 << 0)
> +#define   PP_SEQUENCE_STATE_ON_S1_1  (0x9 << 0)
>  #define   PP_SEQUENCE_STATE_ON_S1_2  (0xa << 0)
>  #define   PP_SEQUENCE_STATE_ON_S1_3  (0xb << 0)
>  #define   PP_SEQUENCE_STATE_RESET(0xf << 0)
> -- 
> 2.20.1

-- 
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 2/2] drm/i915: fix placement of ICP_PP_CONTROL

2019-03-04 Thread Ville Syrjälä
On Fri, Mar 01, 2019 at 05:14:05PM -0800, Lucas De Marchi wrote:
> This register was placed in the middle of the PP_STATUS definition. Move
> it down together with PP_CONTROL and fix the aligment of the bit
> definition (as per documentation it should be 2 spaces instead of 1).
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c9b868347481..bbbc0649a180 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4692,17 +4692,6 @@ enum {
>  #define _PP_STATUS   0x61200
>  #define PP_STATUS(pps_idx)   _MMIO_PPS(pps_idx, _PP_STATUS)
>  #define   PP_ON  (1 << 31)
> -
> -#define _PP_CONTROL_10xc7204
> -#define _PP_CONTROL_20xc7304
> -#define ICP_PP_CONTROL(x)_MMIO(((x) == 1) ? _PP_CONTROL_1 : \
> -   _PP_CONTROL_2)
> -#define  POWER_CYCLE_DELAY_MASK  (0x1f << 4)
> -#define  POWER_CYCLE_DELAY_SHIFT 4
> -#define  VDD_OVERRIDE_FORCE  (1 << 3)
> -#define  BACKLIGHT_ENABLE(1 << 2)
> -#define  PWR_DOWN_ON_RESET   (1 << 1)
> -#define  PWR_STATE_TARGET(1 << 0)
>  /*
>   * Indicates that all dependencies of the panel are on:
>   *
> @@ -4728,6 +4717,17 @@ enum {
>  #define   PP_SEQUENCE_STATE_ON_S1_3  (0xb << 0)
>  #define   PP_SEQUENCE_STATE_RESET(0xf << 0)
>  
> +#define _PP_CONTROL_10xc7204
> +#define _PP_CONTROL_20xc7304
> +#define ICP_PP_CONTROL(x)_MMIO(((x) == 1) ? _PP_CONTROL_1 : \
> +   _PP_CONTROL_2)
> +#define   POWER_CYCLE_DELAY_MASK (0x1f << 4)
> +#define   POWER_CYCLE_DELAY_SHIFT4
> +#define   VDD_OVERRIDE_FORCE (1 << 3)
> +#define   BACKLIGHT_ENABLE   (1 << 2)
> +#define   PWR_DOWN_ON_RESET  (1 << 1)
> +#define   PWR_STATE_TARGET   (1 << 0)

This entire register looks 100% redundant. Just nuke the whole thing?

> +
>  #define _PP_CONTROL  0x61204
>  #define PP_CONTROL(pps_idx)  _MMIO_PPS(pps_idx, _PP_CONTROL)
>  #define  PANEL_UNLOCK_REGS   (0xabcd << 16)
> -- 
> 2.20.1

-- 
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 08/12] drm/i915: Generalize intel_is_dram_symmetric()

2019-03-04 Thread Jani Nikula
On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Decouple intel_is_dram_symmetric() from the raw register values
> by comparing just the dram_channel_info structs.

The idea is sound.

>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 28 
>  1 file changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3d6a08e907e3..9261bd0dccd6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1155,14 +1155,12 @@ skl_dram_get_channel_info(struct dram_channel_info 
> *ch,
>  }
>  
>  static bool
> -intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
> - struct dram_channel_info *ch0)
> +intel_is_dram_symmetric(const struct dram_channel_info *ch0,
> + const struct dram_channel_info *ch1)
>  {
> - return (val_ch0 == val_ch1 &&
> + return !memcmp(ch0, ch1, sizeof(*ch0)) &&
>   (ch0->s_info.size == 0 ||
> -  (ch0->l_info.size == ch0->s_info.size &&
> -   ch0->l_info.width == ch0->s_info.width &&
> -   ch0->l_info.ranks == ch0->s_info.ranks)));
> +  !memcmp(&ch0->l_info, &ch0->s_info, sizeof(ch0->l_info)));

However using memcmp like this gives me the creeps. It's probably going
to work just fine. It's just the knowledge that it's not guaranteed to
work that bugs me.

Oh well.

Reviewed-by: Jani Nikula 

>  }
>  
>  static int
> @@ -1170,16 +1168,16 @@ skl_dram_get_channels_info(struct drm_i915_private 
> *dev_priv)
>  {
>   struct dram_info *dram_info = &dev_priv->dram_info;
>   struct dram_channel_info ch0 = {}, ch1 = {};
> - u32 val_ch0, val_ch1;
> + u32 val;
>   int ret;
>  
> - val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> - ret = skl_dram_get_channel_info(&ch0, 0, val_ch0);
> + val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> + ret = skl_dram_get_channel_info(&ch0, 0, val);
>   if (ret == 0)
>   dram_info->num_channels++;
>  
> - val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> - ret = skl_dram_get_channel_info(&ch1, 1, val_ch1);
> + val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> + ret = skl_dram_get_channel_info(&ch1, 1, val);
>   if (ret == 0)
>   dram_info->num_channels++;
>  
> @@ -1205,12 +1203,10 @@ skl_dram_get_channels_info(struct drm_i915_private 
> *dev_priv)
>  
>   dram_info->is_16gb_dimm = ch0.is_16gb_dimm || ch1.is_16gb_dimm;
>  
> - dev_priv->dram_info.symmetric_memory = intel_is_dram_symmetric(val_ch0,
> -val_ch1,
> -&ch0);
> + dram_info->symmetric_memory = intel_is_dram_symmetric(&ch0, &ch1);
>  
> - DRM_DEBUG_KMS("memory configuration is %sSymmetric memory\n",
> -   dev_priv->dram_info.symmetric_memory ? "" : "not ");
> + DRM_DEBUG_KMS("Memory configuration is symmetric? %s\n",
> +   yesno(dram_info->symmetric_memory));
>   return 0;
>  }

-- 
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 09/12] drm/i914: s/l_info/dimm_l/ etc.

2019-03-04 Thread Jani Nikula
On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Rename the dimm info structs for clarity.

Reviewed-by: Jani Nikula 


>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 18 +-
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9261bd0dccd6..21413069a480 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1129,24 +1129,24 @@ static int
>  skl_dram_get_channel_info(struct dram_channel_info *ch,
> int channel, u32 val)
>  {
> - skl_dram_get_dimm_info(&ch->l_info, channel, 'L', val & 0x);
> - skl_dram_get_dimm_info(&ch->s_info, channel, 'S', val >> 16);
> + skl_dram_get_dimm_info(&ch->dimm_l, channel, 'L', val & 0x);
> + skl_dram_get_dimm_info(&ch->dimm_s, channel, 'S', val >> 16);
>  
> - if (ch->l_info.size == 0 && ch->s_info.size == 0) {
> + if (ch->dimm_l.size == 0 && ch->dimm_s.size == 0) {
>   DRM_DEBUG_KMS("CH%d not populated\n", channel);
>   return -EINVAL;
>   }
>  
> - if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
> + if (ch->dimm_l.ranks == 2 || ch->dimm_s.ranks == 2)
>   ch->ranks = 2;
> - else if (ch->l_info.ranks == 1 && ch->s_info.ranks == 1)
> + else if (ch->dimm_l.ranks == 1 && ch->dimm_s.ranks == 1)
>   ch->ranks = 2;
>   else
>   ch->ranks = 1;
>  
>   ch->is_16gb_dimm =
> - skl_is_16gb_dimm(&ch->l_info) ||
> - skl_is_16gb_dimm(&ch->s_info);
> + skl_is_16gb_dimm(&ch->dimm_l) ||
> + skl_is_16gb_dimm(&ch->dimm_s);
>  
>   DRM_DEBUG_KMS("CH%d ranks: %d, 16Gb DIMMs: %s\n",
> channel, ch->ranks, yesno(ch->is_16gb_dimm));
> @@ -1159,8 +1159,8 @@ intel_is_dram_symmetric(const struct dram_channel_info 
> *ch0,
>   const struct dram_channel_info *ch1)
>  {
>   return !memcmp(ch0, ch1, sizeof(*ch0)) &&
> - (ch0->s_info.size == 0 ||
> -  !memcmp(&ch0->l_info, &ch0->s_info, sizeof(ch0->l_info)));
> + (ch0->dimm_s.size == 0 ||
> +  !memcmp(&ch0->dimm_l, &ch0->dimm_s, sizeof(ch0->dimm_l)));
>  }
>  
>  static int
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fcde09934bb5..89881b68dcb4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2070,7 +2070,7 @@ struct dram_dimm_info {
>  };
>  
>  struct dram_channel_info {
> - struct dram_dimm_info l_info, s_info;
> + struct dram_dimm_info dimm_l, dimm_s;
>   u8 ranks;
>   bool is_16gb_dimm;
>  };

-- 
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 10/12] drm/i915: Clean up intel_get_dram_info() a bit

2019-03-04 Thread Jani Nikula
On Mon, 25 Feb 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Remove the pointless zero initialization of bunch of things
> (the thing is kzalloc()ed).
>
> Also throw out the mostly useless on-stack string. I think
> it'll be clear enough from the logs that 0 means unknown.

Yeah. Alternatively you could just do DRM_DEBUG_KMS in both if branches
instead of using a buffer.

Reviewed-by: Jani Nikula 

>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 21413069a480..e3aafe2bf3b7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1357,14 +1357,8 @@ static void
>  intel_get_dram_info(struct drm_i915_private *dev_priv)
>  {
>   struct dram_info *dram_info = &dev_priv->dram_info;
> - char bandwidth_str[32];
>   int ret;
>  
> - dram_info->valid = false;
> - dram_info->ranks = 0;
> - dram_info->bandwidth_kbps = 0;
> - dram_info->num_channels = 0;
> -
>   /*
>* Assume 16Gb DIMMs are present until proven otherwise.
>* This is only used for the level 0 watermark latency
> @@ -1385,12 +1379,10 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
>   if (ret)
>   return;
>  
> - if (dram_info->bandwidth_kbps)
> - sprintf(bandwidth_str, "%d KBps", dram_info->bandwidth_kbps);
> - else
> - sprintf(bandwidth_str, "unknown");
> - DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
> -   bandwidth_str, dram_info->num_channels);
> + DRM_DEBUG_KMS("DRAM bandwidth: %u kBps, channels: %u\n",
> +   dram_info->bandwidth_kbps,
> +   dram_info->num_channels);
> +
>   DRM_DEBUG_KMS("DRAM ranks: %d, 16Gb DIMMs: %s\n",
> dram_info->ranks, yesno(dram_info->is_16gb_dimm));
>  }

-- 
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 v4 7/9] drm/i915: Drop redundant checks to update PSR state

2019-03-04 Thread Souza, Jose
On Mon, 2019-03-04 at 10:54 -0800, Dhinakaran Pandiyan wrote:
> On Mon, 2019-03-04 at 10:42 -0800, Rodrigo Vivi wrote:
> > On Fri, Mar 01, 2019 at 05:34:54PM -0800, José Roberto de Souza
> > wrote:
> > > All of this checks are redudant and can be removed as the if
> > > bellow
> > > already takes care when there is no changes in the state.
> > 
> > is it just redundant or does it really change the behaviour for
> > PSR2
> > as needed?
> 
> I have the same question now that I read José's response to patch
> 8/9.
> At first, I ignored reading this patch because it included the word
> "redundant" in the commit message :)


It is just redudant, the 'if (enable == psr->enabled && psr2_enable ==
psr->psr2_enabled)' takes care of going from PSR1 -> PSR1, PSR2 -> PSR2
and disabled -> disabled, all other combinations requires one the calls
bellow that can be simplified.


> 
> > code seems right, explanation here not so sure...
> > but if this is really right and I am missing something feel
> > free to use:
> > 
> > 
> > Reviewed-by: Rodrigo Vivi 
> > 
> > otherwise please change the msg.
> > 
> > Thanks,
> > Rodrigo.
> > 
> > > Cc: Dhinakaran Pandiyan 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/intel_psr.c | 12 
> > >  1 file changed, 4 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 73453d89a841..d3e3996551c6 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -878,15 +878,11 @@ void intel_psr_update(struct intel_dp
> > > *intel_dp,
> > >   if (enable == psr->enabled && psr2_enable == psr->psr2_enabled)
> > >   goto unlock;
> > >  
> > > - if (psr->enabled) {
> > > - if (!enable || psr2_enable != psr->psr2_enabled)
> > > - intel_psr_disable_locked(intel_dp);
> > > - }
> > > + if (psr->enabled)
> > > + intel_psr_disable_locked(intel_dp);
> > >  
> > > - if (enable) {
> > > - if (!psr->enabled || psr2_enable != psr->psr2_enabled)
> > > - intel_psr_enable_locked(dev_priv, crtc_state);
> > > - }
> > > + if (enable)
> > > + intel_psr_enable_locked(dev_priv, crtc_state);
> > >  
> > >  unlock:
> > >   mutex_unlock(&dev_priv->psr.lock);
> > > -- 
> > > 2.21.0
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx


signature.asc
Description: This is a digitally signed message part
___
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/i915/psr: Set idle frames to maximum while getting pipe CRC

2019-03-04 Thread Souza, Jose
On Mon, 2019-03-04 at 11:00 -0800, Dhinakaran Pandiyan wrote:
> On Mon, 2019-03-04 at 10:40 -0800, Souza, Jose wrote:
> > On Mon, 2019-03-04 at 10:31 -0800, Dhinakaran Pandiyan wrote:
> > > On Fri, 2019-03-01 at 17:34 -0800, José Roberto de Souza wrote:
> > > > Increase the idle frames to activate PSR1 to avoid CRC
> > > > timeouts,
> > > > as
> > > > soon as pipe CRC is enabled it will avoid PSR1 to activate but
> > > > if
> > > > PSR1 is activate before that, hardware goes to lower power
> > > > states
> > > > that inhibits CRC calculations causing CRC timeout errors in
> > > > IGT
> > > > tests.
> 
> Okay, so you are solving the case where PSR is already active when we
> want CRCs. How does modifying the idle frame count help if PSR is
> already active?

Exactly this sporadicts timeout should be caused by this:

- IGT test modify frontbuffer or do a flip
- IGT execution is preempted and it takes more than X idle frames
- PSR is activated
- IGT test start CRC capture
- CRC timeout

So increasing the idle frames should reduce the scenario above.

> 
> The commit also says PSR does not become active if CRCs were already
> enabled (idle count should not matter here). In that case, just
> disabling and re-enabling should be good, isn't it? Or perhaps, just
> doing a psr_flush() would do the same job?

Good suggestion, psr_flush() should do the same job I will test and
change to that.

> 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > > >  drivers/gpu/drm/i915/intel_psr.c | 17 +++--
> > > >  2 files changed, 16 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 453af7438e67..e336f758e481 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -521,6 +521,7 @@ struct i915_psr {
> > > > bool sink_not_reliable;
> > > > bool irq_aux_error;
> > > > u16 su_x_granularity;
> > > > +   bool crc_enabled;
> > > >  };
> > > >  
> > > >  enum intel_pch {
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index d3e3996551c6..b237d96db277 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -452,6 +452,16 @@ static void hsw_activate_psr1(struct
> > > > intel_dp
> > > > *intel_dp)
> > > >  * frames, we'll go with 9 frames for now
> > > >  */
> > > > idle_frames = max(idle_frames, dev_priv-
> > > > >psr.sink_sync_latency
> > > > + 1);
> > > > +
> > > > +   /*
> > > > +* Increase the idle frames to active PSR1 to avoid CRC
> > > > timeouts, as
> > > > +* soon as pipe CRC is enabled it will avoid PSR1 to
> > > > activate
> > > > but if
> > > > +* PSR1 is activate before that, hardware goes to lower
> > > > power
> > > > states
> > > > +* that inhibits CRC calculations.
> > > > +*/
> > > > +   if (dev_priv->psr.crc_enabled)
> > > > +   idle_frames = 0xf;
> > > 
> > > My understanding was only the enable bit can be changed when PSR
> > > is
> > > enabled. Does this work?
> > 
> > That is true, the additional changes in intel_psr_update() will
> > disable
> > and then enable PSR with this new idle_frames.
> > 
> > > > +
> > > > val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  1   2   >