mthierry

Keybase proof

I hereby claim:

• I am mthierry on github.
• I am mthierry (https://keybase.io/mthierry) on keybase.
• I have a public key whose fingerprint is 304F 8695 1D45 A718 CBC1 11EB 388B 137A AC67 6C48

To claim this, I am signing this object:

mthierry

@@ -10,7 +10,7 @@
 		<false/>
 	</dict>
 	<key>UUID</key>
-	<integer>13</integer>
+	<integer>14</integer>
 	<key>centeredOrigin</key>
 	<false/>
 	<key>currentResolution</key>
 @@ -485,6 +485,84 @@

mthierry

diff --git a/tools/releasetools/add_img_to_target_files.py b/tools/releasetools/add_img_to_target_files.py
index bf217e0..f8c34f9 100755
--- a/tools/releasetools/add_img_to_target_files.py
+++ b/tools/releasetools/add_img_to_target_files.py
@@ -215,7 +215,7 @@ def AddImagesToTargetFiles(filename):
 
   input_zip.close()
   output_zip = zipfile.ZipFile(filename, "a",
-                               compression=zipfile.ZIP_DEFLATED)
+                               compression=zipfile.ZIP_DEFLATED, allowZip64=True)

mthierry

From 6a477f4ddc53282aa752c4ccca44bbfea1eb0751 Mon Sep 17 00:00:00 2001
From: Michel Thierry <michel.thierry@intel.com>
Date: Wed, 22 Apr 2015 15:56:12 +0100
Subject: [PATCH] drm/i915: Do not re-allocate vmas in aliasing ppgtt

Aliasing ppgtt is fully allocated right after creation, thus shouldn't
need to call allocate_va_range in i915_vma_bind.

This duplication started after commit 5c5f645773b6d147bf68c350674dc3ef4f8de83d
("drm/i915: drm/i915: Unify aliasing ppgtt handling"), as aliasing ppgtt

mthierry

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6adee4c..4956f03 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -234,6 +234,7 @@ drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
     }
     mutex_unlock(&obj->dev->object_name_lock);
 
+    trace_printk("handle_unref_unlocked, obj=%p\n", obj);
     drm_gem_object_unreference_unlocked(obj);

mthierry

From d43f41250b3628450e268f7d325c066e19c00a8b Mon Sep 17 00:00:00 2001
From: Michel Thierry <michel.thierry@intel.com>
Date: Tue, 12 May 2015 10:25:52 +0100
Subject: [PATCH] drm: Prevent null mutext_unlock

Added by commit 672cb1d6aec7da2799afd1b529d5136d84ed2561
Author: Daniel Stone <daniels@collabora.com>
Date:   Mon Apr 20 19:22:55 2015 +0100

    drm: Add reference counting to blob properties

mthierry

From 420497e2891a2ed31619e016a9d597d165ea4eb9 Mon Sep 17 00:00:00 2001
From: Michel Thierry <michel.thierry@intel.com>
Date: Tue, 23 Jun 2015 10:46:49 +0100
Subject: [PATCH v2] intel: Add EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag.

Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.

In specific, any resource used with flat/heapless (0x00000000-0xfffff000)
General State Heap (GSH) or Intruction State Heap (ISH) must be in a

mthierry

From 9a9e9424f5c49f9c5d6a40c936c0d2136ac3678b Mon Sep 17 00:00:00 2001
From: Michel Thierry <michel.thierry@intel.com>
Date: Tue, 23 Jun 2015 11:11:22 +0100
Subject: [PATCH v2] i965/gen8+: bo in state base address must be in 32-bit
 address range

Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.

In specific, any resource used with flat/heapless (0x00000000-0xfffff000)

mthierry

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3427b11..facb5f5 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -260,6 +260,8 @@ static void drm_mm_insert_helper_range(struct drm_mm_node *hole_node,
 	u64 adj_start = hole_start;
 	u64 adj_end = hole_end;
 
+	DRM_DEBUG_DRIVER("hole_start=0x%llx, hole_end=0x%llx, adj_start=0x%llx, adj_end=0x%llx, start=0x%llx, end=0x%llx, alignment=%u\n",
+			 hole_start, hole_end, adj_start, adj_end, start, end, alignment);

mthierry

From 502bfa38c5fe0965ca0a90e8b7858c453838e400 Mon Sep 17 00:00:00 2001
From: Michel Thierry <michel.thierry@intel.com>
Date: Tue, 23 Jun 2015 11:11:22 +0100
Subject: [PATCH v2] i965/gen8+: bo in state base address must be in 32-bit
 address range

Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.

In specific, any resource used with flat/heapless (0x00000000-0xfffff000)