Re: [Intel-gfx] [PULL] drm-intel-fixes

[Daniel Vetter]

On Fri, Jul 31, 2015 at 9:07 PM, Linus Torvalds
 wrote:
> On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter  wrote:
>>
>> I delayed my -fixes pull a bit hoping that I could include a fix for the
>> dp mst stuff but looks a bit more nasty than that. So just 3 other
>> regression fixes, one 4.2 other two cc: stable.
>
> Quick question: you can now reproduce the mst problem that Ted
> reported? You said you found a mst bridge..
>
> This matters mainly because I wonder if I should apply my temporary
> workaround patch, or expect that a real fix is coming soon..

Yeah I have matching fireworks now I think, took a bit of trickery
since I plugged the mst into a desktop which means it'll use pipe A by
default. The fun seems to only happen on the other pipes ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Danilo Cesar Lemes de Paula]

Describing arguments at top of a struct definition works fine
for small/medium size structs, but it definitely doesn't work well
for struct with a huge list of elements.

Keeping the arguments list inside the struct body makes it easier
to maintain the documentation.
ie:
/**
 * struct my_struct - short description
 * @a: first member
 * @b: second member
 *
 * Longer description
 */
struct my_struct {
int a;
int b;
/**
 * @c: This is longer description of C
 *
 * You can use paragraphs to describe arguments
 * using this method.
 */
int c;
};

This patch allows the use of this kind of syntax. Only one argument
per comment and user can use how many paragraphs he needs. It should
start with /**, which is already being used by kernel-doc. If those
comment doesn't follow those rules, it will be ignored.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 scripts/kernel-doc | 80 --
 1 file changed, 78 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9922e66..9bfa8b9 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -133,6 +133,30 @@ use strict;
 #
 # All descriptions can be multiline, except the short function description.
 #
+# For really longs structs, you can also describe arguments inside the
+# body of the struct.
+# eg.
+# /**
+#  * struct my_struct - short description
+#  * @a: first member
+#  * @b: second member
+#  *
+#  * Longer description
+#  */
+# struct my_struct {
+# int a;
+# int b;
+# /**
+#  * @c: This is longer description of C
+#  *
+#  * You can use paragraphs to describe arguments
+#  * using this method.
+#  */
+# int c;
+# };
+#
+# This should be use for arguments only.
+#
 # You can also add additional sections. When documenting kernel functions you
 # should document the "Context:" of the function, e.g. whether the functions
 # can be called form interrupts. Unlike other sections you can end it with an
@@ -287,9 +311,19 @@ my $lineprefix="";
 # 2 - scanning field start.
 # 3 - scanning prototype.
 # 4 - documentation block
+# 5 - gathering documentation outside main block
 my $state;
 my $in_doc_sect;
 
+# Split Doc State
+# 0 - Invalid (Before start or after finish)
+# 1 - Is started (the /** was found inside a struct)
+# 2 - The @parameter header was found, start accepting multi paragraph text.
+# 3 - Finished (the */ was found)
+# 4 - Error - Comment without header was found. Spit a warning as it's not
+# proper kernel-doc and ignore the rest.
+my $split_doc_state;
+
 #declaration types: can be
 # 'function', 'struct', 'union', 'enum', 'typedef'
 my $decl_type;
@@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
 my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
 my $doc_content = $doc_com_body . '(.*)';
 my $doc_block = $doc_com . 'DOC:\s*(.*)?';
+my $doc_split_start = '^\s*/\*\*\s*$';
+my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
+my $doc_split_end = '^\s*\*/\s*$';
 
 my %constants;
 my %parameterdescs;
@@ -2181,6 +2218,7 @@ sub reset_state {
 $prototype = "";
 
 $state = 0;
+$split_doc_state = 0;
 }
 
 sub tracepoint_munge($) {
@@ -2453,7 +2491,6 @@ sub process_file($) {
}
$section = $newsection;
} elsif (/$doc_end/) {
-
if (($contents ne "") && ($contents ne "\n")) {
dump_section($file, $section, xml_escape($contents));
$section = $section_default;
@@ -2494,8 +2531,47 @@ sub process_file($) {
print STDERR "Warning(${file}:$.): bad line: $_";
++$warnings;
}
+   } elsif ($state == 5) { # scanning for split parameters
+
+   # First line (state 1) needs to be a @parameter
+   if ($split_doc_state == 1 && /$doc_split_sect/o) {
+   $section = $1;
+   $contents = $2;
+   if ($contents ne "") {
+   while ((substr($contents, 0, 1) eq " ") ||
+   substr($contents, 0, 1) eq "\t") {
+   $contents = substr($contents, 1);
+   }
+   $contents .= "\n";
+   }
+   $split_doc_state = 2;
+
+   # End commend */
+   } elsif (/$doc_split_end/) {
+   if (($contents ne "") && ($contents ne "\n")) {
+   dump_section($file, $section, xml_escape($contents));
+   $section = $section_default;
+   $contents = "";
+   }
+   $state = 3;
+   $split_doc_state = 0;
+
+   # Regular text
+   } elsif (/$doc_content/) {
+   if ($split_doc

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()

[Chris Wilson]

On Fri, Jul 31, 2015 at 05:42:23PM -0300, Tiago Vignatti wrote:
> For now we're opting out devices that don't have the LLC CPU cache (mostly
> "Atom" devices). Alternatively, we could build up a path to mmap them through
> GTT WC (and ignore the fact that will be dead-slow for reading). Or, an even
> more complex work I believe, would involve on setting up dma-buf ioctls to
> allow userspace flush, controlling manually the synchronization via
> begin{,end}_cpu_access.
> 
> Signed-off-by: Tiago Vignatti 
> ---
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index e9c2bfd..e6cb402 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -193,7 +193,26 @@ static void i915_gem_dmabuf_kunmap(struct dma_buf 
> *dma_buf, unsigned long page_n
>  
>  static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct 
> vm_area_struct *vma)
>  {
> - return -EINVAL;
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> + struct drm_device *dev = obj->base.dev;
> + int ret;
> +
> + if (obj->base.size < vma->vm_end - vma->vm_start)
> + return -EINVAL;
> +
> + /* On non-LLC machines we'd need to be careful cause CPU and GPU don't
> +  * share the CPU's L3 cache and coherency may hurt when CPU mapping. */
> + if (!HAS_LLC(dev))
> + return -EINVAL;

The first problem is that llc does not guarrantee that the buffer is
cache coherent with all aspects of the GPU. For scanout and similar
writes need to be WC.

if (obj->has_framebuffer_references) would at least catch where the fb
is made before the mmap.

Equally this buffer could then be shared with other devices and exposing
a CPU mmap to userspace (and no flush/set-domain protocol) will result in
corruption.

> + if (!obj->base.filp)
> + return -EINVAL;
> +
> + ret = obj->base.filp->f_op->mmap(obj->base.filp, vma);
> + fput(vma->vm_file);
> + vma->vm_file = get_file(obj->base.filp);

Transfer owenership even if the ->mmap() fails?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm: prime: Honour O_RDWR during prime-handle-to-fd

[Tiago Vignatti]

From: Daniel Thompson 

Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.

It is trivial to relax the restriction and permit read/write access.
This is safe because the flags are seldom touched by drm; mostly they
are passed verbatim to dma_buf calls.

v3 (Tiago): removed unused flags variable from drm_prime_handle_to_fd_ioctl.

Signed-off-by: Daniel Thompson 
Signed-off-by: Tiago Vignatti 
---
 drivers/gpu/drm/drm_prime.c | 10 +++---
 include/uapi/drm/drm.h  |  1 +
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 27aa718..df6cdc7 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -329,7 +329,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  * drm_gem_prime_export - helper library implementation of the export callback
  * @dev: drm_device to export from
  * @obj: GEM object to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC and DRM_RDWR
  *
  * This is the implementation of the gem_prime_export functions for GEM drivers
  * using the PRIME helpers.
@@ -628,7 +628,6 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
 struct drm_file *file_priv)
 {
struct drm_prime_handle *args = data;
-   uint32_t flags;
 
if (!drm_core_check_feature(dev, DRIVER_PRIME))
return -EINVAL;
@@ -637,14 +636,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
return -ENOSYS;
 
/* check flags are valid */
-   if (args->flags & ~DRM_CLOEXEC)
+   if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
return -EINVAL;
 
-   /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
-   flags = args->flags & DRM_CLOEXEC;
-
return dev->driver->prime_handle_to_fd(dev, file_priv,
-   args->handle, flags, &args->fd);
+   args->handle, args->flags, &args->fd);
 }
 
 int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..ad8223e 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -668,6 +668,7 @@ struct drm_set_client_cap {
__u64 value;
 };
 
+#define DRM_RDWR O_RDWR
 #define DRM_CLOEXEC O_CLOEXEC
 struct drm_prime_handle {
__u32 handle;
-- 
2.1.0

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

[Intel-gfx] [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()

[Tiago Vignatti]

For now we're opting out devices that don't have the LLC CPU cache (mostly
"Atom" devices). Alternatively, we could build up a path to mmap them through
GTT WC (and ignore the fact that will be dead-slow for reading). Or, an even
more complex work I believe, would involve on setting up dma-buf ioctls to
allow userspace flush, controlling manually the synchronization via
begin{,end}_cpu_access.

Signed-off-by: Tiago Vignatti 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index e9c2bfd..e6cb402 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -193,7 +193,26 @@ static void i915_gem_dmabuf_kunmap(struct dma_buf 
*dma_buf, unsigned long page_n
 
 static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct 
*vma)
 {
-   return -EINVAL;
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+   struct drm_device *dev = obj->base.dev;
+   int ret;
+
+   if (obj->base.size < vma->vm_end - vma->vm_start)
+   return -EINVAL;
+
+   /* On non-LLC machines we'd need to be careful cause CPU and GPU don't
+* share the CPU's L3 cache and coherency may hurt when CPU mapping. */
+   if (!HAS_LLC(dev))
+   return -EINVAL;
+
+   if (!obj->base.filp)
+   return -EINVAL;
+
+   ret = obj->base.filp->f_op->mmap(obj->base.filp, vma);
+   fput(vma->vm_file);
+   vma->vm_file = get_file(obj->base.filp);
+
+   return ret;
 }
 
 static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, size_t start, 
size_t length, enum dma_data_direction direction)
-- 
2.1.0

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

[Intel-gfx] [PATCH 0/2] mmap on the dma-buf directly

[Tiago Vignatti]

Hi,

I've tested these two patches (in drm-intel-nightly, but also in CrOS kernel
v3.14) and they seem just enough for what we want to do: the idea is to create
a GEM bo in one process and pass the prime handle of the it to another
process, which in turn uses the handle only to map and write. This could be
useful for Chrome OS  architecture, where the Web content ("unpriviledged
process") maps and CPU-draws a buffer, which was previously allocated in the
GPU process ("priviledged process").

I'm using a modified igt mostly to test these things. PTAL here:
https://github.com/tiagovignatti/intel-gpu-tools/commits/prime_mmap

Thank you,

Tiago


Daniel Thompson (1):
  drm: prime: Honour O_RDWR during prime-handle-to-fd

Tiago Vignatti (1):
  drm/i915: Use CPU mapping for userspace dma-buf mmap()

 drivers/gpu/drm/drm_prime.c| 10 +++---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 -
 include/uapi/drm/drm.h |  1 +
 3 files changed, 24 insertions(+), 8 deletions(-)

-- 
2.1.0

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

[Intel-gfx] [PATCH 0/5] igt: adding parameter to drm_open_any and drm_open_any_master to allow specification of non-intel GPUs

[Micah Fedke]

Changes since last version of patch:

Addressed comments from danvet:
 - added drm_open_driver(driver_flag)
 - replaced existing drm_open_any's with cocci (separate commit)
 - updated drm_read (and some associated plumbing) to run with OPEN_ANY_GPU

The updated version of drm_read works on exynos5 and ivybrige, given the commit 
that makes the necessary lib calls generic.

Not sure if it's policy to include the cocci script or not, and where that 
might go in the tree.

Cgit of patchset: 
https://git.collabora.com/cgit/user/fedke.m/intel-gpu-tools.git/log/?h=drm_open_parameter


Micah Fedke (5):
  lib: adding drm_open_driver() interface
  convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls
with cocci
  lib: remove support for deprecated drm_open_any*() calls
  lib/tests: make kmstest_get_pipe_from_crtc_id and
igt_enable_connectors generic to prepare for platform agnostic tests
  tests: make drm_read platform agnostic

 benchmarks/gem_userptr_benchmark.c   |   2 +-
 benchmarks/intel_upload_blit_large.c |   2 +-
 benchmarks/intel_upload_blit_large_gtt.c |   2 +-
 benchmarks/intel_upload_blit_large_map.c |   2 +-
 benchmarks/intel_upload_blit_small.c |   2 +-
 debugger/eudb.c  |   2 +-
 lib/drmtest.c| 108 ---
 lib/drmtest.h|  11 ++--
 lib/igt_gt.c |   2 +-
 lib/igt_kms.c|  13 ++--
 lib/igt_kms.h|   2 +-
 tests/core_get_client_auth.c |   6 +-
 tests/core_getclient.c   |   2 +-
 tests/core_getstats.c|   2 +-
 tests/core_getversion.c  |   2 +-
 tests/drm_import_export.c|   4 +-
 tests/drm_read.c | 101 -
 tests/drm_vma_limiter.c  |   2 +-
 tests/drm_vma_limiter_cached.c   |   2 +-
 tests/drm_vma_limiter_cpu.c  |   2 +-
 tests/drm_vma_limiter_gtt.c  |   2 +-
 tests/drv_getparams.c|   2 +-
 tests/drv_hangman.c  |   4 +-
 tests/drv_suspend.c  |   2 +-
 tests/eviction_common.c  |   2 +-
 tests/gem_alive.c|   2 +-
 tests/gem_bad_address.c  |   2 +-
 tests/gem_bad_batch.c|   2 +-
 tests/gem_bad_blit.c |   2 +-
 tests/gem_bad_length.c   |   2 +-
 tests/gem_bad_reloc.c|   2 +-
 tests/gem_basic.c|   2 +-
 tests/gem_caching.c  |   2 +-
 tests/gem_concurrent_blit.c  |   4 +-
 tests/gem_cpu_reloc.c|   2 +-
 tests/gem_cs_prefetch.c  |   2 +-
 tests/gem_cs_tlb.c   |   2 +-
 tests/gem_ctx_bad_destroy.c  |   2 +-
 tests/gem_ctx_bad_exec.c |   2 +-
 tests/gem_ctx_basic.c|   4 +-
 tests/gem_ctx_create.c   |   2 +-
 tests/gem_ctx_exec.c |   2 +-
 tests/gem_ctx_param_basic.c  |   2 +-
 tests/gem_ctx_thrash.c   |   4 +-
 tests/gem_double_irq_loop.c  |   2 +-
 tests/gem_dummy_reloc_loop.c |   4 +-
 tests/gem_evict_alignment.c  |   2 +-
 tests/gem_evict_everything.c |   2 +-
 tests/gem_exec_bad_domains.c |   2 +-
 tests/gem_exec_big.c |   2 +-
 tests/gem_exec_blt.c |   2 +-
 tests/gem_exec_faulting_reloc.c  |   2 +-
 tests/gem_exec_lut_handle.c  |   2 +-
 tests/gem_exec_nop.c |   2 +-
 tests/gem_exec_params.c  |   2 +-
 tests/gem_exec_parse.c   |   2 +-
 tests/gem_fd_exhaustion.c|   2 +-
 tests/gem_fence_thrash.c |   2 +-
 tests/gem_fence_upload.c |   8 +--
 tests/gem_fenced_exec_thrash.c   |   2 +-
 tests/gem_flink.c|   6 +-
 tests/gem_flink_race.c   |   6 +-
 tests/gem_gpgpu_fill.c   |   2 +-
 tests/gem_gtt_cpu_tlb.c  |   2 +-
 tests/gem_gtt_hog.c  |   4 +-
 tests/gem_gtt_speed.c|   2 +-
 tests/gem_hang.c |   2 +-
 tests/gem_hangcheck_forcewake.c  |   2 +-
 tests/gem_largeobject.c  |   2 +-
 tests/gem_linear_blits.c |   2 +-
 tests/gem_lut_handle.c   |   2 +-
 tests/gem_madvise.c  |   8 +--
 tests/gem_media_fill.c   |   2 +-
 tests/gem_mmap.c |   2 +-
 tests/gem_mmap_gtt.c |   4 +-
 tests/gem_mmap_offset_exhaustion.c   |   2 +-
 tests/gem_mmap_wc.c  |   2 +-
 tests/gem_multi_bsd_sync_loop.c  |   4 +-
 

[Intel-gfx] [PATCH 1/5] lib: adding drm_open_driver() interface

[Micah Fedke]

---
 lib/drmtest.c | 108 ++
 lib/drmtest.h |  18 +++---
 2 files changed, 86 insertions(+), 40 deletions(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index ee5c123..4e3ddd6 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -75,23 +75,43 @@
 
 uint16_t __drm_device_id;
 
-static int is_i915_device(int fd)
+/**
+ * __get_drm_device_name:
+ *
+ * Obtains the name of the drm device driver of the opened drm fd
+ *
+ * @fd: opened drm file descriptor to query
+ * @name: output: pointer to string to be filled with the device name
+ *
+ * Returns:
+ * 0 if the name was successfully written to @name, or -1 on error
+ */
+static int __get_drm_device_name(int fd, char *name)
 {
drm_version_t version;
-   char name[5] = "";
 
memset(&version, 0, sizeof(version));
version.name_len = 4;
version.name = name;
 
-   if (drmIoctl(fd, DRM_IOCTL_VERSION, &version))
+   if (!drmIoctl(fd, DRM_IOCTL_VERSION, &version)){
return 0;
+   }
 
-   return strcmp("i915", name) == 0;
+   return -1;
 }
 
-static int
-is_intel(int fd)
+static bool is_i915_device(int fd)
+{
+   int ret;
+   char name[5] = "";
+
+   ret = __get_drm_device_name(fd, name);
+
+   return !ret && strcmp("i915", name) == 0;
+}
+
+static bool is_intel(int fd)
 {
struct drm_i915_getparam gp;
int devid = 0;
@@ -101,13 +121,13 @@ is_intel(int fd)
gp.value = &devid;
 
if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp, sizeof(gp)))
-   return 0;
+   return false;
 
if (!IS_INTEL(devid))
-   return 0;
+   return false;
 
__drm_device_id = devid;
-   return 1;
+   return true;
 }
 
 static void check_stop_rings(void)
@@ -230,19 +250,31 @@ int drm_get_card(void)
return -1;
 }
 
-/** Open the first DRM device we can find, searching up to 16 device nodes */
-int __drm_open_any(void)
+/**
+ * __drm_open_driver:
+ *
+ * Open the first DRM device we can find, searching up to 16 device nodes
+ *
+ * @chipset: OR'd flags for each chipset to search, eg. DRIVER_INTEL
+ *
+ * Returns:
+ * An open DRM fd or -1 on error
+ */
+int __drm_open_driver(int chipset)
 {
for (int i = 0; i < 16; i++) {
char name[80];
int fd;
+  bool found_intel;
 
sprintf(name, "/dev/dri/card%u", i);
fd = open(name, O_RDWR);
if (fd == -1)
continue;
+ 
+  found_intel =  is_i915_device(fd) && is_intel(fd) && (chipset & 
DRIVER_INTEL);
 
-   if (is_i915_device(fd) && is_intel(fd))
+   if ((chipset & OPEN_ANY_GPU) || found_intel)
return fd;
 
close(fd);
@@ -252,7 +284,7 @@ int __drm_open_any(void)
return -1;
 }
 
-static int __drm_open_any_render(void)
+static int __drm_open_driver_render(int chipset)
 {
char *name;
int i, fd;
@@ -307,41 +339,43 @@ static void quiescent_gpu_at_exit_render(int sig)
 }
 
 /**
- * drm_open_any:
+ * drm_open_driver:
  *
- * Open an i915 drm legacy device node. This function always returns a valid
+ * Open a drm legacy device node. This function always returns a valid
  * file descriptor.
  *
- * Returns: a i915 drm file descriptor
+ * Returns: a drm file descriptor
  */
-int drm_open_any(void)
+int drm_open_driver(int chipset)
 {
static int open_count;
-   int fd = __drm_open_any();
+   int fd = __drm_open_driver(chipset);
 
igt_require(fd >= 0);
 
if (__sync_fetch_and_add(&open_count, 1))
return fd;
 
-   gem_quiescent_gpu(fd);
-   at_exit_drm_fd = __drm_open_any();
-   igt_install_exit_handler(quiescent_gpu_at_exit);
+   if(chipset & DRIVER_INTEL){
+  gem_quiescent_gpu(fd);
+  igt_install_exit_handler(quiescent_gpu_at_exit);
+   }
+   at_exit_drm_fd = __drm_open_driver(chipset);
 
return fd;
 }
 
 /**
- * drm_open_any_master:
+ * drm_open_driver_master:
  *
- * Open an i915 drm legacy device node and ensure that it is drm master.
+ * Open a drm legacy device node and ensure that it is drm master.
  *
  * Returns:
- * The i915 drm file descriptor or -1 on error
+ * The drm file descriptor or -1 on error
  */
-int drm_open_any_master(void)
+int drm_open_driver_master(int chipset)
 {
-   int fd = drm_open_any();
+   int fd = drm_open_driver(chipset);
 
igt_require(fd >= 0);
igt_require_f(drmSetMaster(fd) == 0, "Can't become DRM master, "
@@ -351,28 +385,30 @@ int drm_open_any_master(void)
 }
 
 /**
- * drm_open_any_render:
+ * drm_open_driver_render:
  *
- * Open an i915 drm render device node.
+ * Open a drm render device node.
  *
  * Returns:
- * The i915 drm file descriptor or -1 on error
+ * The drm file descriptor or -1 on error
  */
-int drm_open_any_render(void)
+int drm_open_driver_render(int chipset)
 {
static int o

[Intel-gfx] [PATCH 3/5] lib: remove support for deprecated drm_open_any*() calls

[Micah Fedke]

---
 lib/drmtest.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/lib/drmtest.h b/lib/drmtest.h
index 740aac1..7a41ae5 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -41,13 +41,6 @@
 #define OPEN_ANY_GPU 0x1
 #define DRIVER_INTEL 0x1 << 1
 
-// provide the deprecated drm_open_any*() calls
-#define drm_open_any() drm_open_driver(OPEN_ANY_GPU)
-#define drm_open_any_master() drm_open_driver_master(OPEN_ANY_GPU)
-#define drm_open_any_render() drm_open_driver_render(OPEN_ANY_GPU)
-#define __drm_open_any() __drm_open_driver(OPEN_ANY_GPU)
-
-
 #ifdef ANDROID
 #ifndef HAVE_MMAP64
 extern void*  __mmap2(void *, size_t, int, int, int, off_t);
-- 
2.1.4

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

[Intel-gfx] [PATCH 5/5] tests: make drm_read platform agnostic

[Micah Fedke]

---
 tests/drm_read.c | 101 ++-
 1 file changed, 55 insertions(+), 46 deletions(-)

diff --git a/tests/drm_read.c b/tests/drm_read.c
index fdaf126..f60e21c 100644
--- a/tests/drm_read.c
+++ b/tests/drm_read.c
@@ -45,10 +45,15 @@
 #include "drm.h"
 #include "ioctl_wrappers.h"
 #include "drmtest.h"
+#include "igt_core.h"
 #include "igt_aux.h"
+#include "igt_kms.h"
 
 IGT_TEST_DESCRIPTION("Call read(drm) and see if it behaves.");
 
+static drmModeRes *resources;
+static int crtc_idx;
+
 static void sighandler(int sig)
 {
 }
@@ -61,16 +66,19 @@ static void assert_empty(int fd)
 
 static void generate_event(int fd)
 {
-   union drm_wait_vblank vbl;
+   drmVBlank wait_vbl;
+   unsigned crtc_idx_mask;
+   memset(&wait_vbl, 0, sizeof(wait_vbl));
 
-   /* We require that pipe 0 is running */
+   crtc_idx_mask = crtc_idx << DRM_VBLANK_HIGH_CRTC_SHIFT;
+   igt_assert(!(crtc_idx_mask & ~DRM_VBLANK_HIGH_CRTC_MASK));
 
-   vbl.request.type =
-   DRM_VBLANK_RELATIVE |
-   DRM_VBLANK_EVENT;
-   vbl.request.sequence = 0;
+   wait_vbl.request.type = crtc_idx_mask;
+   wait_vbl.request.type |= DRM_VBLANK_RELATIVE;
+   wait_vbl.request.type |= DRM_VBLANK_EVENT;
+   wait_vbl.request.sequence = 1;
 
-   do_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, &vbl);
+   igt_assert(!drmWaitVBlank(fd, &wait_vbl));
 }
 
 static void wait_for_event(int fd)
@@ -154,44 +162,23 @@ static void test_short_buffer(int in, int nonblock)
 
 static int pipe0_enabled(int fd)
 {
-   struct drm_mode_card_res res;
-   uint32_t crtcs[32];
-   int i;
-
-   /* We assume we can generate events on pipe 0. So we have better
-* make sure that is running!
-*/
-
-   memset(&res, 0, sizeof(res));
-   res.count_crtcs = 32;
-   res.crtc_id_ptr = (uintptr_t)crtcs;
-
-   if (drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, &res))
-   return 0;
-
-   if (res.count_crtcs > 32)
-   return 0;
-
-   for (i = 0; i < res.count_crtcs; i++) {
-   struct drm_i915_get_pipe_from_crtc_id get_pipe;
-   struct drm_mode_crtc mode;
-
-   memset(&get_pipe, 0, sizeof(get_pipe));
-   memset(&mode, 0, sizeof(mode));
-
-   mode.crtc_id = crtcs[i];
-
-   get_pipe.pipe = -1;
-   get_pipe.crtc_id = mode.crtc_id;
-   drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, &get_pipe);
-   if (get_pipe.pipe)
-   continue;
-
-   drmIoctl(fd, DRM_IOCTL_MODE_GETCRTC, &mode);
-   return mode.mode_valid && mode.mode.clock;
-   }
-
-   return 0;
+   drmModeRes *res;
+   drmModeCrtc *crtc;
+
+   /* We assume we can generate events on pipe 0. So we have better
+* make sure that is running!
+*/
+
+   res = drmModeGetResources(fd);
+   igt_assert(res);
+   crtc = drmModeGetCrtc(fd, res->crtcs[crtc_idx]);
+   if (!crtc){
+  return 0;
+   }
+   drmModeFreeCrtc(crtc);
+   drmModeFreeResources(res);
+
+   return crtc->mode_valid && crtc->mode.clock;
 }
 
 igt_main
@@ -202,8 +189,30 @@ igt_main
siginterrupt(SIGALRM, 1);
 
igt_fixture {
-   fd = drm_open_driver_master(DRIVER_INTEL);
+  struct kmstest_connector_config config;
+  int i, n;
+
+   fd = drm_open_driver_master(OPEN_ANY_GPU);
+   igt_enable_connectors(fd);
+   kmstest_set_vt_graphics_mode();
+
igt_require(pipe0_enabled(fd));
+
+  resources = drmModeGetResources(fd);
+  igt_assert(resources);
+
+  for (i = 0; i < resources->count_connectors; i++) {
+ for (n = 0; n < resources->count_crtcs; n++) {
+//use the first connector config we find
+if(kmstest_get_connector_config(fd, resources->connectors[i],
+1 << n, &config)){
+   crtc_idx = config.crtc_idx;
+   break;
+}
+ }
+  }
+  drmModeFreeCrtc(config.crtc);
+
}
 
igt_subtest("invalid-buffer")
-- 
2.1.4

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

[Intel-gfx] [PATCH 4/5] lib/tests: make kmstest_get_pipe_from_crtc_id and igt_enable_connectors generic to prepare for platform agnostic tests

[Micah Fedke]

---
 lib/igt_kms.c  | 13 +++--
 lib/igt_kms.h  |  2 +-
 tests/kms_flip.c   |  2 +-
 tests/kms_pipe_crc_basic.c |  2 +-
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7e956b4..c067443 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -294,7 +294,8 @@ int kmstest_get_pipe_from_crtc_id(int fd, int crtc_id)
memset(&pfci, 0, sizeof(pfci));
pfci.crtc_id = crtc_id;
ret = drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, &pfci);
-   igt_assert(ret == 0);
+   if(ret)
+  return -1;
 
return pfci.pipe;
 }
@@ -631,6 +632,10 @@ found:
config->crtc_idx = i;
config->pipe = kmstest_get_pipe_from_crtc_id(drm_fd,
 config->crtc->crtc_id);
+   if(config->pipe == -1) {
+  igt_warn("could not get pipe from crtc id, using index\n");
+  config->pipe = i;
+   }
 
drmModeFreeResources(resources);
 
@@ -1801,13 +1806,10 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe)
  * An exit handler is installed to ensure connectors are reset when the test
  * exits.
  */
-void igt_enable_connectors(void)
+void igt_enable_connectors(int drm_fd)
 {
drmModeRes *res;
drmModeConnector *c;
-   int drm_fd;
-
-   drm_fd = drm_open_driver(DRIVER_INTEL);
 
res = drmModeGetResources(drm_fd);
 
@@ -1830,7 +1832,6 @@ void igt_enable_connectors(void)
 
drmModeFreeConnector(c);
}
-   close(drm_fd);
 }
 
 /**
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 565df14..b5f007d 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -270,7 +270,7 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe);
 
 #define IGT_FIXED(i,f) ((i) << 16 | (f))
 
-void igt_enable_connectors(void);
+void igt_enable_connectors(int drm_fd);
 void igt_reset_connectors(void);
 
 #define EDID_LENGTH 128
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 4d8d0c0..a88e707 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1702,7 +1702,7 @@ int main(int argc, char **argv)
igt_fixture {
drm_fd = drm_open_driver_master(DRIVER_INTEL);
 
-   igt_enable_connectors();
+   igt_enable_connectors(drm_fd);
 
kmstest_set_vt_graphics_mode();
igt_install_exit_handler(kms_flip_exit_handler);
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index fc4ad46..10ef097 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -228,7 +228,7 @@ igt_main
igt_fixture {
data.drm_fd = drm_open_driver_master(DRIVER_INTEL);
 
-   igt_enable_connectors();
+   igt_enable_connectors(data.drm_fd);
 
kmstest_set_vt_graphics_mode();
 
-- 
2.1.4

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

[Intel-gfx] [PATCH 2/5] convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls with cocci

[Micah Fedke]

---
 benchmarks/gem_userptr_benchmark.c   |  2 +-
 benchmarks/intel_upload_blit_large.c |  2 +-
 benchmarks/intel_upload_blit_large_gtt.c |  2 +-
 benchmarks/intel_upload_blit_large_map.c |  2 +-
 benchmarks/intel_upload_blit_small.c |  2 +-
 debugger/eudb.c  |  2 +-
 lib/igt_gt.c |  2 +-
 lib/igt_kms.c|  2 +-
 tests/core_get_client_auth.c |  6 ++---
 tests/core_getclient.c   |  2 +-
 tests/core_getstats.c|  2 +-
 tests/core_getversion.c  |  2 +-
 tests/drm_import_export.c|  4 ++--
 tests/drm_read.c |  2 +-
 tests/drm_vma_limiter.c  |  2 +-
 tests/drm_vma_limiter_cached.c   |  2 +-
 tests/drm_vma_limiter_cpu.c  |  2 +-
 tests/drm_vma_limiter_gtt.c  |  2 +-
 tests/drv_getparams.c|  2 +-
 tests/drv_hangman.c  |  4 ++--
 tests/drv_suspend.c  |  2 +-
 tests/eviction_common.c  |  2 +-
 tests/gem_alive.c|  2 +-
 tests/gem_bad_address.c  |  2 +-
 tests/gem_bad_batch.c|  2 +-
 tests/gem_bad_blit.c |  2 +-
 tests/gem_bad_length.c   |  2 +-
 tests/gem_bad_reloc.c|  2 +-
 tests/gem_basic.c|  2 +-
 tests/gem_caching.c  |  2 +-
 tests/gem_concurrent_blit.c  |  4 ++--
 tests/gem_cpu_reloc.c|  2 +-
 tests/gem_cs_prefetch.c  |  2 +-
 tests/gem_cs_tlb.c   |  2 +-
 tests/gem_ctx_bad_destroy.c  |  2 +-
 tests/gem_ctx_bad_exec.c |  2 +-
 tests/gem_ctx_basic.c|  4 ++--
 tests/gem_ctx_create.c   |  2 +-
 tests/gem_ctx_exec.c |  2 +-
 tests/gem_ctx_param_basic.c  |  2 +-
 tests/gem_ctx_thrash.c   |  4 ++--
 tests/gem_double_irq_loop.c  |  2 +-
 tests/gem_dummy_reloc_loop.c |  4 ++--
 tests/gem_evict_alignment.c  |  2 +-
 tests/gem_evict_everything.c |  2 +-
 tests/gem_exec_bad_domains.c |  2 +-
 tests/gem_exec_big.c |  2 +-
 tests/gem_exec_blt.c |  2 +-
 tests/gem_exec_faulting_reloc.c  |  2 +-
 tests/gem_exec_lut_handle.c  |  2 +-
 tests/gem_exec_nop.c |  2 +-
 tests/gem_exec_params.c  |  2 +-
 tests/gem_exec_parse.c   |  2 +-
 tests/gem_fd_exhaustion.c|  2 +-
 tests/gem_fence_thrash.c |  2 +-
 tests/gem_fence_upload.c |  8 +++
 tests/gem_fenced_exec_thrash.c   |  2 +-
 tests/gem_flink.c|  6 ++---
 tests/gem_flink_race.c   |  6 ++---
 tests/gem_gpgpu_fill.c   |  2 +-
 tests/gem_gtt_cpu_tlb.c  |  2 +-
 tests/gem_gtt_hog.c  |  4 ++--
 tests/gem_gtt_speed.c|  2 +-
 tests/gem_hang.c |  2 +-
 tests/gem_hangcheck_forcewake.c  |  2 +-
 tests/gem_largeobject.c  |  2 +-
 tests/gem_linear_blits.c |  2 +-
 tests/gem_lut_handle.c   |  2 +-
 tests/gem_madvise.c  |  8 +++
 tests/gem_media_fill.c   |  2 +-
 tests/gem_mmap.c |  2 +-
 tests/gem_mmap_gtt.c |  4 ++--
 tests/gem_mmap_offset_exhaustion.c   |  2 +-
 tests/gem_mmap_wc.c  |  2 +-
 tests/gem_multi_bsd_sync_loop.c  |  4 ++--
 tests/gem_non_secure_batch.c |  2 +-
 tests/gem_partial_pwrite_pread.c |  2 +-
 tests/gem_persistent_relocs.c|  2 +-
 tests/gem_pin.c  |  2 +-
 tests/gem_pipe_control_store_loop.c  |  2 +-
 tests/gem_ppgtt.c|  4 ++--
 tests/gem_pread.c|  2 +-
 tests/gem_pread_after_blit.c |  2 +-
 tests/gem_pwrite.c   |  2 +-
 tests/gem_pwrite_pread.c |  2 +-
 tests/gem_readwrite.c|  2 +-
 tests/gem_reg_read.c |  2 +-
 tests/gem_reloc_overflow.c   |  2 +-
 tests/gem_reloc_vs_gpu.c |  4 ++--
 tests/gem_render_copy.c  |  2 +-
 tests/gem_render_copy_redux.c|  2 +-
 tests/gem_render_linear_blits.c  |  2 +-
 tests/gem_render_tiled_blits.c   |  2 +-
 tests/gem_reset_stats.c  | 40 
 tests/gem_ring_sync_copy.c   |  2 +-
 tests/gem_ring_sync_loop.c   |  2 +-
 tests/gem_ringfill.c |  2 +-
 tests/gem_seqno_wrap.c   |  2 +-
 tests/gem_set_tiling_vs

Re: [Intel-gfx] [PULL] drm-intel-fixes

[Linus Torvalds]

On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter  wrote:
>
> I delayed my -fixes pull a bit hoping that I could include a fix for the
> dp mst stuff but looks a bit more nasty than that. So just 3 other
> regression fixes, one 4.2 other two cc: stable.

Quick question: you can now reproduce the mst problem that Ted
reported? You said you found a mst bridge..

This matters mainly because I wonder if I should apply my temporary
workaround patch, or expect that a real fix is coming soon..

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

[Intel-gfx] [PATCH] intel: Drop aub dumping functionality

[krh]

From: Kristian Høgsberg Kristensen 

We now have a separate tool for this in intel-gpu-tools and we don't
need to clutter up libdrm with this feature. We leave the entry points
in there to avoid breaking API/ABI.

Signed-off-by: Kristian Høgsberg Kristensen 
---
 intel/intel_aub.h| 153 ---
 intel/intel_bufmgr_gem.c | 379 +--
 2 files changed, 2 insertions(+), 530 deletions(-)
 delete mode 100644 intel/intel_aub.h

diff --git a/intel/intel_aub.h b/intel/intel_aub.h
deleted file mode 100644
index 5f0aba8..000
--- a/intel/intel_aub.h
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * Copyright © 2010 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- * Authors:
- *Eric Anholt 
- *
- */
-
-/** @file intel_aub.h
- *
- * The AUB file is a file format used by Intel's internal simulation
- * and other validation tools.  It can be used at various levels by a
- * driver to input state to the simulated hardware or a replaying
- * debugger.
- *
- * We choose to dump AUB files using the trace block format for ease
- * of implementation -- dump out the blocks of memory as plain blobs
- * and insert ring commands to execute the batchbuffer blob.
- */
-
-#ifndef _INTEL_AUB_H
-#define _INTEL_AUB_H
-
-#define AUB_MI_NOOP(0)
-#define AUB_MI_BATCH_BUFFER_START  (0x31 << 23)
-#define AUB_PIPE_CONTROL   (0x7a02)
-
-/* DW0: instruction type. */
-
-#define CMD_AUB(7 << 29)
-
-#define CMD_AUB_HEADER (CMD_AUB | (1 << 23) | (0x05 << 16))
-/* DW1 */
-# define AUB_HEADER_MAJOR_SHIFT24
-# define AUB_HEADER_MINOR_SHIFT16
-
-#define CMD_AUB_TRACE_HEADER_BLOCK (CMD_AUB | (1 << 23) | (0x41 << 16))
-#define CMD_AUB_DUMP_BMP   (CMD_AUB | (1 << 23) | (0x9e << 16))
-
-/* DW1 */
-#define AUB_TRACE_OPERATION_MASK   0x00ff
-#define AUB_TRACE_OP_COMMENT   0x
-#define AUB_TRACE_OP_DATA_WRITE0x0001
-#define AUB_TRACE_OP_COMMAND_WRITE 0x0002
-#define AUB_TRACE_OP_MMIO_WRITE0x0003
-// operation = TRACE_DATA_WRITE, Type
-#define AUB_TRACE_TYPE_MASK0xff00
-#define AUB_TRACE_TYPE_NOTYPE  (0 << 8)
-#define AUB_TRACE_TYPE_BATCH   (1 << 8)
-#define AUB_TRACE_TYPE_VERTEX_BUFFER   (5 << 8)
-#define AUB_TRACE_TYPE_2D_MAP  (6 << 8)
-#define AUB_TRACE_TYPE_CUBE_MAP(7 << 8)
-#define AUB_TRACE_TYPE_VOLUME_MAP  (9 << 8)
-#define AUB_TRACE_TYPE_1D_MAP  (10 << 8)
-#define AUB_TRACE_TYPE_CONSTANT_BUFFER (11 << 8)
-#define AUB_TRACE_TYPE_CONSTANT_URB(12 << 8)
-#define AUB_TRACE_TYPE_INDEX_BUFFER(13 << 8)
-#define AUB_TRACE_TYPE_GENERAL (14 << 8)
-#define AUB_TRACE_TYPE_SURFACE (15 << 8)
-
-
-// operation = TRACE_COMMAND_WRITE, Type =
-#define AUB_TRACE_TYPE_RING_HWB(1 << 8)
-#define AUB_TRACE_TYPE_RING_PRB0   (2 << 8)
-#define AUB_TRACE_TYPE_RING_PRB1   (3 << 8)
-#define AUB_TRACE_TYPE_RING_PRB2   (4 << 8)
-
-// Address space
-#define AUB_TRACE_ADDRESS_SPACE_MASK   0x00ff
-#define AUB_TRACE_MEMTYPE_GTT  (0 << 16)
-#define AUB_TRACE_MEMTYPE_LOCAL(1 << 16)
-#define AUB_TRACE_MEMTYPE_NONLOCAL (2 << 16)
-#define AUB_TRACE_MEMTYPE_PCI  (3 << 16)
-#define AUB_TRACE_MEMTYPE_GTT_ENTRY (4 << 16)
-
-/* DW2 */
-
-/**
- * aub_state_struct_type enum values are encoded with the top 16 bits
- * representing the type to be delivered to the .aub file, and the bottom 16
- * bits representing the subtype.  This macro performs the encoding.
- */
-#define ENCODE_SS_TYPE(type, subtype) (((type) << 16) | (subtype))
-
-enum aub_state_struct_type {
-   AUB_TRACE_VS_STATE =
ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL, 1),
-   AUB_TRACE_GS_STATE =
ENCODE_SS_TYPE(AUB_TR

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt

[Chris Wilson]

On Fri, Jul 31, 2015 at 05:26:24PM +0100, Chris Wilson wrote:
> This performance regression is still unfixed.

Hah. Just found out that adding the git id to the version also changes
the kernel name - so everytime I was booting the wrong kernel and the
bisect ended up at the wrong patch.

So whilst we still could benefit from clearing the dirty flags after
setting them, I've just wasted a day.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 06/19] drm/i915/gen8: Add PML4 structure

[Goel, Akash]

On 7/31/2015 5:42 PM, Michel Thierry wrote:

Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.

To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.

v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
v5: Postpone 48-bit code in sanitize_enable_ppgtt (Akash).

Cc: Akash Goel 
Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
  drivers/gpu/drm/i915/i915_gem_gtt.c | 30 +-
  drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
  3 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..4729eaf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2498,7 +2498,8 @@ struct drm_i915_cmd_table {
  #define HAS_HW_CONTEXTS(dev)  (INTEL_INFO(dev)->gen >= 6)
  #define HAS_LOGICAL_RING_CONTEXTS(dev)(INTEL_INFO(dev)->gen >= 8)
  #define USES_PPGTT(dev)   (i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt >= 2)
+#define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)

  #define HAS_OVERLAY(dev)  (INTEL_INFO(dev)->has_overlay)
  #define OVERLAY_NEEDS_PHYSICAL(dev)   
(INTEL_INFO(dev)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f71746..ba99b67 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -689,9 +689,6 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
pt_vaddr = NULL;

for_each_sg_page(pages->sgl, &sg_iter, pages->nents, 0) {
-   if (WARN_ON(pdpe >= GEN8_LEGACY_PDPES))
-   break;
-

Apologize for this eleventh hour comment.
Would this change be better off in the later patch "Add 4 level support 
in insert_entries and clear_range".


Best regards
Akash


if (pt_vaddr == NULL) {
struct i915_page_directory *pd = 
pdp->page_directory[pdpe];
struct i915_page_table *pt = pd->page_table[pde];
@@ -1105,14 +1102,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;

ppgtt->base.start = 0;
-   ppgtt->base.total = 1ULL << 32;
-   if (IS_ENABLED(CONFIG_X86_32))
-   /* While we have a proliferation of size_t variables
-* we cannot represent the full ppgtt size on 32bit,
-* so limit it to the same size as the GGTT (currently
-* 2GiB).
-*/
-   ppgtt->base.total = to_i915(ppgtt->base.dev)->gtt.base.total;
ppgtt->base.cleanup = gen8_ppgtt_cleanup;
ppgtt->base.allocate_va_range = gen8_alloc_va_range;
ppgtt->base.insert_entries = gen8_ppgtt_insert_entries;
@@ -1122,10 +,25 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)

ppgtt->switch_mm = gen8_mm_switch;

-   ret = __pdp_init(false, &ppgtt->pdp);
+   if (!USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
+   ret = __pdp_init(false, &ppgtt->pdp);

-   if (ret)
+   if (ret)
+   goto free_scratch;
+
+   ppgtt->base.total = 1ULL << 32;
+   if (IS_ENABLED(CONFIG_X86_32))
+   /* While we have a proliferation of size_t variables
+* we cannot represent the full ppgtt size on 32bit,
+* so limit it to the same size as the GGTT (currently
+* 2GiB).
+*/
+   ppgtt->base.total = 
to_i915(ppgtt->base.dev)->gtt.base.total;
+   } else {
+   ppgtt->base.total = 1ULL << 48;
+   ret = -EPERM; /* Not yet implemented */
goto free_scratch;
+   }

return 0;

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 87e389c..04bc66f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -88,9 +88,17 @@ typedef uint64_t gen8_pde_t;
   * PDPE  |  PDE  |  PTE  | offset
   * The difference as compared to normal x86 3 level page table is the PDPEs 
are
   * programmed via register.
+ *
+ * GEN8 48b legacy style address is defined as a 4 level page table:
+ * 47:39 | 38:30 | 29:21 | 20:12 |  11:0
+ * PML4E | PDPE  |  PDE  |  PTE  | offset
   */
+#define GEN8_PML4ES_PER_PML4   512
+#define GEN8_PML4E_SHIFT   39
  #define GEN8_PDPE_SHIFT   30
-#define GEN8_PDPE_MASK 0x3
+/* NB: GEN8_PDPE_MASK is untrue for 32b platforms, but it has no impact on 32

Re: [Intel-gfx] [PATCH v8 18/19] drm/i915/gen8: Flip the 48b switch

[Goel, Akash]

Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "


On 7/31/2015 6:05 PM, Michel Thierry wrote:

Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Update the sanitize_enable_ppgtt for 48 bit PPGTT mode.

Note, aliasing PPGTT remains 32b only.

v2: s/full_64b/full_48b/. (Akash)
v3: Add sanitize_enable_ppgtt changes until here. (Akash)
v4: Update param description (Chris)

Cc: Akash Goel 
Cc: Chris Wilson 
Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 7 ++-
  drivers/gpu/drm/i915/i915_params.c  | 2 +-
  2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7a526f9..31d20c6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,9 +104,11 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
  {
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
+   bool has_full_48bit_ppgtt;

has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
+   has_full_48bit_ppgtt = IS_BROADWELL(dev) || INTEL_INFO(dev)->gen >= 9;

if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
@@ -125,6 +127,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
if (enable_ppgtt == 2 && has_full_ppgtt)
return 2;

+   if (enable_ppgtt == 3 && has_full_48bit_ppgtt)
+   return 3;
+
  #ifdef CONFIG_INTEL_IOMMU
/* Disable ppgtt on SNB if VT-d is on. */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) {
@@ -141,7 +146,7 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
}

if (INTEL_INFO(dev)->gen >= 8 && i915.enable_execlists)
-   return 2;
+   return has_full_48bit_ppgtt ? 3 : 2;
else
return has_aliasing_ppgtt ? 1 : 0;
  }
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 5ae4b0a..900e48a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -111,7 +111,7 @@ MODULE_PARM_DESC(enable_hangcheck,
  module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
  MODULE_PARM_DESC(enable_ppgtt,
"Override PPGTT usage. "
-   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)");
+   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full with extended 
address space)");

  module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
  MODULE_PARM_DESC(enable_execlists,


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

[Intel-gfx] [PULL] drm-intel-fixes

[Daniel Vetter]

Hi Linus,

I delayed my -fixes pull a bit hoping that I could include a fix for the
dp mst stuff but looks a bit more nasty than that. So just 3 other
regression fixes, one 4.2 other two cc: stable.

Cheers, Daniel


The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f:

  Linux 4.2-rc4 (2015-07-26 12:26:21 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-07-31

for you to fetch changes up to 5eb3e5a5e11d14f9deb2a4b83555443b69ab9940:

  drm/i915: Declare the swizzling unknown for L-shaped configurations 
(2015-07-30 16:51:20 +0200)


Chris Wilson (3):
  drm/i915: Replace WARN inside I915_READ64_2x32 with retry loop
  drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt
  drm/i915: Declare the swizzling unknown for L-shaped configurations

 drivers/gpu/drm/i915/i915_drv.h| 17 -
 drivers/gpu/drm/i915/i915_gem_gtt.c| 11 +++
 drivers/gpu/drm/i915/i915_gem_tiling.c |  5 -
 3 files changed, 23 insertions(+), 10 deletions(-)

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

Re: [Intel-gfx] [QA 2015/07/17 ww30] Testing report for `drm-intel-testing`

[Mason, Michael W]

Why are so many IGT tests blacklisted?  How does a test get put on the 
blacklist?  We've been running the full (almost) IGT suite on Chrome OS. Our 
blacklist has around 46 tests, mainly for tests that timeout, hang the system 
and don't reboot, or cause a reboot in the middle of the test. I'm wondering if 
there's some other criteria we should consider.

Thanks,
Mike


From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of 
christophe.prig...@linux.intel.com [christophe.prig...@linux.intel.com]
Sent: Saturday, July 25, 2015 7:53 AM
To: vet...@linux.intel.com; Vetter, Daniel
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [QA 2015/07/17 ww30] Testing report for `drm-intel-testing`

Hello,

We launched Intel GPU Tools on 6 platforms: Skylake-Y, Braswell-M,
Broadwell-U, Baytrail M and T, Haswell-ULT to validate kernel 4.12-rc2 tag
drm-intel-testing-2015-07-17.
Here are the results:

New bugs reported:

https://bugs.freedesktop.org/show_bug.cgi?id=91447 [BSW-BDW-U]
igt/kms_frontbuffer_tracking
https://bugs.freedesktop.org/show_bug.cgi?id=91349 [BSW-BYT-M]
igt/gem_eio/throttle result is crash
https://bugs.freedesktop.org/show_bug.cgi?id=91453 [BYT-M]
igt/gem_eio/execbuf result is crash
https://bugs.freedesktop.org/show_bug.cgi?id=91439 [byt]
igt/drv_module_reload not set to timeout (Asus T100 TA)
https://bugs.freedesktop.org/show_bug.cgi?id=91454 [hsw] igt/
gem_render_linear_blits@swap-thrash test is timing out
https://bugs.freedesktop.org/show_bug.cgi?id=91455 [hsw] igt/
gem_reloc_vs_gpu@forked-interruptible-faulting-reloc-thrash-inactive-hang
not set to time out (NUC)

Test Environment:

kernel 4.2-rc2 from git://anongit.freedesktop.org/drm-intel tag
drm-intel-testing-2015-07-17
Mesa: mesa-10.6.2 from http://cgit.freedesktop.org/mesa/mesa/
Xf86_video_intel: 2.99.917 from
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Libdrm: libdrm-2.4.62 from http://cgit.freedesktop.org/mesa/drm/
Cairo: 1.14.2 from http://cgit.freedesktop.org/cairo
libva: libva-1.6.0 from http://cgit.freedesktop.org/libva/
intel-driver: 1.6.0 from http://cgit.freedesktop.org/vaapi/intel-driver
xorg: 1.17.99 installed with script git_xorg.sh
Xserver: xorg-server-1.17.2 from http://cgit.freedesktop.org/xorg/xserver
Intel-gpu-tools: 1.11 8ad1e4077879a111f341dbfd2e0fee84efc9f57e from
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

Results:

Platform| Available | Blacklisted   | Skipped   | Executed  
| % Pass| % Exe
--
SKL | 5756  | 4029  | 145   | 1582  
| 19.53%| 91.60%
BSW | 5756  | 3882  | 178   | 1696  
| 44.22%| 90.50%
BDW-U   | 5756  | 4017  | 149   | 1590  
| 56.86%| 91.43%
BYT-T   | 5756  | 3851  | 972   | 933   
| 65.70%| 48.98%
BYT-M   | 5756  | 3851  | 661   | 1244  
| 72.03%| 65.30%
HSW-U   | 5763  | 3806  | 806   | 1151  
| 86.27%| 58.81%
--

Last week results:

Platform| Total | Executed  | Pass  | % Executed| % Pass
-
SKL | 1745  | 1644  | 276   | 94.21%| 16.79%
BSW | 1887  | 1087  | 855   | 57.60%| 78.66%
BDW-U   | 1755  | 1614  | 1063  | 91.97%| 65.86%
BYT-T   | 1920  | 1472  | 736   | 76.67%| 50.00%
BYT-M   | 1920  | 1840  | 322   | 95.83%| 17.50%
HSW-U   | 1894  | 1714  | 1275  | 90.50%| 74.39%
-

Known bugs:

SKL
https://bugs.freedesktop.org/show_bug.cgi?id=89959
[SKL]igt/gem_concurrent_blit subcase sporadically causes system hang and
*ERROR* blitter: timed out waiting for forcewake ack to clear.
https://bugs.freedesktop.org/show_bug.cgi?id=89728 [HSW/BDW/BSW/SKL
bisected] igt/pm_rps/ subcases reset and blocking fail
https://bugs.freedesktop.org/show_bug.cgi?id=89928
[SKL]igt/gem_evict_everything/forked-mempressure-interruptible takes more
than 10 minutes
https://bugs.freedesktop.org/show_bug.cgi?id=90546 [BDW/BSW/SKL
bisected]igt/pm_rpm/drm-resources-equal fails
https://bugs.freedesktop.org/show_bug.cgi?id=86763 [BSW/SKL]igt/kms_plane
some su

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add support for stealing purgable stolen pages

[Goel, Akash]

On 7/31/2015 8:36 PM, Chris Wilson wrote:

On Fri, Jul 31, 2015 at 08:12:30PM +0530, Goel, Akash wrote:



On 7/29/2015 5:34 PM, Chris Wilson wrote:

On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:

Chris and I just discussed on irc that the bound_list isn't in a great LRU
order right now and Chris sent out a fix for that. But it only works if we
preferrentially shrink inactive objects first. Worth the bother or just a
FIXME? For the fb use-case alone it's not needed since we can't remove the
fb until it's no longer being displayed (otherwise the backwards-compat
code kicks in and synchronously kills the display at RMFB time), and that
pretty much means we can't put the underlying bo into any cache (and mark
it purgeable) either. But a FIXME comment here would be good for sure,
just in case this assumption ever gets broken.


I've been mucking around with patch a bit (with contexts-from-stolen
reenabled) and the list ierators used here are terrible; severely
impacting our allocations by a few orders of magnitude (imagine having
just the ggtt full of 4k objects, let alone several ppgtt all full of
their own bound 4k objetcs).

To combat this will require a special purgeable list maintaind by
madv(), and subclassing the struct drm_mm_node to hold our extra
details.


Should we add a separate purgeable list for stolen objects ?


/** Stolen memory for this object, instead of being backed by shmem. */
- struct drm_mm_node *stolen;
+ struct i915_gem_stolen *stolen;


struct i915_gem_stolen {
struct drm_mm_node *node;
struct list_head purge_list;
};


Almost. You will need a backpointer from the node to the object so you
can do your list iteration and purge the unwanted object.
Agree that a back pointer is also needed, as the stolen structure will 
not be embedded in the object structure. Thanks.



http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=1094f92e6d94190cf1334fd9bd6459ab70801455


More thanks for providing the reference implementation.

Best regards
Akash

-Chris


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

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt

[Chris Wilson]

On Thu, Apr 23, 2015 at 08:56:40PM +0200, Daniel Vetter wrote:
> On Thu, Apr 23, 2015 at 04:43:52PM +0100, Chris Wilson wrote:
> > On Fri, Apr 17, 2015 at 04:49:18PM +0300, Mika Kuoppala wrote:
> > > Daniel Vetter  writes:
> > > 
> > > > On Tue, Apr 14, 2015 at 06:53:41PM +0100, Chris Wilson wrote:
> > > >> On Tue, Apr 14, 2015 at 07:11:25PM +0200, Daniel Vetter wrote:
> > > >> > On Tue, Apr 14, 2015 at 05:06:36PM +0100, Chris Wilson wrote:
> > > >> > > On Tue, Apr 14, 2015 at 05:35:18PM +0200, Daniel Vetter wrote:
> > > >> > > > We load the ppgtt ptes once per gpu reset/driver load/resume and
> > > >> > > > that's all that's needed. Note that this only blows up when we're
> > > >> > > > using the allocate_va_range funcs and not the special-purpose 
> > > >> > > > ones
> > > >> > > > used. With this change we can get rid of that duplication.
> > > >> > > 
> > > >> > > Honestly, I would prefer the test to be rewritten so that the
> > > >> > > information on which vm was being used was passed along and not 
> > > >> > > that
> > > >> > > magic sprinkled in the middle of nowhere. e.g. execbuffer knows 
> > > >> > > exactly
> > > >> > > what vm it bound the objects into, and yet towards the end we 
> > > >> > > decide to
> > > >> > > guess again. Also, I would rather the execbuffer test be moved to
> > > >> > > i915_gem_context since it is scattering internal knowledge about.
> > > >> > 
> > > >> > Yeah I agree that there's more room for cleanup. I've done this 
> > > >> > minimal
> > > >> > patch purely to shut up the bogus WARN_ONs when I tried to unify the
> > > >> > gen6/7 pt alloc code in the next patch. Since it's bogus.
> > > >> 
> > > >> How about:
> > > >
> > > > Yeah, but imo there's also more. I tried to understand the gen8 legacy 
> > > > ctx
> > > > switch logic and failed, and I wasn't fully convinced that the gen7 one
> > > > won't WARN if we actually enable full ppgtt. Given all that I decided to
> > > > go with the most minimal patch and just removed the offending bogus 
> > > > WARN.
> > > > But Mika/Michel promised to hang around for eventual cleanups?
> > > 
> > > Yes. There is more to come after this series.
> > > I can include Chris's suggestion.
> > 
> > Looking at this WARN that fires continually on gen6/gen7, (it's nice to
> > have such a blatant WARN to explain the perf decrease), don't we need
> > 
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index a1a9f5dad541..006d4a2610f7 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -1562,6 +1562,8 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
> > ret = ppgtt->switch_mm(ppgtt, ring);
> > if (ret != 0)
> > return ret;
> > +
> > +   ppgtt->pd_dirty_rings &= ~(1 << i);
> > }
> > }
> 
> Yeah, but I didn't really see the point in the debug infrastructure for
> aliasing ppgtt. The pde loading is done somewhere completely else than for
> full ppgtt. And if we forget to load the pdes the effects are obvious,
> whereas failing to reload when changes happen with full ppgtt is much
> harder to spot quickly. So I opted to undo those checks again, they have
> been defunct before my changes anyway.

This performance regression is still unfixed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gen9: Update null batch to follow VF state restriction

[Arun Siluvery]

Atleast one component of one valid vertex element must be enabled.

Cc: Ben Widawsky 
Cc: Chris Wilson 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/intel_renderstate_gen9.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen9.c 
b/drivers/gpu/drm/i915/intel_renderstate_gen9.c
index 16a7ec2..fa86431 100644
--- a/drivers/gpu/drm/i915/intel_renderstate_gen9.c
+++ b/drivers/gpu/drm/i915/intel_renderstate_gen9.c
@@ -873,7 +873,7 @@ static const u32 gen9_null_state_batch[] = {
0x,
0x,
0x78550003,
-   0x,
+   0x0001,
0x,
0x,
0x,
-- 
1.9.1

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

[Intel-gfx] [PATCH] tools/null_state/gen9: Send atleast one valid component in VF state

[Arun Siluvery]

A programming restriction exists for this instruction, atleast one component
of one valid vertex element must be enabled.

Cc: Ben Widawsky 
Cc: Chris Wilson 
Signed-off-by: Arun Siluvery 
---
 tools/null_state_gen/intel_renderstate_gen9.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/null_state_gen/intel_renderstate_gen9.c 
b/tools/null_state_gen/intel_renderstate_gen9.c
index 6f808f8..b3766ea 100644
--- a/tools/null_state_gen/intel_renderstate_gen9.c
+++ b/tools/null_state_gen/intel_renderstate_gen9.c
@@ -440,7 +440,12 @@ int gen9_setup_null_render_state(struct intel_batchbuffer 
*batch)
/* Vertex buffers */
gen8_emit_vertex_buffers(batch);
gen8_emit_vertex_elements(batch);
-   OUT_CMD(GEN9_3DSTATE_COMPONENT_PACKING, 5);
+
+   OUT_BATCH(GEN9_3DSTATE_COMPONENT_PACKING | 3);
+   OUT_BATCH(1);
+   OUT_BATCH(0);
+   OUT_BATCH(0);
+   OUT_BATCH(0);
 
OUT_BATCH(GEN6_3DSTATE_VF_STATISTICS | 1 /* Enable */);
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix FBC frontbuffer tracking flushing code

[Paulo Zanoni]

2015-07-30 20:37 GMT-03:00 Rodrigo Vivi :
>
>
> On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni  wrote:
>>
>> From: Paulo Zanoni 
>>
>> Due to the way busy_bits was handled, we were not doing any flushes if
>> we didn't previously get an invalidate. Since it's possible to get
>> flushes without an invalidate first, remove the busy_bits early
>> return.
>>
>> So now that we don't have the busy_bits guard anymore we'll need the
>> origin check for the GTT tracking (we were not doing anything on GTT
>> flushes due to the GTT check at invalidate()).
>>
>> As a last detail, since we can get multiple consecutive flushes,
>> disable FBC before updating it, otherwise intel_fbc_update() will just
>> keep FBC enabled instead of restarting it.
>>
>> Notice that this does not fix any of the current IGT tests due to the
>> fact that we still have a few intel_fbc() calls at points where we
>> also have the frontbuffer tracking calls: we didn't fully convert to
>> frontbuffer tracking yet. Once we remove those calls and start relying
>> only on the frontbuffer tracking infrastructure we'll need this patch.
>>
>> Signed-off-by: Paulo Zanoni 
>> ---
>>  drivers/gpu/drm/i915/intel_drv.h |  2 +-
>>  drivers/gpu/drm/i915/intel_fbc.c | 13 +++--
>>  drivers/gpu/drm/i915/intel_frontbuffer.c |  2 +-
>>  3 files changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index f4abce1..2437666 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1240,7 +1240,7 @@ void intel_fbc_invalidate(struct drm_i915_private
>> *dev_priv,
>>   unsigned int frontbuffer_bits,
>>   enum fb_op_origin origin);
>>  void intel_fbc_flush(struct drm_i915_private *dev_priv,
>> -unsigned int frontbuffer_bits);
>> +unsigned int frontbuffer_bits, enum fb_op_origin
>> origin);
>>  const char *intel_no_fbc_reason_str(enum no_fbc_reason reason);
>>  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
>>
>> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
>> b/drivers/gpu/drm/i915/intel_fbc.c
>> index c271af7..1f97fb5 100644
>> --- a/drivers/gpu/drm/i915/intel_fbc.c
>> +++ b/drivers/gpu/drm/i915/intel_fbc.c
>> @@ -884,22 +884,23 @@ void intel_fbc_invalidate(struct drm_i915_private
>> *dev_priv,
>>  }
>>
>>  void intel_fbc_flush(struct drm_i915_private *dev_priv,
>> -unsigned int frontbuffer_bits)
>> +unsigned int frontbuffer_bits, enum fb_op_origin
>> origin)
>>  {
>> if (!dev_priv->fbc.enable_fbc)
>> return;
>>
>> -   mutex_lock(&dev_priv->fbc.lock);
>> +   if (origin == ORIGIN_GTT)
>> +   return;
>>
>> -   if (!dev_priv->fbc.busy_bits)
>> -   goto out;
>> +   mutex_lock(&dev_priv->fbc.lock);
>>
>> dev_priv->fbc.busy_bits &= ~frontbuffer_bits;
>>
>> -   if (!dev_priv->fbc.busy_bits)
>> +   if (!dev_priv->fbc.busy_bits) {
>> +   __intel_fbc_disable(dev_priv);
>> __intel_fbc_update(dev_priv);
>
>
> are we going to kill fbc_update for good? ;)

It is part of the long term plan, but it requires many other changes
first, so I'm focusing on the bugs here.

>
> But yes, we need to force the disable on flush so this is good.
> I'd just add in a separated patch, but anyway feel free to use
>
> Reviewed-by: Rodrigo Vivi 
>
>>
>> +   }
>>
>> -out:
>> mutex_unlock(&dev_priv->fbc.lock);
>>  }
>>
>> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
>> b/drivers/gpu/drm/i915/intel_frontbuffer.c
>> index 777b1d3..ac85357 100644
>> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
>> @@ -129,7 +129,7 @@ static void intel_frontbuffer_flush(struct drm_device
>> *dev,
>>
>> intel_edp_drrs_flush(dev, frontbuffer_bits);
>> intel_psr_flush(dev, frontbuffer_bits, origin);
>> -   intel_fbc_flush(dev_priv, frontbuffer_bits);
>> +   intel_fbc_flush(dev_priv, frontbuffer_bits, origin);
>>  }
>>
>>  /**
>> --
>> 2.1.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Extract a intel_power_well_disable() function

[Paulo Zanoni]

2015-07-31 6:24 GMT-03:00 Jani Nikula :
> On Fri, 31 Jul 2015, Paulo Zanoni  wrote:
>> From: Damien Lespiau 
>>
>> Similar to the ->enable vfunc in commit:
>>
>>   commit 865720564389b2b19cf58e41ed31701e5f464b9d
>
> That sha won't be the same once it gets applied. Maybe just squash these
> two patches into one?

Or just ask the maintainers to remove that specific line containing
the sha while applying the patch since the commit title is already
listed and that won't change :)


>
> BR,
> Jani.
>
>>   Author: Damien Lespiau 
>>   Date:   Wed Jun 3 14:27:05 2015 +0100
>>
>>   drm/i915: Extract a intel_power_well_enable() function
>>
>> v2 (from Paulo):
>>   - Same s/i915_/intel_/ bikeshed as the previous patch.
>>   - Update the commit hash.
>>
>> Signed-off-by: Damien Lespiau 
>> Reviewed-by: Paulo Zanoni 
>> Signed-off-by: Paulo Zanoni 
>> ---
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 15 ++-
>>  1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index a52574d..821644d 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -76,6 +76,14 @@ static void intel_power_well_enable(struct 
>> drm_i915_private *dev_priv,
>>   power_well->hw_enabled = true;
>>  }
>>
>> +static void intel_power_well_disable(struct drm_i915_private *dev_priv,
>> +  struct i915_power_well *power_well)
>> +{
>> + DRM_DEBUG_KMS("disabling %s\n", power_well->name);
>> + power_well->hw_enabled = false;
>> + power_well->ops->disable(dev_priv, power_well);
>> +}
>> +
>>  /*
>>   * We should only use the power well if we explicitly asked the hardware to
>>   * enable it, so check if it's enabled and also check if we've requested it 
>> to
>> @@ -1147,11 +1155,8 @@ void intel_display_power_put(struct drm_i915_private 
>> *dev_priv,
>>   for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
>>   WARN_ON(!power_well->count);
>>
>> - if (!--power_well->count && i915.disable_power_well) {
>> - DRM_DEBUG_KMS("disabling %s\n", power_well->name);
>> - power_well->hw_enabled = false;
>> - power_well->ops->disable(dev_priv, power_well);
>> - }
>> + if (!--power_well->count && i915.disable_power_well)
>> + intel_power_well_disable(dev_priv, power_well);
>>   }
>>
>>   mutex_unlock(&power_domains->lock);
>> --
>> 2.4.6
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add support for stealing purgable stolen pages

[Chris Wilson]

On Fri, Jul 31, 2015 at 08:12:30PM +0530, Goel, Akash wrote:
> 
> 
> On 7/29/2015 5:34 PM, Chris Wilson wrote:
> >On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:
> >>Chris and I just discussed on irc that the bound_list isn't in a great LRU
> >>order right now and Chris sent out a fix for that. But it only works if we
> >>preferrentially shrink inactive objects first. Worth the bother or just a
> >>FIXME? For the fb use-case alone it's not needed since we can't remove the
> >>fb until it's no longer being displayed (otherwise the backwards-compat
> >>code kicks in and synchronously kills the display at RMFB time), and that
> >>pretty much means we can't put the underlying bo into any cache (and mark
> >>it purgeable) either. But a FIXME comment here would be good for sure,
> >>just in case this assumption ever gets broken.
> >
> >I've been mucking around with patch a bit (with contexts-from-stolen
> >reenabled) and the list ierators used here are terrible; severely
> >impacting our allocations by a few orders of magnitude (imagine having
> >just the ggtt full of 4k objects, let alone several ppgtt all full of
> >their own bound 4k objetcs).
> >
> >To combat this will require a special purgeable list maintaind by
> >madv(), and subclassing the struct drm_mm_node to hold our extra
> >details.
> 
> Should we add a separate purgeable list for stolen objects ?
> 
> 
> /** Stolen memory for this object, instead of being backed by shmem. */
> - struct drm_mm_node *stolen;
> + struct i915_gem_stolen *stolen;
> 
> 
> struct i915_gem_stolen {
>   struct drm_mm_node *node;
>   struct list_head purge_list;
> };

Almost. You will need a backpointer from the node to the object so you
can do your list iteration and purge the unwanted object.
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=1094f92e6d94190cf1334fd9bd6459ab70801455
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] interference on display, Intel 945GM, 32bit system, kernel next

[Chris Wilson]

On Fri, Jul 31, 2015 at 04:11:21PM +0200, Krzysztof Kolasa wrote:
> On 22.07.2015 10:27, Daniel Vetter wrote:
> > On Tue, Jul 21, 2015 at 08:07:47PM +0200, Krzysztof Kolasa wrote:
> >> On 21.07.2015 16:03, Daniel Vetter wrote:
> >>> On Tue, Jul 21, 2015 at 02:48:21PM +0200, Krzysztof Kolasa wrote:
>  On 21.07.2015 11:43, Chris Wilson wrote:
> > On Tue, Jul 21, 2015 at 11:07:20AM +0200, Daniel Vetter wrote:
> >> On Tue, Jul 21, 2015 at 10:58:50AM +0200, Krzysztof Kolasa wrote:
> >>> On 21.07.2015 10:41, Daniel Vetter wrote:
>  I meant whether you can reset the bad commit and it's immediate 
>  parent
>  extensively to make sure the bisect is really correct. gpu's 
>  occasionally
>  take a while to hang themselves, so could be that the bisect was
>  mislead somewhere.
> >>> Again I will bisect, more testing good sections.
> >>>
> >>> At the moment on my old laptop, the latest official, properly working 
> >>> kernel is 4.1.2
> >> You don't need to redo the full bisect, only retest the bad and the 
> >> parent
> >> of the bad extensively. That's enough to confirm the bisect result for
> >> sure.
> > The bisection is misleading. It's a missing write-barrier.
> > -Chris
> >
>  tested again:
> 
>  # good: [cd102a687beed1042824d5fa81c6ba8bfe78e6a4] drm/i915: Remove 
>  misleading comment around bind_to_vm
>  git bisect good cd102a687beed1042824d5fa81c6ba8bfe78e6a4
>  # bad: [0875546c5318c85c13d07014af5350e9000bc9e9] drm/i915: Fix up the 
>  vma aliasing ppgtt binding
>  git bisect bad 0875546c5318c85c13d07014af5350e9000bc9e9
>  # first bad commit: [0875546c5318c85c13d07014af5350e9000bc9e9] drm/i915: 
>  Fix up the vma aliasing ppgtt binding
> 
> 
>  Screen does not lie :) first bad is BAD, good is GOOD
> 
>  on commit cd102a687beed10, computer worked steadily (with a large number 
>  of windows, applications) about an hour and stopped the tests, 
>  everything was OK
> 
>  on commit 0875546c5318c85, after about one minute, the screen gone mad
> >>> Suprising. Can you try out the below patch, it should disable the active
> >>> ingredient of the offending. On older kernels just remove the if
> >>> (bind_flags) before the call to ->bind_vma - the point is to call
> >>> ->bind_vma unconditionally.
> >>> -Daniel
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> >>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>> index cc133c700686..1227cd69c624 100644
> >>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >>> @@ -2908,9 +2908,6 @@ int i915_vma_bind(struct i915_vma *vma, enum 
> >>> i915_cache_level cache_level,
> >>>   else
> >>>   bind_flags &= ~vma->bound;
> >>>  
> >>> - if (bind_flags == 0)
> >>> - return 0;
> >>> -
> >>>   if (vma->bound == 0 && vma->vm->allocate_va_range) {
> >>>   trace_i915_va_alloc(vma->vm,
> >>>   vma->node.start,
> >>
> >> I tested the patch and did not help ...
> > Does this one below help?
> > -Daniel
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index d2df321ba634..38dce61e028d 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -150,9 +150,6 @@ static int i915_getparam(struct drm_device *dev, void 
> > *data,
> > case I915_PARAM_HAS_COHERENT_PHYS_GTT:
> > value = 1;
> > break;
> > -   case I915_PARAM_MMAP_VERSION:
> > -   value = 1;
> > -   break;
> > case I915_PARAM_SUBSLICE_TOTAL:
> > value = INTEL_INFO(dev)->subslice_total;
> > if (!value)
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 52b446b27b4d..c71525cefdf9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1676,7 +1676,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void 
> > *data,
> > struct drm_gem_object *obj;
> > unsigned long addr;
> >  
> > -   if (args->flags & ~(I915_MMAP_WC))
> > +   if (args->flags)
> > return -EINVAL;
> >  
> > if (args->flags & I915_MMAP_WC && !cpu_has_pat)
> This commit solved the problem:
> 
> http://cgit.freedesktop.org/drm-intel/commit/?id=d0e30adc42d979e4adc36b6c112b57337423b70c
> 
> drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt

Oh well, still plenty of 4.0 victims to be worried about (which can't be
explained by the bug fixed by d0e30a).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add support for stealing purgable stolen pages

[Goel, Akash]

On 7/29/2015 5:34 PM, Chris Wilson wrote:

On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:

Chris and I just discussed on irc that the bound_list isn't in a great LRU
order right now and Chris sent out a fix for that. But it only works if we
preferrentially shrink inactive objects first. Worth the bother or just a
FIXME? For the fb use-case alone it's not needed since we can't remove the
fb until it's no longer being displayed (otherwise the backwards-compat
code kicks in and synchronously kills the display at RMFB time), and that
pretty much means we can't put the underlying bo into any cache (and mark
it purgeable) either. But a FIXME comment here would be good for sure,
just in case this assumption ever gets broken.


I've been mucking around with patch a bit (with contexts-from-stolen
reenabled) and the list ierators used here are terrible; severely
impacting our allocations by a few orders of magnitude (imagine having
just the ggtt full of 4k objects, let alone several ppgtt all full of
their own bound 4k objetcs).

To combat this will require a special purgeable list maintaind by
madv(), and subclassing the struct drm_mm_node to hold our extra
details.


Should we add a separate purgeable list for stolen objects ?


/** Stolen memory for this object, instead of being backed by shmem. */
- struct drm_mm_node *stolen;
+ struct i915_gem_stolen *stolen;


struct i915_gem_stolen {
struct drm_mm_node *node;
struct list_head purge_list;
};

Best regards
Akash


-Chris


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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add support for stealing purgable stolen pages

[Goel, Akash]

On 7/27/2015 3:08 PM, Daniel Vetter wrote:

On Wed, Jul 22, 2015 at 07:21:48PM +0530, ankitprasad.r.sha...@intel.com wrote:

From: Chris Wilson 

If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - and you will be forgiven for thinking that the code looks
very similar.

At the moment, we do not allow userspace to allocate objects in stolen,
so there is neither the memory pressure to trigger stolen eviction nor
any purgeable objects inside the stolen arena. However, this will change
in the near future, and so better management and defragmentation of
stolen memory will become a real issue.

v2: Remember to remove the drm_mm_node.

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: correctedted if-else braces format (Tvrtko/kerneldoc)

Testcase: igt/gem_stolen

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem_stolen.c | 122 ++---
  1 file changed, 111 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 348ed5a..eaf0bdd 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -430,18 +430,29 @@ cleanup:
return NULL;
  }

-struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
+static bool mark_free(struct drm_i915_gem_object *obj, struct list_head 
*unwind)
+{
+   if (obj->stolen == NULL)
+   return false;
+
+   if (obj->madv != I915_MADV_DONTNEED)
+   return false;
+
+   if (i915_gem_obj_is_pinned(obj))
+   return false;
+
+   list_add(&obj->obj_exec_link, unwind);
+   return drm_mm_scan_add_block(obj->stolen);
+}
+
+static struct drm_mm_node *
+stolen_alloc(struct drm_i915_private *dev_priv, u32 size)
  {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;
+   struct drm_i915_gem_object *obj;
+   struct list_head unwind, evict;
int ret;

-   if (!drm_mm_initialized(&dev_priv->mm.stolen))
-   return NULL;
-
-   DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
if (size == 0)
return NULL;

@@ -451,11 +462,100 @@ i915_gem_object_create_stolen(struct drm_device *dev, 
u32 size)

ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
 4096, DRM_MM_SEARCH_DEFAULT);
-   if (ret) {
-   kfree(stolen);
-   return NULL;
+   if (ret == 0)
+   return stolen;
+
+   /* No more stolen memory available, or too fragmented.
+* Try evicting purgeable objects and search again.
+*/
+
+   drm_mm_init_scan(&dev_priv->mm.stolen, size, 4096, 0);
+   INIT_LIST_HEAD(&unwind);
+
+   list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list)
+   if (mark_free(obj, &unwind))
+   goto found;
+
+   list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list)
+   if (mark_free(obj, &unwind))
+   goto found;


Chris and I just discussed on irc that the bound_list isn't in a great LRU
order right now and Chris sent out a fix for that. But it only works if we
preferrentially shrink inactive objects first. Worth the bother or just a
FIXME?
Sorry for the late response. Do you mean to say here that within the 
bound list, first the inactive stolen objects should be considered for 
purge ?

Is it very likely that an active bo will also be marked as purgeable ?


For the fb use-case alone it's not needed since we can't remove the
fb until it's no longer being displayed (otherwise the backwards-compat
code kicks in and synchronously kills the display at RMFB time), and that
pretty much means we can't put the underlying bo into any cache (and mark
it purgeable) either.
Here do you mean that a frame buffer bo should not be (or cannot be) 
marked as purgeable by User, if it is still being scanned out ?


Best regards
Akash

 But a FIXME comment here would be good for sure,

just in case this assumption ever gets broken.
-Daniel


+
+found:
+   INIT_LIST_HEAD(&evict);
+   while (!list_empty(&unwind)) {
+   obj = list_first_entry(&unwind,
+  struct drm_i915_gem_object,
+  obj_exec_link);
+   list_del_init(&obj->obj_exec_link);
+
+   if (drm_mm_scan_remove_block(obj->stolen)) {
+   list_add(&obj->obj_exec_link, &evict);
+   drm_gem_object_reference(&obj->base);
+   }
}

+   ret = 0;
+ 

Re: [Intel-gfx] interference on display, Intel 945GM, 32bit system, kernel next

[Krzysztof Kolasa]

On 22.07.2015 10:27, Daniel Vetter wrote:
> On Tue, Jul 21, 2015 at 08:07:47PM +0200, Krzysztof Kolasa wrote:
>> On 21.07.2015 16:03, Daniel Vetter wrote:
>>> On Tue, Jul 21, 2015 at 02:48:21PM +0200, Krzysztof Kolasa wrote:
 On 21.07.2015 11:43, Chris Wilson wrote:
> On Tue, Jul 21, 2015 at 11:07:20AM +0200, Daniel Vetter wrote:
>> On Tue, Jul 21, 2015 at 10:58:50AM +0200, Krzysztof Kolasa wrote:
>>> On 21.07.2015 10:41, Daniel Vetter wrote:
 I meant whether you can reset the bad commit and it's immediate parent
 extensively to make sure the bisect is really correct. gpu's 
 occasionally
 take a while to hang themselves, so could be that the bisect was
 mislead somewhere.
>>> Again I will bisect, more testing good sections.
>>>
>>> At the moment on my old laptop, the latest official, properly working 
>>> kernel is 4.1.2
>> You don't need to redo the full bisect, only retest the bad and the 
>> parent
>> of the bad extensively. That's enough to confirm the bisect result for
>> sure.
> The bisection is misleading. It's a missing write-barrier.
> -Chris
>
 tested again:

 # good: [cd102a687beed1042824d5fa81c6ba8bfe78e6a4] drm/i915: Remove 
 misleading comment around bind_to_vm
 git bisect good cd102a687beed1042824d5fa81c6ba8bfe78e6a4
 # bad: [0875546c5318c85c13d07014af5350e9000bc9e9] drm/i915: Fix up the vma 
 aliasing ppgtt binding
 git bisect bad 0875546c5318c85c13d07014af5350e9000bc9e9
 # first bad commit: [0875546c5318c85c13d07014af5350e9000bc9e9] drm/i915: 
 Fix up the vma aliasing ppgtt binding


 Screen does not lie :) first bad is BAD, good is GOOD

 on commit cd102a687beed10, computer worked steadily (with a large number 
 of windows, applications) about an hour and stopped the tests, everything 
 was OK

 on commit 0875546c5318c85, after about one minute, the screen gone mad
>>> Suprising. Can you try out the below patch, it should disable the active
>>> ingredient of the offending. On older kernels just remove the if
>>> (bind_flags) before the call to ->bind_vma - the point is to call
>>> ->bind_vma unconditionally.
>>> -Daniel
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
>>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> index cc133c700686..1227cd69c624 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> @@ -2908,9 +2908,6 @@ int i915_vma_bind(struct i915_vma *vma, enum 
>>> i915_cache_level cache_level,
>>> else
>>> bind_flags &= ~vma->bound;
>>>  
>>> -   if (bind_flags == 0)
>>> -   return 0;
>>> -
>>> if (vma->bound == 0 && vma->vm->allocate_va_range) {
>>> trace_i915_va_alloc(vma->vm,
>>> vma->node.start,
>>
>> I tested the patch and did not help ...
> Does this one below help?
> -Daniel
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index d2df321ba634..38dce61e028d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -150,9 +150,6 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   case I915_PARAM_HAS_COHERENT_PHYS_GTT:
>   value = 1;
>   break;
> - case I915_PARAM_MMAP_VERSION:
> - value = 1;
> - break;
>   case I915_PARAM_SUBSLICE_TOTAL:
>   value = INTEL_INFO(dev)->subslice_total;
>   if (!value)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 52b446b27b4d..c71525cefdf9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1676,7 +1676,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
>   struct drm_gem_object *obj;
>   unsigned long addr;
>  
> - if (args->flags & ~(I915_MMAP_WC))
> + if (args->flags)
>   return -EINVAL;
>  
>   if (args->flags & I915_MMAP_WC && !cpu_has_pat)
This commit solved the problem:

http://cgit.freedesktop.org/drm-intel/commit/?id=d0e30adc42d979e4adc36b6c112b57337423b70c

drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt

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

Re: [Intel-gfx] [PATCH] drm/atomic: Paper over locking WARN in default_state_clear

[Daniel Vetter]

On Fri, Jul 31, 2015 at 10:34:43AM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 29-07-15 om 12:51 schreef Daniel Vetter:
> > In
> >
> > commit 6f75cea66c8dd043ced282016b21a639af176642
> > Author: Daniel Vetter 
> > Date:   Wed Nov 19 18:38:07 2014 +0100
> >
> > drm/atomic: Only destroy connector states with connection mutex held
> >
> > I tried to fix races of atomic commits against connector
> > hot-unplugging. The idea is to ensure lifetimes by holding the
> > connection_mutex long enough. That works for synchronous commits, but
> > not for async ones.
> >
> > For async atomic commit we really need to fix up connector lifetimes
> > for real. But that's a much bigger task, so just add more duct-tape:
> > For cleaning up connector states we currently don't need the connector
> > itself. So NULL it out and remove the locking check. Of course that
> > check was to protect the entire sequence, but the modeset itself
> > should be save since currently DP MST hot-removal does a dpms-off. And
> > that should synchronize with any outstanding async atomic commit.
> >
> > Or at least that's my hope, this is all a giant mess.
> >
> > Reported-by: Maarten Lankhorst 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3efd91c0c6cb..434915448ea0 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -153,9 +153,15 @@ void drm_atomic_state_default_clear(struct 
> > drm_atomic_state *state)
> > if (!connector)
> > continue;
> >  
> > -   WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));
> > -
> > -   connector->funcs->atomic_destroy_state(connector,
> > +   /*
> > +* FIXME: Async commits can race with connector unplugging and
> > +* there's currently nothing that prevents cleanup up state for
> > +* deleted connectors. As long as the callback doesn't look at
> > +* the connector we'll be fine though, so make sure that's the
> > +* case by setting all connector pointers to NULL.
> > +*/
> > +   state->connector_states[i]->connector = NULL;
> > +   connector->funcs->atomic_destroy_state(NULL,
> >
> > state->connector_states[i]);
> >
> This wouldn't provide any additional guarantee during the async commit
> itself, so please don't do this. :-)

Nope, it's really just a big reminder that we have a bug here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Help needed for unusual hack

[harrykipper]

Hello, I have a Thinkpad X230 (IvyBridge, HD4000) with a very clever 
display mod (described to some extent by a guy here --> 
http://boweihe.me/?p=1442). Practically the low res native LVDS panel 
of the laptop was replaced with a FHD IPS eDP panel. The FHD eDP screen 
is attached to the dock DisplayPort connector on the laptop's 
mainboard, which has been rewired in some way, possibly with an 
interface board. The setup works fairly well, the screen is detected as 
DP-3 (the laptop has two other external digital ports) and treated as 
external. I could disable the non existent lvds screen using 
video=lvds1:d to prevent the gpu from duplicating the signal and 
wasting power, but that doesn't give me brightness controls because the 
lvds port is still initialized by the drm module and the 
intel_backlight/ directory is found in 
/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-LVDS-1/.


To try and solve this I went ahead and:
1 - added my laptop's vendor and model number to the 
intel_no_lvds_dmi_callback() function in intel_lvds.c
2 - changed the is_edp() function in intel_dp.c to always return 'true' 
:-D


This way the lvds port skips being initialized, so card0-LVDS-1 doesn't 
exist at all, the DP port is detected as eDP and intel_backlight sits 
correctly in 
/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-DP-1/. The 
screen works perfectly, I have full backlight control and xrandr shows 
all the modes supported by the panel. The backdrop is that the other 
two digital ports are lost, because the kernel disables them when it 
tries to initialize them as eDP, which obviously they are not. In dmesg 
I see


[drm] failed to retrieve link info, disabling eDP

repeated twice, suggesting that the third port is configured correctly, 
as in fact it is.


Now obviously this is a very ugly hack that I came up with as a non 
programmer, unfamiliar with the kernel, and additionally I have an 
error at boot (see below)


My question is (are): could anyone suggest a more clever way of forcing 
the third DP port to be detected as eDP and keeping the other two 
alive? Is the error below something that I should worry about?


Thanks very much and sorry if this is not the right place to ask.

WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1034 
ironlake_crtc_disable+0x93/0x7f0()

[3.220452] pipe_off wait timed out
[3.220453] Modules linked in:
[3.220456] CPU: 0 PID: 6 Comm: kworker/u16:0 Tainted: G U   
  4.1.3-eDP #7
[3.220458] Hardware name: LENOVO 2324B14/2324B14, BIOS G2ETA4WW 
(2.64 ) 04/09/2015

[3.220463] Workqueue: events_unbound async_run_entry_fn
[3.220466]  8174a298 4c6f2a3f 8174a298 
815d398b
[3.220468]  8802149377f0 81071907 8802146e 
880214a92800
[3.220470]   880214a92b38 880214a92b40 
81071998

[3.220471] Call Trace:
[3.220478]  [] ? dump_stack+0x47/0x67
[3.220482]  [] ? warn_slowpath_common+0x77/0xb0
[3.220484]  [] ? warn_slowpath_fmt+0x58/0x80
[3.220488]  [] ? ironlake_crtc_disable+0x93/0x7f0
[3.220492]  [] ? drm_mode_copy+0x19/0x30
[3.220496]  [] ? __kmalloc_track_caller+0x20/0x1d0
[3.220499]  [] ? __intel_set_mode+0xb6c/0xc90
[3.220503]  [] ? 
intel_dump_pipe_config.isra.52+0x33/0x3e0

[3.220508]  [] ? gen6_write32+0x2c/0x90
[3.220510]  [] ? 
intel_crtc_set_config+0xd3a/0x1060
[3.220514]  [] ? 
drm_atomic_state_clear+0x10a/0x180
[3.220517]  [] ? 
drm_mode_set_config_internal+0x5f/0x100

[3.220521]  [] ? restore_fbdev_mode+0xb9/0xe0
[3.220524]  [] ? 
drm_fb_helper_restore_fbdev_mode_unlocked+0x1b/0x60

[3.220526]  [] ? drm_fb_helper_set_par+0x1d/0x40
[3.220530]  [] ? intel_fbdev_set_par+0x11/0x60
[3.220533]  [] ? fbcon_init+0x580/0x610
[3.220536]  [] ? visual_init+0xac/0x110
[3.220539]  [] ? do_bind_con_driver+0x1e4/0x440
[3.220542]  [] ? do_take_over_console+0x110/0x1a0
[3.220545]  [] ? do_fbcon_takeover+0x53/0xc0
[3.220550]  [] ? notifier_call_chain+0x47/0x70
[3.220552]  [] ? 
__blocking_notifier_call_chain+0x3c/0x60

[3.220556]  [] ? register_framebuffer+0x210/0x360
[3.220559]  [] ? 
drm_fb_helper_initial_config+0x282/0x470

[3.220561]  [] ? async_run_entry_fn+0x3e/0x150
[3.220564]  [] ? process_one_work+0x11e/0x3d0
[3.220566]  [] ? worker_thread+0x48/0x4c0
[3.220570]  [] ? preempt_schedule_common+0x1a/0x40
[3.220572]  [] ? process_one_work+0x3d0/0x3d0
[3.220576]  [] ? kthread+0xc8/0xe0
[3.220579]  [] ? kthread_worker_fn+0x180/0x180
[3.220582]  [] ? ret_from_fork+0x42/0x70
[3.220585]  [] ? kthread_worker_fn+0x180/0x180
[3.220587] ---[ end trace 5ff7400acd9836ea ]---
[3.330758] [drm:ironlake_crtc_disable] *ERROR* failed to disable 
transcoder A
[3.47] [drm:intel_set_pch_fifo_underrun_reporting] *ERROR* 
uncleared pch fifo underrun on pch transcoder A
[3.50] [drm:cpt_irq_handler] *

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Support for pread/pwrite from/to non shmem backed objects

[Goel, Akash]

On 7/22/2015 8:09 PM, Chris Wilson wrote:

On Wed, Jul 22, 2015 at 07:21:49PM +0530, ankitprasad.r.sha...@intel.com wrote:

  static int
  i915_gem_shmem_pread(struct drm_device *dev,
 struct drm_i915_gem_object *obj,
@@ -754,17 +850,20 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
goto out;
}

-   /* prime objects have no backing filp to GEM pread/pwrite
-* pages from.
-*/
-   if (!obj->base.filp) {
-   ret = -EINVAL;
-   goto out;
-   }
-
trace_i915_gem_object_pread(obj, args->offset, args->size);

-   ret = i915_gem_shmem_pread(dev, obj, args, file);
+   /* pread for non shmem backed objects */
+   if (!obj->base.filp) {
+   if (obj->tiling_mode == I915_TILING_NONE)


pread/pwrite is defined as a cpu linear, the restriction upon tiling is
a simplification of handling swizzling.


+   ret = i915_gem_gtt_pread_pwrite(dev, obj, args->size,
+   args->offset,
+   args->data_ptr,
+   false);
+   else
+   ret = -EINVAL;
+   } else {
+   ret = i915_gem_shmem_pread(dev, obj, args, file);
+   }

  out:
drm_gem_object_unreference(&obj->base);
@@ -1105,17 +1204,22 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
goto out;
}

-   /* prime objects have no backing filp to GEM pread/pwrite
-* pages from.
-*/
-   if (!obj->base.filp) {
-   ret = -EINVAL;
-   goto out;
-   }
-
trace_i915_gem_object_pwrite(obj, args->offset, args->size);

ret = -EFAULT;
+
+   /* pwrite for non shmem backed objects */
+   if (!obj->base.filp) {
+   if (obj->tiling_mode == I915_TILING_NONE)
+   ret = i915_gem_gtt_pread_pwrite(dev, obj, args->size,
+   args->offset,
+   args->data_ptr,
+   true);
+   else
+   ret = -EINVAL;
+
+   goto out;


The fast pwrite code always works for obj->base.filp == NULL. To easily
make it generic and handle the cases where we cannot fallback to shem,
undo the PIN_NONBLOCK.

Then you just want something like
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d3016f37cd4d..f2284a27dd6d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1114,8 +1114,9 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
  * perspective, requiring manual detiling by the client.
  */
 if (obj->tiling_mode == I915_TILING_NONE &&


Since the suggestion is to reuse the gtt_pwrite_fast function only for 
non-shmem backed objects, can we also relax the Tiling constraint here, 
apart from removing the PIN_NONBLOCK flag. As anyways there is a 
put_fence already being done in gtt_pwrite_fast function.


Also currently the gtt_pwrite_fast function is non-tolerant to faults, 
incurred while accessing the User space buffer, so can that also be 
relaxed (at least for the non-shmem backed objects) ??


Best regards
Akash


-   obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
-   cpu_write_needs_clflush(obj)) {
+   (obj->base.filp == NULL ||
+(obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
+ cpu_write_needs_clflush(obj {
 ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
 /* Note that the gtt paths might fail with non-page-backed user
  * pointers (e.g. gtt mappings when moving data between
@@ -1125,7 +1126,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 if (ret == -EFAULT || ret == -ENOSPC) {
 if (obj->phys_handle)
 ret = i915_gem_phys_pwrite(obj, args, file);
-   else
+   else if (obj->filp)
 ret = i915_gem_shmem_pwrite(dev, obj, args, file);
 }


to enable pwrite access to stolen.
-Chris


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

[Intel-gfx] [PATCH] drm/i915: Postpone plane readout until after encoder readout

[Patrik Jakobsson]

When reading out hw state for planes we disable inactive planes which in
turn triggers an update of the watermarks. The update depends on the
crtc_clock being set which is done when reading out encoders. Thus
postpone the plane readout until after encoder readout.

This prevents a warning in skl_compute_linetime_wm() where pixel_rate
becomes 0 when crtc_clock is 0.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/i915/intel_display.c | 38 +---
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 13a6608..73b2d4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15205,27 +15205,25 @@ static bool primary_get_hw_state(struct intel_crtc 
*crtc)
return !!(I915_READ(DSPCNTR(crtc->plane)) & DISPLAY_PLANE_ENABLE);
 }
 
-static void readout_plane_state(struct intel_crtc *crtc,
-   struct intel_crtc_state *crtc_state)
+static void intel_sanitize_plane(struct intel_plane *plane)
 {
-   struct intel_plane *p;
struct intel_plane_state *plane_state;
-   bool active = crtc_state->base.active;
+   struct intel_crtc *crtc;
 
-   for_each_intel_plane(crtc->base.dev, p) {
-   if (crtc->pipe != p->pipe)
-   continue;
+   plane_state = to_intel_plane_state(plane->base.state);
 
-   plane_state = to_intel_plane_state(p->base.state);
+   if (!plane_state->base.crtc)
+   return;
 
-   if (p->base.type == DRM_PLANE_TYPE_PRIMARY)
-   plane_state->visible = primary_get_hw_state(crtc);
-   else {
-   if (active)
-   p->disable_plane(&p->base, &crtc->base);
+   crtc = to_intel_crtc(plane_state->base.crtc);
 
-   plane_state->visible = false;
-   }
+   if (plane->base.type == DRM_PLANE_TYPE_PRIMARY) {
+   plane_state->visible = primary_get_hw_state(crtc);
+   } else {
+   if (crtc->base.state->active)
+   plane->disable_plane(&plane->base, &crtc->base);
+
+   plane_state->visible = false;
}
 }
 
@@ -15276,7 +15274,6 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
}
 
crtc->base.hwmode = crtc->config->base.adjusted_mode;
-   readout_plane_state(crtc, 
to_intel_crtc_state(crtc->base.state));
 
DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
  crtc->base.base.id,
@@ -15349,6 +15346,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
enum pipe pipe;
struct intel_crtc *crtc;
struct intel_encoder *encoder;
+   struct intel_plane *plane;
int i;
 
intel_modeset_readout_hw_state(dev);
@@ -15360,6 +15358,14 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
 
for_each_pipe(dev_priv, pipe) {
crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+
+   for_each_intel_plane(crtc->base.dev, plane) {
+   if (crtc->pipe != plane->pipe)
+   continue;
+
+   intel_sanitize_plane(plane);
+   }
+
intel_sanitize_crtc(crtc);
intel_dump_pipe_config(crtc, crtc->config,
   "[setup_hw_state]");
-- 
2.1.4

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

[Intel-gfx] [PATCH v8 18/19] drm/i915/gen8: Flip the 48b switch

[Michel Thierry]

Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Update the sanitize_enable_ppgtt for 48 bit PPGTT mode.

Note, aliasing PPGTT remains 32b only.

v2: s/full_64b/full_48b/. (Akash)
v3: Add sanitize_enable_ppgtt changes until here. (Akash)
v4: Update param description (Chris)

Cc: Akash Goel 
Cc: Chris Wilson 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 7 ++-
 drivers/gpu/drm/i915/i915_params.c  | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7a526f9..31d20c6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,9 +104,11 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
 {
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
+   bool has_full_48bit_ppgtt;
 
has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
+   has_full_48bit_ppgtt = IS_BROADWELL(dev) || INTEL_INFO(dev)->gen >= 9;
 
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
@@ -125,6 +127,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
if (enable_ppgtt == 2 && has_full_ppgtt)
return 2;
 
+   if (enable_ppgtt == 3 && has_full_48bit_ppgtt)
+   return 3;
+
 #ifdef CONFIG_INTEL_IOMMU
/* Disable ppgtt on SNB if VT-d is on. */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) {
@@ -141,7 +146,7 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
}
 
if (INTEL_INFO(dev)->gen >= 8 && i915.enable_execlists)
-   return 2;
+   return has_full_48bit_ppgtt ? 3 : 2;
else
return has_aliasing_ppgtt ? 1 : 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 5ae4b0a..900e48a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -111,7 +111,7 @@ MODULE_PARM_DESC(enable_hangcheck,
 module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
 MODULE_PARM_DESC(enable_ppgtt,
"Override PPGTT usage. "
-   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)");
+   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full with 
extended address space)");
 
 module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
 MODULE_PARM_DESC(enable_execlists,
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH v8 18/19] drm/i915/gen8: Flip the 48b switch

[Chris Wilson]

On Fri, Jul 31, 2015 at 01:13:00PM +0100, Michel Thierry wrote:
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 5ae4b0a..900e48a 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -111,7 +111,7 @@ MODULE_PARM_DESC(enable_hangcheck,
>  module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
>  MODULE_PARM_DESC(enable_ppgtt,
>   "Override PPGTT usage. "
> - "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)");
> + "(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full_48b)");

3=full with extended address space
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v8 18/19] drm/i915/gen8: Flip the 48b switch

[Michel Thierry]

Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Update the sanitize_enable_ppgtt for 48 bit PPGTT mode.

Note, aliasing PPGTT remains 32b only.

v2: s/full_64b/full_48b/. (Akash)
v3: Add sanitize_enable_ppgtt changes until here. (Akash)

Cc: Akash Goel 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 7 ++-
 drivers/gpu/drm/i915/i915_params.c  | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7a526f9..31d20c6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,9 +104,11 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
 {
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
+   bool has_full_48bit_ppgtt;
 
has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
+   has_full_48bit_ppgtt = IS_BROADWELL(dev) || INTEL_INFO(dev)->gen >= 9;
 
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
@@ -125,6 +127,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
if (enable_ppgtt == 2 && has_full_ppgtt)
return 2;
 
+   if (enable_ppgtt == 3 && has_full_48bit_ppgtt)
+   return 3;
+
 #ifdef CONFIG_INTEL_IOMMU
/* Disable ppgtt on SNB if VT-d is on. */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) {
@@ -141,7 +146,7 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, 
int enable_ppgtt)
}
 
if (INTEL_INFO(dev)->gen >= 8 && i915.enable_execlists)
-   return 2;
+   return has_full_48bit_ppgtt ? 3 : 2;
else
return has_aliasing_ppgtt ? 1 : 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 5ae4b0a..900e48a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -111,7 +111,7 @@ MODULE_PARM_DESC(enable_hangcheck,
 module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
 MODULE_PARM_DESC(enable_ppgtt,
"Override PPGTT usage. "
-   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)");
+   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full_48b)");
 
 module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
 MODULE_PARM_DESC(enable_execlists,
-- 
2.5.0

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

[Intel-gfx] [PATCH v3 10/11] drm/i915: DVO pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to DVO.

V2:
- removed computation for max pixel clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dvo.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index fd5e522..2bfc51c 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -247,6 +247,7 @@ intel_dvo_mode_valid(struct drm_connector *connector,
 struct drm_display_mode *mode)
 {
struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
 
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
@@ -260,6 +261,9 @@ intel_dvo_mode_valid(struct drm_connector *connector,
return MODE_PANEL;
}
 
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
+
return intel_dvo->dev.dev_ops->mode_valid(&intel_dvo->dev, mode);
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 02/11] drm/i915: DisplayPort pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to DisplayPort.

V2:
- removed computation for max DOT clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..5faeadb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -206,6 +206,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
 
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
@@ -223,7 +224,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
 
-   if (mode_rate > max_rate)
+   if (mode_rate > max_rate || target_clock > max_pixclk)
return MODE_CLOCK_HIGH;
 
if (mode->clock < 1)
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 05/11] drm/i915: SDVO pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to SDVO.

V2:
- removed computation for max pixel clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 2c435a7..55a2853 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1560,6 +1560,7 @@ intel_sdvo_mode_valid(struct drm_connector *connector,
  struct drm_display_mode *mode)
 {
struct intel_sdvo *intel_sdvo = intel_attached_sdvo(connector);
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
 
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
@@ -1570,6 +1571,9 @@ intel_sdvo_mode_valid(struct drm_connector *connector,
if (intel_sdvo->pixel_clock_max < mode->clock)
return MODE_CLOCK_HIGH;
 
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
+
if (intel_sdvo->is_lvds) {
if (mode->hdisplay > intel_sdvo->sdvo_lvds_fixed_mode->hdisplay)
return MODE_PANEL;
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 11/11] drm/i915: Max DOT clock frequency to debugfs

[Mika Kahola]

Information on maximum supported DOT clock frequency to
i915_frequency_info.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..4ba02b5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1314,6 +1314,8 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_puts(m, "no P-state info available\n");
}
 
+   seq_printf(m, "Max pixel clock frequency: %dkHz\n", 
dev_priv->max_dotclk);
+
 out:
intel_runtime_pm_put(dev_priv);
return ret;
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 04/11] drm/i915: LVDS pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to LVDS.

V2:
- removed computation for max pixel clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_lvds.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index cb634f4..59213f9 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -289,11 +289,14 @@ intel_lvds_mode_valid(struct drm_connector *connector,
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
 
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
if (mode->vdisplay > fixed_mode->vdisplay)
return MODE_PANEL;
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
 
return MODE_OK;
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v8 06/19] drm/i915/gen8: Add PML4 structure

[Michel Thierry]

Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.

To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.

v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
v5: Postpone 48-bit code in sanitize_enable_ppgtt (Akash).

Cc: Akash Goel 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c | 30 +-
 drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
 3 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..4729eaf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2498,7 +2498,8 @@ struct drm_i915_cmd_table {
 #define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 6)
 #define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 8)
 #define USES_PPGTT(dev)(i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt >= 2)
+#define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
 
 #define HAS_OVERLAY(dev)   (INTEL_INFO(dev)->has_overlay)
 #define OVERLAY_NEEDS_PHYSICAL(dev)
(INTEL_INFO(dev)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f71746..ba99b67 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -689,9 +689,6 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
pt_vaddr = NULL;
 
for_each_sg_page(pages->sgl, &sg_iter, pages->nents, 0) {
-   if (WARN_ON(pdpe >= GEN8_LEGACY_PDPES))
-   break;
-
if (pt_vaddr == NULL) {
struct i915_page_directory *pd = 
pdp->page_directory[pdpe];
struct i915_page_table *pt = pd->page_table[pde];
@@ -1105,14 +1102,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
 
ppgtt->base.start = 0;
-   ppgtt->base.total = 1ULL << 32;
-   if (IS_ENABLED(CONFIG_X86_32))
-   /* While we have a proliferation of size_t variables
-* we cannot represent the full ppgtt size on 32bit,
-* so limit it to the same size as the GGTT (currently
-* 2GiB).
-*/
-   ppgtt->base.total = to_i915(ppgtt->base.dev)->gtt.base.total;
ppgtt->base.cleanup = gen8_ppgtt_cleanup;
ppgtt->base.allocate_va_range = gen8_alloc_va_range;
ppgtt->base.insert_entries = gen8_ppgtt_insert_entries;
@@ -1122,10 +,25 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
 
ppgtt->switch_mm = gen8_mm_switch;
 
-   ret = __pdp_init(false, &ppgtt->pdp);
+   if (!USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
+   ret = __pdp_init(false, &ppgtt->pdp);
 
-   if (ret)
+   if (ret)
+   goto free_scratch;
+
+   ppgtt->base.total = 1ULL << 32;
+   if (IS_ENABLED(CONFIG_X86_32))
+   /* While we have a proliferation of size_t variables
+* we cannot represent the full ppgtt size on 32bit,
+* so limit it to the same size as the GGTT (currently
+* 2GiB).
+*/
+   ppgtt->base.total = 
to_i915(ppgtt->base.dev)->gtt.base.total;
+   } else {
+   ppgtt->base.total = 1ULL << 48;
+   ret = -EPERM; /* Not yet implemented */
goto free_scratch;
+   }
 
return 0;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 87e389c..04bc66f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -88,9 +88,17 @@ typedef uint64_t gen8_pde_t;
  * PDPE  |  PDE  |  PTE  | offset
  * The difference as compared to normal x86 3 level page table is the PDPEs are
  * programmed via register.
+ *
+ * GEN8 48b legacy style address is defined as a 4 level page table:
+ * 47:39 | 38:30 | 29:21 | 20:12 |  11:0
+ * PML4E | PDPE  |  PDE  |  PTE  | offset
  */
+#define GEN8_PML4ES_PER_PML4   512
+#define GEN8_PML4E_SHIFT   39
 #define GEN8_PDPE_SHIFT30
-#define GEN8_PDPE_MASK 0x3
+/* NB: GEN8_PDPE_MASK is untrue for 32b platforms, but it has no impact on 32b 
page
+ * tables */
+#define GEN8_PDPE_MASK 0x1ff
 #define GEN8_PDE_SHIFT 21
 #define GEN8_PDE_MASK  0x1ff
 #define GEN8_PTE_SHIFT 12
@@ -98,8 +106,8 @@ typedef uint6

[Intel-gfx] [PATCH v3 07/11] drm/i915: CRT pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to CRT.

V2:
- removed computation for max pixel clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_crt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 5d78c1f..40ded5f 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -290,6 +290,7 @@ intel_crt_mode_valid(struct drm_connector *connector,
 struct drm_display_mode *mode)
 {
struct drm_device *dev = connector->dev;
+   int max_pixclk = to_i915(dev)->max_dotclk;
 
int max_clock = 0;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
@@ -305,6 +306,9 @@ intel_crt_mode_valid(struct drm_connector *connector,
if (mode->clock > max_clock)
return MODE_CLOCK_HIGH;
 
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
+
/* The FDI receiver on LPT only supports 8bpc and only has 2 lanes. */
if (HAS_PCH_LPT(dev) &&
(ironlake_get_lanes_required(mode->clock, 27, 24) > 2))
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 06/11] drm/i915: DSI pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to DSI.

V2:
- removed computation for max pixel clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dsi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 18dd7d7..3def6f9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -654,6 +654,7 @@ intel_dsi_mode_valid(struct drm_connector *connector,
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
 
DRM_DEBUG_KMS("\n");
 
@@ -669,6 +670,9 @@ intel_dsi_mode_valid(struct drm_connector *connector,
return MODE_PANEL;
}
 
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
+
return MODE_OK;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 09/11] drm/i915: DisplayPort-MST pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to DisplayPort MST.

V2:
- removed computation for max pixel clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 585f0a4..fcf03d0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -347,6 +347,8 @@ static enum drm_mode_status
 intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
 {
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
+
/* TODO - validate mode against available PBN for link */
if (mode->clock < 1)
return MODE_CLOCK_LOW;
@@ -354,6 +356,9 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
 
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
+
return MODE_OK;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 01/11] drm/i915: Store max dotclock

[Mika Kahola]

Store max dotclock into dev_priv structure so we are able
to filter out the modes that are not supported by our
platforms.

V2:
- limit the max dot clock frequency to max CD clock frequency
  for the gen9 and above
- limit the max dot clock frequency to 90% of the max CD clock
  frequency for the older gens
- for Cherryview the max dot clock frequency is limited to 95%
  of the max CD clock frequency
- for gen2 and gen3 the max dot clock limit is set to 90% of the
  2X max CD clock frequency

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 19 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..1f69211b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1777,6 +1777,7 @@ struct drm_i915_private {
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_boot_cdclk;
unsigned int cdclk_freq, max_cdclk_freq;
+   unsigned int max_dotclk;
unsigned int hpll_freq;
 
/**
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 43b0f17..c9c6d19 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5259,6 +5259,23 @@ static void modeset_update_crtc_power_domains(struct 
drm_atomic_state *state)
modeset_put_power_domains(dev_priv, put_domains[i]);
 }
 
+static int intel_compute_max_dotclk(struct drm_i915_private *dev_priv)
+{
+   int max_cdclk_freq = dev_priv->max_cdclk_freq;
+   int max_dotclk_freq;
+
+   if (INTEL_INFO(dev_priv)->gen >= 9)
+   max_dotclk_freq = max_cdclk_freq;
+   else if (IS_CHERRYVIEW(dev_priv))
+   max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 95, 100);
+   else if (INTEL_INFO(dev_priv)->gen == 2 || INTEL_INFO(dev_priv)->gen == 
3)
+   max_dotclk_freq = DIV_ROUND_UP(2 * max_cdclk_freq * 90, 100);
+   else
+   max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 90, 100);
+
+   return max_dotclk_freq;
+}
+
 static void intel_update_max_cdclk(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -5298,6 +5315,8 @@ static void intel_update_max_cdclk(struct drm_device *dev)
dev_priv->max_cdclk_freq = dev_priv->cdclk_freq;
}
 
+   dev_priv->max_dotclk = intel_compute_max_dotclk(dev_priv);
+
DRM_DEBUG_DRIVER("Max CD clock rate: %d kHz\n",
 dev_priv->max_cdclk_freq);
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 08/11] drm/i915: TV pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to TV.

V2:
- removed computation for max pixel clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_tv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 8b9d325..beeed25 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -897,6 +897,10 @@ intel_tv_mode_valid(struct drm_connector *connector,
 {
struct intel_tv *intel_tv = intel_attached_tv(connector);
const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
+
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
 
/* Ensure TV refresh is close to desired refresh */
if (tv_mode && abs(tv_mode->refresh - drm_mode_vrefresh(mode) * 1000)
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 00/11] Check pixel clock when setting mode

[Mika Kahola]

From EDID we can read and request higher pixel clock than
our HW can support. This set of patches add checks if
requested pixel clock is lower than the one supported by the HW.
The requested mode is discarded if we cannot support the requested
pixel clock. For example for Cherryview

'cvt 2560 1600 60' gives

# 2560x1600 59.99 Hz (CVT 4.10MA) hsync: 99.46 kHz; pclk: 348.50 MHz
Modeline "2560x1600_60.00"  348.50  2560 2760 3032 3504  1600 1603 1609 1658 
-hsync +vsync

where pixel clock 348.50 MHz is higher than the supported 304 MHz.

The checks are implemented for DisplayPort, HDMI, LVDS, DVO, SDVO, DSI,
CRT, TV, and DP-MST.

V2:
- The maximum DOT clock frequency is added to debugfs i915_frequency_info.
- max dotclock cached in dev_priv structure
- moved computation of max dotclock to 'intel_display.c'

V3:
- intel_update_max_dotclk() renamed as intel_compute_max_dotclk()
- for GEN9 and above the max dotclock frequency is equal to CD clock
  frequency
- for older generations the dot clock frequency is limited to 90% of the
  CD clock frequency
- For Cherryview the dot clock is limited to 95% of CD clock frequency
- for GEN2/3 the maximum dot clock frequency is limited to 90% of the
  2X CD clock frequency as we have on option to use double wide mode
- cleanup

Mika Kahola (11):
  drm/i915: Store max dotclock
  drm/i915: DisplayPort pixel clock check
  drm/i915: HDMI pixel clock check
  drm/i915: LVDS pixel clock check
  drm/i915: SDVO pixel clock check
  drm/i915: DSI pixel clock check
  drm/i915: CRT pixel clock check
  drm/i915: TV pixel clock check
  drm/i915: DisplayPort-MST pixel clock check
  drm/i915: DVO pixel clock check
  drm/i915: Max DOT clock frequency to debugfs

 drivers/gpu/drm/i915/i915_debugfs.c  |  2 ++
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_crt.c |  4 
 drivers/gpu/drm/i915/intel_display.c | 19 +++
 drivers/gpu/drm/i915/intel_dp.c  |  3 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c  |  5 +
 drivers/gpu/drm/i915/intel_dsi.c |  4 
 drivers/gpu/drm/i915/intel_dvo.c |  4 
 drivers/gpu/drm/i915/intel_hdmi.c|  4 
 drivers/gpu/drm/i915/intel_lvds.c|  3 +++
 drivers/gpu/drm/i915/intel_sdvo.c|  4 
 drivers/gpu/drm/i915/intel_tv.c  |  4 
 12 files changed, 56 insertions(+), 1 deletion(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v3 03/11] drm/i915: HDMI pixel clock check

[Mika Kahola]

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to HDMI.

V2:
- removed computation for max dot clock

V3:
- cleanup by removing unnecessary lines

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..3149e5f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1193,10 +1193,14 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
enum drm_mode_status status;
int clock;
+   int max_pixclk = to_i915(connector->dev)->max_dotclk;
 
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
 
+   if (mode->clock > max_pixclk)
+   return MODE_CLOCK_HIGH;
+
clock = mode->clock;
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
clock *= 2;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 0/4] Fix SKL runtime PM

[Patrik Jakobsson]

On Thu, Jul 30, 2015 at 06:20:25PM -0300, Paulo Zanoni wrote:
> Hello
> 
> So I discovered that SKL runtime PM doesn't work on drm-intel-nightly and
> decided to investigate why. I found this patch in one of Damien's trees and it
> fixed the problem I was seeing. I really don't know why the patches were not
> sent to the list yet and I can't ask him since he's on vacation. So I decided 
> to
> review them, implement my own bikesheds, add R-B tags and submit to the list,
> since it's an important feature that's broken and preliminary_hw_support was
> removed for SKL.
> 
> I hope the reason he didn't submit this is not because there's some bug I 
> failed
> to spot. Anyway, he'll tell us in a few days :).
> 
> Also notice that we're not passing every pm_rpm subtest now: we're just not
> failing 100% of the tests.

Good find! I also started looking into this and came up with something similar.
The series looks fine to me but I agree with Jani that you can squash
enable/disable into one commit. Now lets hope the bugs uncovered by this series
are trivial to fix.

For the entire patchset:

Reviewed-by: Patrik Jakobsson 

> 
> Thanks,
> Paulo
> 
> Damien Lespiau (3):
>   drm/i915: Extract a intel_power_well_enable() function
>   drm/i915: Extract a intel_power_well_disable() function
>   drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini
> sequences
> 
> Paulo Zanoni (1):
>   drm/i915/skl: send opregion_nofify_adapter(PCI_D1) instead of PCI_D3
> 
>  drivers/gpu/drm/i915/i915_drv.c | 20 +--
>  drivers/gpu/drm/i915/intel_ddi.c|  2 --
>  drivers/gpu/drm/i915/intel_display.c|  5 +--
>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 59 
> +++--
>  5 files changed, 63 insertions(+), 25 deletions(-)
> 
> -- 
> 2.4.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Tone done *ERROR* for an expected VBT condition

[Chris Wilson]

Older VBT (e.g. gen2) have smaller child block defintions, so do not cry
wolf over an error that is outside of our control and is not an error
anyway.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb00fdec..f8afbafa8e02 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1023,7 +1023,7 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
return;
}
if (p_defs->child_dev_size < sizeof(*p_child)) {
-   DRM_ERROR("General definiton block child device size is too 
small.\n");
+   DRM_DEBUG_KMS("General definiton block child device size is too 
small.\n");
return;
}
/* get the block size of general definitions */
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH v2 10/12] drm/i915: Remove connectors_active.

[Ander Conselvan De Oliveira]

Reviewed-by: Ander Conselvan de Oliveira 

On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> There are no more users, byebye!
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 37 
> +---
>  drivers/gpu/drm/i915/intel_drv.h |  1 -
>  2 files changed, 1 insertion(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 341fadb40c81..23175ce6583d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12196,27 +12196,12 @@ static bool intel_crtc_in_use(struct drm_crtc *crtc)
>  static void
>  intel_modeset_update_state(struct drm_atomic_state *state)
>  {
> - struct drm_device *dev = state->dev;
> - struct intel_encoder *intel_encoder;
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
> - struct drm_connector *connector;
>   int i;
>  
>   intel_shared_dpll_commit(state);
>  
> - for_each_intel_encoder(dev, intel_encoder) {
> - if (!intel_encoder->base.crtc)
> - continue;
> -
> - crtc = intel_encoder->base.crtc;
> - crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
> - if (!crtc_state || !needs_modeset(crtc->state))
> - continue;
> -
> - intel_encoder->connectors_active = false;
> - }
> -
>   drm_atomic_helper_update_legacy_modeset_state(state->dev, state);
>  
>   /* Double check state. */
> @@ -12231,21 +12216,6 @@ intel_modeset_update_state(struct drm_atomic_state 
> *state)
>   else
>   crtc->hwmode.crtc_clock = 0;
>   }
> -
> - list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> - if (!connector->encoder || !connector->encoder->crtc)
> - continue;
> -
> - crtc = connector->encoder->crtc;
> - crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
> - if (!crtc_state || !needs_modeset(crtc->state))
> - continue;
> -
> - if (crtc->state->active) {
> - intel_encoder = to_intel_encoder(connector->encoder);
> - intel_encoder->connectors_active = true;
> - }
> - }
>  }
>  
>  static bool intel_fuzzy_clock_check(int clock1, int clock2)
> @@ -14965,10 +14935,8 @@ static void intel_sanitize_crtc(struct intel_crtc 
> *crtc)
>*  actually up, hence no need to break them. */
>   WARN_ON(crtc->active);
>  
> - for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
> - WARN_ON(encoder->connectors_active);
> + for_each_encoder_on_crtc(dev, &crtc->base, encoder)
>   encoder->base.crtc = NULL;
> - }
>   }
>  
>   if (crtc->active || HAS_GMCH_DISPLAY(dev)) {
> @@ -15027,7 +14995,6 @@ static void intel_sanitize_encoder(struct 
> intel_encoder *encoder)
>   encoder->post_disable(encoder);
>   }
>   encoder->base.crtc = NULL;
> - encoder->connectors_active = false;
>  
>   /* Inconsistent output/port/pipe state happens presumably due to
>* a bug in one of the get_hw_state functions. Or someplace else
> @@ -15189,7 +15156,6 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   encoder->base.crtc = NULL;
>   }
>  
> - encoder->connectors_active = false;
>   DRM_DEBUG_KMS("[ENCODER:%d:%s] hw state readout: %s, pipe %c\n",
> encoder->base.base.id,
> encoder->base.name,
> @@ -15200,7 +15166,6 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   for_each_intel_connector(dev, connector) {
>   if (connector->get_hw_state(connector)) {
>   connector->base.dpms = DRM_MODE_DPMS_ON;
> - connector->encoder->connectors_active = true;
>   connector->base.encoder = &connector->encoder->base;
>   } else {
>   connector->base.dpms = DRM_MODE_DPMS_OFF;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 62073d2f83fa..c30bbb22381b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -133,7 +133,6 @@ struct intel_encoder {
>  
>   enum intel_output_type type;
>   unsigned int cloneable;
> - bool connectors_active;
>   void (*hot_plug)(struct intel_encoder *);
>   bool (*compute_config)(struct intel_encoder *,
>  struct intel_crtc_state *);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/ma

Re: [Intel-gfx] [PATCH v2 07/12] drm/i915: Get rid of dpms handling.

[Ander Conselvan De Oliveira]

Reviewed-by: Ander Conselvan de Oliveira 

On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> This is now done completely atomically.
> Keep connectors_active for now, but make it mirror crtc_state->active.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_crt.c | 49 +-
>  drivers/gpu/drm/i915/intel_display.c | 99 
> +---
>  drivers/gpu/drm/i915/intel_dp.c  |  2 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c  |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h |  3 --
>  drivers/gpu/drm/i915/intel_dsi.c |  2 +-
>  drivers/gpu/drm/i915/intel_dvo.c | 46 +
>  drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
>  drivers/gpu/drm/i915/intel_lvds.c|  2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c| 47 +
>  drivers/gpu/drm/i915/intel_tv.c  |  2 +-
>  11 files changed, 11 insertions(+), 245 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 9eba3dd5b434..af5e43bef4a4 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -236,53 +236,6 @@ static void intel_enable_crt(struct intel_encoder 
> *encoder)
>   intel_crt_set_dpms(encoder, crt->connector->base.dpms);
>  }
>  
> -/* Special dpms function to support cloning between dvo/sdvo/crt. */
> -static int intel_crt_dpms(struct drm_connector *connector, int mode)
> -{
> - struct drm_device *dev = connector->dev;
> - struct intel_encoder *encoder = intel_attached_encoder(connector);
> - struct drm_crtc *crtc;
> - int old_dpms;
> -
> - /* PCH platforms and VLV only support on/off. */
> - if (INTEL_INFO(dev)->gen >= 5 && mode != DRM_MODE_DPMS_ON)
> - mode = DRM_MODE_DPMS_OFF;
> -
> - if (mode == connector->dpms)
> - return 0;
> -
> - old_dpms = connector->dpms;
> - connector->dpms = mode;
> -
> - /* Only need to change hw state when actually enabled */
> - crtc = encoder->base.crtc;
> - if (!crtc) {
> - encoder->connectors_active = false;
> - return 0;
> - }
> -
> - /* We need the pipe to run for anything but OFF. */
> - if (mode == DRM_MODE_DPMS_OFF)
> - encoder->connectors_active = false;
> - else
> - encoder->connectors_active = true;
> -
> - /* We call connector dpms manually below in case pipe dpms doesn't
> -  * change due to cloning. */
> - if (mode < old_dpms) {
> - /* From off to on, enable the pipe first. */
> - intel_crtc_update_dpms(crtc);
> -
> - intel_crt_set_dpms(encoder, mode);
> - } else {
> - intel_crt_set_dpms(encoder, mode);
> -
> - intel_crtc_update_dpms(crtc);
> - }
> -
> - return 0;
> -}
> -
>  static enum drm_mode_status
>  intel_crt_mode_valid(struct drm_connector *connector,
>struct drm_display_mode *mode)
> @@ -798,7 +751,7 @@ static void intel_crt_reset(struct drm_connector 
> *connector)
>  
>  static const struct drm_connector_funcs intel_crt_connector_funcs = {
>   .reset = intel_crt_reset,
> - .dpms = intel_crt_dpms,
> + .dpms = drm_atomic_helper_connector_dpms,
>   .detect = intel_crt_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .destroy = intel_crt_destroy,
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e3afe611a78c..ed9eba2666e2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6271,67 +6271,6 @@ free:
>   return ret;
>  }
>  
> -/* Master function to enable/disable CRTC and corresponding power wells */
> -int intel_crtc_control(struct drm_crtc *crtc, bool enable)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_mode_config *config = &dev->mode_config;
> - struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct intel_crtc_state *pipe_config;
> - struct drm_atomic_state *state;
> - int ret;
> -
> - if (enable == intel_crtc->active)
> - return 0;
> -
> - if (enable && !crtc->state->enable)
> - return 0;
> -
> - /* this function should be called with drm_modeset_lock_all for now */
> - if (WARN_ON(!ctx))
> - return -EIO;
> - lockdep_assert_held(&ctx->ww_ctx);
> -
> - state = drm_atomic_state_alloc(dev);
> - if (WARN_ON(!state))
> - return -ENOMEM;
> -
> - state->acquire_ctx = ctx;
> - state->allow_modeset = true;
> -
> - pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
> - if (IS_ERR(pipe_config)) {
> - ret = PTR_ERR(pipe_config);
> - goto err;
> - }
> - pipe_config->base.active = enable;
> -
> - ret = drm_atomic_commit(state);
> - if (!ret)
> - return ret;
> -
>

Re: [Intel-gfx] [PATCH v2.1 03/12] drm/i915: Convert connector checking to atomic, v2.

[Ander Conselvan De Oliveira]

On Thu, 2015-07-30 at 14:57 +0200, Maarten Lankhorst wrote:
> Right now dpms callbacks can still fiddle with the connector state,
> but it can only turn connectors off.
> 
> This is remediated by only checking crtc->state->active when the
> connector is active, and ignore crtc->state->active when the
> connector is off.
> 
> connectors_active is no longer checked, and will be removed later
> in this series together with dpms.
> 
> Another check for !encoder->crtc is performed by check_encoder_state
> too, so it can be removed.
> 
> Changes since v1:
> - Add commit message.
> - rename state to old_state.
> - Move deletion of mst_port check to mst patch.

I didn't see the respin of that patch, so this one didn't apply cleanly for me. 
I had to edit the
mst patch first.

Reviewed-by: Ander Conselvan de Oliveira 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 66 
> +---
>  1 file changed, 32 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 77b4da7e698c..876071ad4681 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6360,38 +6360,33 @@ static void intel_encoder_dpms(struct intel_encoder 
> *encoder, int mode)
>   * internal consistency). */
>  static void intel_connector_check_state(struct intel_connector *connector)
>  {
> - if (connector->get_hw_state(connector)) {
> - struct intel_encoder *encoder = connector->encoder;
> - struct drm_crtc *crtc;
> - bool encoder_enabled;
> - enum pipe pipe;
> + struct drm_crtc *crtc = connector->base.state->crtc;
>  
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> -   connector->base.base.id,
> -   connector->base.name);
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> +   connector->base.base.id,
> +   connector->base.name);
>  
> - I915_STATE_WARN(connector->base.dpms == DRM_MODE_DPMS_OFF,
> -  "wrong connector dpms state\n");
> - I915_STATE_WARN(connector->base.encoder != &encoder->base,
> -  "active connector not linked to encoder\n");
> + if (connector->get_hw_state(connector)) {
> + struct drm_encoder *encoder = &connector->encoder->base;
> + struct drm_connector_state *conn_state = connector->base.state;
>  
> - if (encoder) {
> - I915_STATE_WARN(!encoder->connectors_active,
> -  "encoder->connectors_active not set\n");
> + I915_STATE_WARN(!crtc,
> +  "connector enabled without attached crtc\n");
>  
> - encoder_enabled = encoder->get_hw_state(encoder, &pipe);
> - I915_STATE_WARN(!encoder_enabled, "encoder not 
> enabled\n");
> - if (I915_STATE_WARN_ON(!encoder->base.crtc))
> - return;
> + if (!crtc)
> + return;
>  
> - crtc = encoder->base.crtc;
> + I915_STATE_WARN(!crtc->state->active,
> +   "connector is active, but attached crtc isn't\n");
>  
> - I915_STATE_WARN(!crtc->state->enable,
> - "crtc not enabled\n");
> - I915_STATE_WARN(!to_intel_crtc(crtc)->active, "crtc not 
> active\n");
> - I915_STATE_WARN(pipe != to_intel_crtc(crtc)->pipe,
> -  "encoder active on the wrong pipe\n");
> - }
> + I915_STATE_WARN(conn_state->best_encoder != encoder,
> + "atomic encoder doesn't match attached encoder\n");
> +
> + I915_STATE_WARN(conn_state->crtc != encoder->crtc,
> + "attached encoder crtc differs from connector crtc\n");
> + } else {
> + I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
> + "best encoder set without crtc!\n");
>   }
>  }
>  
> @@ -12699,20 +12694,23 @@ static void check_wm_state(struct drm_device *dev)
>  }
>  
>  static void
> -check_connector_state(struct drm_device *dev)
> +check_connector_state(struct drm_device *dev,
> +   struct drm_atomic_state *old_state)
>  {
> - struct intel_connector *connector;
> + struct drm_connector_state *old_conn_state;
> + struct drm_connector *connector;
> + int i;
>  
> - for_each_intel_connector(dev, connector) {
> - struct drm_encoder *encoder = connector->base.encoder;
> - struct drm_connector_state *state = connector->base.state;
> + for_each_connector_in_state(old_state, connector, old_conn_state, i) {
> + struct drm_encoder *encoder = connector->encoder;
> + struct drm_connector_state *state = connect

Re: [Intel-gfx] [PATCH v2.1 2.5/12] drm/i915: Validate the state after an atomic modeset, only, and pass the state.

[Ander Conselvan De Oliveira]

Reviewed-by: Ander Conselvan de Oliveira 

On Thu, 2015-07-30 at 14:57 +0200, Maarten Lankhorst wrote:
> First step in removing dpms and validating atomic state.
> 
> There can still be a mismatch in the connector state because the dpms
> callbacks are still used, but this can not happen immediately after a modeset.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_crt.c |  2 --
>  drivers/gpu/drm/i915/intel_display.c | 12 ++--
>  drivers/gpu/drm/i915/intel_drv.h |  1 -
>  drivers/gpu/drm/i915/intel_dvo.c |  2 --
>  drivers/gpu/drm/i915/intel_sdvo.c|  2 --
>  5 files changed, 6 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 5d78c1feec81..9eba3dd5b434 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -280,8 +280,6 @@ static int intel_crt_dpms(struct drm_connector 
> *connector, int mode)
>   intel_crtc_update_dpms(crtc);
>   }
>  
> - intel_modeset_check_state(connector->dev);
> -
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index dfe4407b0390..77b4da7e698c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6440,8 +6440,6 @@ int intel_connector_dpms(struct drm_connector 
> *connector, int mode)
>   if (connector->encoder)
>   intel_encoder_dpms(to_intel_encoder(connector->encoder), mode);
>  
> - intel_modeset_check_state(connector->dev);
> -
>   return 0;
>  }
>  
> @@ -12900,8 +12898,9 @@ check_shared_dpll_state(struct drm_device *dev)
>   }
>  }
>  
> -void
> -intel_modeset_check_state(struct drm_device *dev)
> +static void
> +intel_modeset_check_state(struct drm_device *dev,
> +   struct drm_atomic_state *old_state)
>  {
>   check_wm_state(dev);
>   check_connector_state(dev);
> @@ -13290,10 +13289,11 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>  
>   drm_atomic_helper_wait_for_vblanks(dev, state);
>   drm_atomic_helper_cleanup_planes(dev, state);
> - drm_atomic_state_free(state);
>  
>   if (any_ms)
> - intel_modeset_check_state(dev);
> + intel_modeset_check_state(dev, state);
> +
> + drm_atomic_state_free(state);
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 320c9e6bd848..0da4236dc85a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -999,7 +999,6 @@ int intel_connector_init(struct intel_connector *);
>  struct intel_connector *intel_connector_alloc(void);
>  int intel_connector_dpms(struct drm_connector *, int mode);
>  bool intel_connector_get_hw_state(struct intel_connector *connector);
> -void intel_modeset_check_state(struct drm_device *dev);
>  bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
>   struct intel_digital_port *port);
>  void intel_connector_attach_encoder(struct intel_connector *connector,
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index fd5e522abebb..600f7fb855d8 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -237,8 +237,6 @@ static int intel_dvo_dpms(struct drm_connector 
> *connector, int mode)
>   intel_crtc_update_dpms(crtc);
>   }
>  
> - intel_modeset_check_state(connector->dev);
> -
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 2c435a79d4da..8911e0e417ee 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1550,8 +1550,6 @@ static int intel_sdvo_dpms(struct drm_connector 
> *connector, int mode)
>   intel_sdvo_set_active_outputs(intel_sdvo, 
> intel_sdvo->attached_output);
>   }
>  
> - intel_modeset_check_state(connector->dev);
> -
>   return 0;
>  }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Extract a intel_power_well_disable() function

[Jani Nikula]

On Fri, 31 Jul 2015, Paulo Zanoni  wrote:
> From: Damien Lespiau 
>
> Similar to the ->enable vfunc in commit:
>
>   commit 865720564389b2b19cf58e41ed31701e5f464b9d

That sha won't be the same once it gets applied. Maybe just squash these
two patches into one?

BR,
Jani.

>   Author: Damien Lespiau 
>   Date:   Wed Jun 3 14:27:05 2015 +0100
>
>   drm/i915: Extract a intel_power_well_enable() function
>
> v2 (from Paulo):
>   - Same s/i915_/intel_/ bikeshed as the previous patch.
>   - Update the commit hash.
>
> Signed-off-by: Damien Lespiau 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index a52574d..821644d 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -76,6 +76,14 @@ static void intel_power_well_enable(struct 
> drm_i915_private *dev_priv,
>   power_well->hw_enabled = true;
>  }
>  
> +static void intel_power_well_disable(struct drm_i915_private *dev_priv,
> +  struct i915_power_well *power_well)
> +{
> + DRM_DEBUG_KMS("disabling %s\n", power_well->name);
> + power_well->hw_enabled = false;
> + power_well->ops->disable(dev_priv, power_well);
> +}
> +
>  /*
>   * We should only use the power well if we explicitly asked the hardware to
>   * enable it, so check if it's enabled and also check if we've requested it 
> to
> @@ -1147,11 +1155,8 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>   for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
>   WARN_ON(!power_well->count);
>  
> - if (!--power_well->count && i915.disable_power_well) {
> - DRM_DEBUG_KMS("disabling %s\n", power_well->name);
> - power_well->hw_enabled = false;
> - power_well->ops->disable(dev_priv, power_well);
> - }
> + if (!--power_well->count && i915.disable_power_well)
> + intel_power_well_disable(dev_priv, power_well);
>   }
>  
>   mutex_unlock(&power_domains->lock);
> -- 
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3 1/5] drm: Add config for detecting libdrm

[Patrik Jakobsson]

On Thu, Jul 30, 2015 at 10:04:49AM -0400, Mike Frysinger wrote:
> On 30 Jul 2015 15:30, Patrik Jakobsson wrote:
> > On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote:
> > > On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
> > > > Use pkg-config to try to find libdrm. If that fails use the standard
> > > > include directory for kernel drm headers in /usr/include/drm.
> > > > 
> > > > * configure.ac: Use pkg-config to find libdrm
> > > > 
> > > > Signed-off-by: Patrik Jakobsson 
> > > > ---
> > > >  configure.ac | 4 
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/configure.ac b/configure.ac
> > > > index bb8bf46..aa63af7 100644
> > > > --- a/configure.ac
> > > > +++ b/configure.ac
> > > > @@ -844,6 +844,10 @@ fi
> > > >  AM_CONDITIONAL([USE_LIBUNWIND], [test "x$use_libunwind" = xyes])
> > > >  AC_MSG_RESULT([$use_libunwind])
> > > >  
> > > > +PKG_CHECK_MODULES([libdrm], [libdrm],
> > > > +   [CPPFLAGS="$CPPFLAGS $libdrm_CFLAGS"],
> > > > +   [CPPFLAGS="$CPPFLAGS -I/usr/include/drm"])
> > > 
> > > yikes, no, this is a really really bad idea.  it should read:
> > > PKG_CHECK_MODULES([LIBDRM], [libdrm],
> > >   [CPPFLAGS="$CPPFLAGS $LIBDRM_CFLAGS"], [:])
> > 
> > I take it you don't want me to fallback on kernel headers and skip
> > compiling with drm support if libdrm is not available?
> 
> you cannot hardcode any path at all.  if the kernel headers provide all
> of the defines/structs that you need, then just include them directly
> via #include .
> -mike

The prefered "drm way" is to always use the libdrm headers and never the kernel
headers. I know this is breaking the rules but it's what we got to work with.
Some distros give you the kernel version and others the libdrm version. The
kernel version is wrong and libdrm patches this up since we're not allowed to
break the userspace interface. I think the safest way would be to only compile
drm support for strace if libdrm is present and ignore the kernel headers.

What do you think?

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

[Intel-gfx] Updated drm-intel-testing

[Daniel Vetter]

Hi all,

New -testing cycle with cool stuff:
- kerneldoc for tiling/swizzling/fencing code
- bxt hpd port A w/a
- various other fixes all over

... not much, everyone's on vacation.

Happy testing!

Cheers, Daniel

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

Re: [Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels

[Jani Nikula]

On Fri, 31 Jul 2015, Sivakumar Thulasimani  
wrote:
> From: "Thulasimani,Sivakumar" 
>
> BPP bits defined in VBT should be used only on panels whose
> edid version is 1.3 or older. EDID version 1.4 introduced offsets
> where bpp is defined and read into display_info, hence bpp from
> VBT will be used only when bpc in display_info is zero.
>
> v2: use display_info.bpc for deciding when to use vbt_bpp (Jani)
>
> Signed-off-by: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 44f8a32..ae00e86 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1409,7 +1409,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>* bpc in between. */
>   bpp = pipe_config->pipe_bpp;
>   if (is_edp(intel_dp)) {
> - if (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp) {
> +
> + /* Get bpp from vbt only for panels that dont have bpp in edid 
> */
> + if (intel_connector->base.display_info.bpc == 0 &&
> + (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp)) 
> {

The indentation seems wrong here, otherwise

Reviewed-by: Jani Nikula 



>   DRM_DEBUG_KMS("clamping bpp for eDP panel to 
> BIOS-provided %i\n",
> dev_priv->vbt.edp_bpp);
>   bpp = dev_priv->vbt.edp_bpp;
> -- 
> 1.7.9.5
>

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

Re: [Intel-gfx] [PATCH] drm/atomic: Paper over locking WARN in default_state_clear

[Maarten Lankhorst]

Hey,

Op 29-07-15 om 12:51 schreef Daniel Vetter:
> In
>
> commit 6f75cea66c8dd043ced282016b21a639af176642
> Author: Daniel Vetter 
> Date:   Wed Nov 19 18:38:07 2014 +0100
>
> drm/atomic: Only destroy connector states with connection mutex held
>
> I tried to fix races of atomic commits against connector
> hot-unplugging. The idea is to ensure lifetimes by holding the
> connection_mutex long enough. That works for synchronous commits, but
> not for async ones.
>
> For async atomic commit we really need to fix up connector lifetimes
> for real. But that's a much bigger task, so just add more duct-tape:
> For cleaning up connector states we currently don't need the connector
> itself. So NULL it out and remove the locking check. Of course that
> check was to protect the entire sequence, but the modeset itself
> should be save since currently DP MST hot-removal does a dpms-off. And
> that should synchronize with any outstanding async atomic commit.
>
> Or at least that's my hope, this is all a giant mess.
>
> Reported-by: Maarten Lankhorst 
> Cc: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3efd91c0c6cb..434915448ea0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -153,9 +153,15 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   if (!connector)
>   continue;
>  
> - WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));
> -
> - connector->funcs->atomic_destroy_state(connector,
> + /*
> +  * FIXME: Async commits can race with connector unplugging and
> +  * there's currently nothing that prevents cleanup up state for
> +  * deleted connectors. As long as the callback doesn't look at
> +  * the connector we'll be fine though, so make sure that's the
> +  * case by setting all connector pointers to NULL.
> +  */
> + state->connector_states[i]->connector = NULL;
> + connector->funcs->atomic_destroy_state(NULL,
>  
> state->connector_states[i]);
>
This wouldn't provide any additional guarantee during the async commit itself, 
so please don't do this. :-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx