[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43829

--- Comment #26 from Alex Deucher  ---
Created attachment 82347
  --> https://bugs.freedesktop.org/attachment.cgi?id=82347=edit
possible fix

Does the attached patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/fad9ffe8/attachment.html>

[Bug 61470] Driver does not turn on LCD backlight on resume

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61470

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 43829 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/dca7b098/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43829

Alex Deucher  changed:

   What|Removed |Added

 CC||webmaster at jamescobban.net

--- Comment #25 from Alex Deucher  ---
*** Bug 61470 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/5cbbc892/attachment.html>

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66450

--- Comment #8 from Eugene Shalygin <eugene.shalygin+bugzilla.FDO at gmail.com> 
---
With this patch playback works. Thank you!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/857ebf8a/attachment.html>

[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44772

Harald Judt  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |MOVED

--- Comment #12 from Harald Judt  ---
Just for reference: Since I've never got a response here, I've opened a bug
report at kernel bugzilla in the hope of someone helping me collect more debug
data: https://bugzilla.kernel.org/show_bug.cgi?id=57381

Since everything's documented there, I'll finally close this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/07345f01/attachment.html>

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

--- Comment #23 from Harald Judt  ---
Thanks, I confirm that the patch fixes the problem!

I've tested this at least 5 times with both the vanilla and the tuxonice
hibernation, and both now work pretty stable with 3.10. (As a side note: The
BFQ IO scheduler patch makes my system hang when suspending, but that is a
different issue and really not a concern for this bug report.)

Now I'm still plagued by bug #44772, which is similar in that it only happens
when resuming from hibernation, not when suspending, and it seems to occur much
more often with 3.10 with pm_async=0 than before.

As far as my machine is concerned, I consider this solved and 3.10 has become
usable for me. Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/80d094f2/attachment.html>

[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44772

Harald Judt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Harald Judt  ---
Reopened because it happens with 3.10 now even with pm_async set to 0. It
happens with older kernel releases too when pm_async is set to 0, but is much
harder to reproduce.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/b0f4db0b/attachment.html>

Questions about TTM buffer object maping

[Jerome Glisse]

On Thu, Jul 11, 2013 at 5:43 PM, Jean-S?bastien P?dron
 wrote:
> Hi,
>
> Thank you J?r?me and Daniel for your input, that's really helpful!
>
> I have another question: in ttm_bo_mmap(), a reference to the buffer object
> is acquired at the beginning of the function. Another reference is acquired
> in ttm_bo_vm_open() (released in ttm_bo_vm_close()).
>
> But where is the first reference released?
>
> --
> Jean-S?bastien P?dron

the ttm_bo_vm_open is not call on first time a vma is mmap, ie when
userspace do mmap it call driver
mmap callback which call ttm_bo_mmap but ttm_bo_vm_open is never call.
If the same process or
another process mmap the same area or subarea the ttm_bo_vm_open is
call. Then on each unmap
ttm_bo_vm_close is call.

Cheers,
Jerome

[PATCH] drm/gpio/nv50: post nv92 cards have 32 interrupt lines

[Emil Velikov]

Since the original merge of nouveau to upstream kernel, we were assuming that
nv90 (and later) cards have 32 lines.

Based on mmio traces of the binary driver, as well as PBUS error messages
during read/write of the e070/e074 registers, we can conclude that nv92 has
only 16 lines whereas nv94 (and later) cards have 32.

Reported-and-tested-by: David M. Lloyd 
Signed-off-by: Emil Velikov 
Cc: dri-devel at lists.freedesktop.org
Cc: Ben Skeggs 
---

Considering that no-one has reported this issue before, I'm rather curious
if we should CC stable

---
 drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c 
b/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c
index bf489dc..c4c1d41 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c
@@ -103,7 +103,7 @@ nv50_gpio_intr(struct nouveau_subdev *subdev)
int i;

intr0 = nv_rd32(priv, 0xe054) & nv_rd32(priv, 0xe050);
-   if (nv_device(priv)->chipset >= 0x90)
+   if (nv_device(priv)->chipset > 0x92)
intr1 = nv_rd32(priv, 0xe074) & nv_rd32(priv, 0xe070);

hi = (intr0 & 0x) | (intr1 << 16);
@@ -115,7 +115,7 @@ nv50_gpio_intr(struct nouveau_subdev *subdev)
}

nv_wr32(priv, 0xe054, intr0);
-   if (nv_device(priv)->chipset >= 0x90)
+   if (nv_device(priv)->chipset > 0x92)
nv_wr32(priv, 0xe074, intr1);
 }

@@ -146,7 +146,7 @@ nv50_gpio_ctor(struct nouveau_object *parent, struct 
nouveau_object *engine,
int ret;

ret = nouveau_gpio_create(parent, engine, oclass,
- nv_device(parent)->chipset >= 0x90 ? 32 : 16,
+ nv_device(parent)->chipset > 0x92 ? 32 : 16,
  );
*pobject = nv_object(priv);
if (ret)
@@ -182,7 +182,7 @@ nv50_gpio_init(struct nouveau_object *object)
/* disable, and ack any pending gpio interrupts */
nv_wr32(priv, 0xe050, 0x);
nv_wr32(priv, 0xe054, 0x);
-   if (nv_device(priv)->chipset >= 0x90) {
+   if (nv_device(priv)->chipset > 0x92) {
nv_wr32(priv, 0xe070, 0x);
nv_wr32(priv, 0xe074, 0x);
}
@@ -195,7 +195,7 @@ nv50_gpio_fini(struct nouveau_object *object, bool suspend)
 {
struct nv50_gpio_priv *priv = (void *)object;
nv_wr32(priv, 0xe050, 0x);
-   if (nv_device(priv)->chipset >= 0x90)
+   if (nv_device(priv)->chipset > 0x92)
nv_wr32(priv, 0xe070, 0x);
return nouveau_gpio_fini(>base, suspend);
 }
-- 
1.8.3.2

Bug in warning message from MTRR rework in uvesafb

[Dave Airlie]

On Thu, Jul 11, 2013 at 3:36 AM, Andy Lutomirski  wrote:
> On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
>  wrote:
>> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
>> MTRR code" contains the following change:
>>
>> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
>>  }
>>  }
>>
>> +if (mtrr != 3 && mtrr != 1)
>> +pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is
>> unsupported", mtrr);
>> +
>>  return 0;
>>  }
>>  #endif /* !MODULE */
>>
>> Shouldn't this be && mtrr != 0?
>
> Indeed, and Sylvain Hitier (cc'd) sent a patch (off-list) that must
> have gotten lost somewhere.
>


Yeah I should get an email reply thing for off-list stuff, as its even
more likely I'll lose it.

Dave.

[PATCH 3/3] drm/radeon: add fault decode function for CIK

[alexdeuc...@gmail.com]

From: Alex Deucher 

Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/cik.c  |   32 ++--
 drivers/gpu/drm/radeon/cikd.h |   16 
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 27891d8..68b4fc5 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4442,6 +4442,29 @@ void cik_vm_fini(struct radeon_device *rdev)
 }

 /**
+ * cik_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (CIK).
+ */
+static void cik_vm_decode_fault(struct radeon_device *rdev,
+   u32 status, u32 addr, u32 mc_client)
+{
+   u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
+   u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
+   u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
+   char *block = (char *)_client;
+
+   printk("VM fault (0x%02x, vmid %d) at page %u, %s from %s (%d)\n",
+  protections, vmid, addr,
+  (status & MEMORY_CLIENT_RW_MASK) ? "write" : "read",
+  block, mc_id);
+}
+
+/**
  * cik_vm_flush - cik vm flush using the CP
  *
  * @rdev: radeon_device pointer
@@ -5496,6 +5519,7 @@ int cik_irq_process(struct radeon_device *rdev)
u32 ring_index;
bool queue_hotplug = false;
bool queue_reset = false;
+   u32 addr, status, mc_client;

if (!rdev->ih.enabled || rdev->shutdown)
return IRQ_NONE;
@@ -5731,11 +5755,15 @@ restart_ih:
break;
case 146:
case 147:
+   addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
+   status = RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS);
+   mc_client = 
RREG32(VM_CONTEXT1_PROTECTION_FAULT_MCCLIENT);
dev_err(rdev->dev, "GPU fault detected: %d 0x%08x\n", 
src_id, src_data);
dev_err(rdev->dev, "  VM_CONTEXT1_PROTECTION_FAULT_ADDR 
  0x%08X\n",
-   RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
+   addr);
dev_err(rdev->dev, "  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
-   RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
+   status);
+   cik_vm_decode_fault(rdev, status, addr, mc_client);
/* reset addr and status */
WREG32_P(VM_CONTEXT1_CNTL2, 1, ~1);
break;
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index 63514b9..7e9275e 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -136,6 +136,22 @@
 #define VM_INVALIDATE_RESPONSE 0x147c

 #defineVM_CONTEXT1_PROTECTION_FAULT_STATUS 0x14DC
+#definePROTECTIONS_MASK(0xf << 0)
+#definePROTECTIONS_SHIFT   0
+   /* bit 0: range
+* bit 1: pde0
+* bit 2: valid
+* bit 3: read
+* bit 4: write
+*/
+#defineMEMORY_CLIENT_ID_MASK   (0xff << 12)
+#defineMEMORY_CLIENT_ID_SHIFT  12
+#defineMEMORY_CLIENT_RW_MASK   (1 << 24)
+#defineMEMORY_CLIENT_RW_SHIFT  24
+#defineFAULT_VMID_MASK (0xf << 25)
+#defineFAULT_VMID_SHIFT25
+
+#defineVM_CONTEXT1_PROTECTION_FAULT_MCCLIENT   0x14E4

 #defineVM_CONTEXT1_PROTECTION_FAULT_ADDR   0x14FC

-- 
1.7.7.5

[PATCH 2/3] drm/radeon: add fault decode function for SI (v2)

[alexdeuc...@gmail.com]

From: Alex Deucher 

Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.

v2: simplify fault decoding

Signed-off-by: Alex Deucher 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/si.c  |  272 +-
 drivers/gpu/drm/radeon/sid.h |   14 ++
 2 files changed, 284 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index f305768..d3f0507 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4390,6 +4390,270 @@ void si_vm_fini(struct radeon_device *rdev)
 }

 /**
+ * si_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (SI).
+ */
+static void si_vm_decode_fault(struct radeon_device *rdev,
+  u32 status, u32 addr)
+{
+   u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
+   u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
+   u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
+   char *block;
+
+   if (rdev->family == CHIP_TAHITI) {
+   switch (mc_id) {
+   case 160:
+   case 144:
+   case 96:
+   case 80:
+   case 224:
+   case 208:
+   case 32:
+   case 16:
+   block = "CB";
+   break;
+   case 161:
+   case 145:
+   case 97:
+   case 81:
+   case 225:
+   case 209:
+   case 33:
+   case 17:
+   block = "CB_FMASK";
+   break;
+   case 162:
+   case 146:
+   case 98:
+   case 82:
+   case 226:
+   case 210:
+   case 34:
+   case 18:
+   block = "CB_CMASK";
+   break;
+   case 163:
+   case 147:
+   case 99:
+   case 83:
+   case 227:
+   case 211:
+   case 35:
+   case 19:
+   block = "CB_IMMED";
+   break;
+   case 164:
+   case 148:
+   case 100:
+   case 84:
+   case 228:
+   case 212:
+   case 36:
+   case 20:
+   block = "DB";
+   break;
+   case 165:
+   case 149:
+   case 101:
+   case 85:
+   case 229:
+   case 213:
+   case 37:
+   case 21:
+   block = "DB_HTILE";
+   break;
+   case 167:
+   case 151:
+   case 103:
+   case 87:
+   case 231:
+   case 215:
+   case 39:
+   case 23:
+   block = "DB_STEN";
+   break;
+   case 72:
+   case 68:
+   case 64:
+   case 8:
+   case 4:
+   case 0:
+   case 136:
+   case 132:
+   case 128:
+   case 200:
+   case 196:
+   case 192:
+   block = "TC";
+   break;
+   case 112:
+   case 48:
+   block = "CP";
+   break;
+   case 49:
+   case 177:
+   case 50:
+   case 178:
+   block = "SH";
+   break;
+   case 53:
+   case 190:
+   block = "VGT";
+   break;
+   case 117:
+   block = "IH";
+   break;
+   case 51:
+   case 115:
+   block = "RLC";
+   break;
+   case 119:
+   case 183:
+   block = "DMA0";
+   break;
+   case 61:
+   block = "DMA1";
+   break;
+   case 248:
+   case 120:
+   block = "HDP";
+   break;
+   default:
+   block = "unknown";
+   break;
+   }
+   } else {
+   switch (mc_id) {
+   case 32:
+   case 16:
+   case 96:
+   case 80:
+   case 160:
+   case 144:
+   

[PATCH 1/3] drm/radeon: add fault decode function for cayman/TN (v2)

[alexdeuc...@gmail.com]

From: Alex Deucher 

Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.

v2: simplify fault decoding

Signed-off-by: Alex Deucher 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/evergreen.c |   10 ++-
 drivers/gpu/drm/radeon/ni.c|  161 
 drivers/gpu/drm/radeon/nid.h   |   16 
 3 files changed, 185 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 9e14007..bc6936a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -139,6 +139,8 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev);
 void evergreen_program_aspm(struct radeon_device *rdev);
 extern void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
 int ring, u32 cp_int_cntl);
+extern void cayman_vm_decode_fault(struct radeon_device *rdev,
+  u32 status, u32 addr);

 static const u32 evergreen_golden_registers[] =
 {
@@ -4629,6 +4631,7 @@ int evergreen_irq_process(struct radeon_device *rdev)
bool queue_hotplug = false;
bool queue_hdmi = false;
bool queue_thermal = false;
+   u32 status, addr;

if (!rdev->ih.enabled || rdev->shutdown)
return IRQ_NONE;
@@ -4915,11 +4918,14 @@ restart_ih:
break;
case 146:
case 147:
+   addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
+   status = RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS);
dev_err(rdev->dev, "GPU fault detected: %d 0x%08x\n", 
src_id, src_data);
dev_err(rdev->dev, "  VM_CONTEXT1_PROTECTION_FAULT_ADDR 
  0x%08X\n",
-   RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
+   addr);
dev_err(rdev->dev, "  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
-   RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
+   status);
+   cayman_vm_decode_fault(rdev, status, addr);
/* reset addr and status */
WREG32_P(VM_CONTEXT1_CNTL2, 1, ~1);
break;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 465b17e..56bd4f3 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2450,6 +2450,167 @@ void cayman_vm_fini(struct radeon_device *rdev)
 {
 }

+/**
+ * cayman_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (cayman/TN).
+ */
+void cayman_vm_decode_fault(struct radeon_device *rdev,
+   u32 status, u32 addr)
+{
+   u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
+   u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
+   u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
+   char *block;
+
+   switch (mc_id) {
+   case 32:
+   case 16:
+   case 96:
+   case 80:
+   case 160:
+   case 144:
+   case 224:
+   case 208:
+   block = "CB";
+   break;
+   case 33:
+   case 17:
+   case 97:
+   case 81:
+   case 161:
+   case 145:
+   case 225:
+   case 209:
+   block = "CB_FMASK";
+   break;
+   case 34:
+   case 18:
+   case 98:
+   case 82:
+   case 162:
+   case 146:
+   case 226:
+   case 210:
+   block = "CB_CMASK";
+   break;
+   case 35:
+   case 19:
+   case 99:
+   case 83:
+   case 163:
+   case 147:
+   case 227:
+   case 211:
+   block = "CB_IMMED";
+   break;
+   case 36:
+   case 20:
+   case 100:
+   case 84:
+   case 164:
+   case 148:
+   case 228:
+   case 212:
+   block = "DB";
+   break;
+   case 37:
+   case 21:
+   case 101:
+   case 85:
+   case 165:
+   case 149:
+   case 229:
+   case 213:
+   block = "DB_HTILE";
+   break;
+   case 38:
+   case 22:
+   case 102:
+   case 86:
+   case 166:
+   case 150:
+   case 230:
+   case 214:
+   block = "SX";
+   break;
+   case 39:
+   case 23:
+   case 103:
+   case 87:
+   case 167:
+   case 151:
+   case 231:
+   case 215:
+   block = "DB_STEN";
+   break;
+   case 40:
+   case 24:
+   case 104:
+   case 88:
+   case 232:
+ 

[PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx

[Alex Deucher]

On Thu, Jul 11, 2013 at 3:59 PM, Ilija Hadzic
 wrote:
>
> Alex,
>
> Can you please share some details about the nature or symptom of the
> "instability". One problem that I have been seeing on my end is that when I
> use the DMA ring intensively (by intensively I mean, calling the copy
> function every frame), combined with some 3D rendering that causes a lot of
> cs_ioctl calls, that I can provoke a corruption of the olist field in
> radeon_sa_bo structure, consequently causing an oops in
> radeon_sa_bo_try_free(). I have also found that I can suppress the problem
> if I add some padding fields at the beginnig of the radeon_sa_bo structure
> (essentially moving the olist field down).
>
> So I speculate that the use of DMA somehow results in corrupting that
> structure, but I have not yet done enough experiments to prove or disprove
> that theory (so I have not spoke up yet). Also my kernel is full of my own
> internal hacks, and I have not yet taken the time to reproduce the problem
> with the "stock" kernel. However, after seeing your patch series, I am
> wondering if the instability you are referring to may be of the same or
> similar nature.

Basically using the DMA engine on r6xx seems to lead to hangs on
certain chips when the bo copy callback gets triggered a lot (e.g., a
web page with lots of images, etc.).  Switching back to the 3D engine
fixes the issue.  R6xx was the first asic family with the async dma
engines, so there are likely some hw bugs at play.  Unfortunately, the
hw guys haven't looked at 6xx in probably 8 years, so I don't hold out
much chance of getting to the root of the problem at this point.

Alex

>
> thanks,
>
> Ilija
>
>
>
> On Thu, 11 Jul 2013, alexdeucher at gmail.com wrote:
>
>> From: Alex Deucher 
>>
>> They still seem to cause instability on some r6xx parts.
>> As a follow up, we can switch to using CP DMA for bo
>> moves on r6xx as a lighter weight alternative to using
>> the 3D engine.
>>
>> A version of this patch should also go to stable kernels.
>>
>> Tested-by: J.N. 
>> Signed-off-by: Alex Deucher 
>> ---
>> drivers/gpu/drm/radeon/radeon_asic.c |   12 ++--
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
>> b/drivers/gpu/drm/radeon/radeon_asic.c
>> index 0970774..ea5c52b 100644
>> --- a/drivers/gpu/drm/radeon/radeon_asic.c
>> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
>> @@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
>> .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> .dma = _copy_dma,
>> .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
>> -   .copy = _copy_dma,
>> -   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>> +   .copy = _copy_blit,
>> +   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> },
>> .surface = {
>> .set_reg = r600_set_surface_reg,
>> @@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
>> .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> .dma = _copy_dma,
>> .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
>> -   .copy = _copy_dma,
>> -   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>> +   .copy = _copy_blit,
>> +   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> },
>> .surface = {
>> .set_reg = r600_set_surface_reg,
>> @@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
>> .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> .dma = _copy_dma,
>> .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
>> -   .copy = _copy_dma,
>> -   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>> +   .copy = _copy_blit,
>> +   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> },
>> .surface = {
>> .set_reg = r600_set_surface_reg,
>> --
>> 1.7.7.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

[PATCH] drm/radeon: use radeon device for request firmware

[j.gli...@gmail.com]

From: Jerome Glisse 

Avoid creating temporary platform device that will lead to issue
when several radeon gpu are in same computer. Instead directly use
the radeon device for requesting firmware.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/cik.c| 25 +++--
 drivers/gpu/drm/radeon/ni.c | 21 +
 drivers/gpu/drm/radeon/r100.c   | 11 +--
 drivers/gpu/drm/radeon/r600.c   | 19 ---
 drivers/gpu/drm/radeon/radeon_uvd.c | 13 +
 drivers/gpu/drm/radeon/si.c | 23 ++-
 6 files changed, 24 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index db507a4..b893165 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -22,7 +22,6 @@
  * Authors: Alex Deucher
  */
 #include 
-#include 
 #include 
 #include 
 #include "drmP.h"
@@ -742,7 +741,6 @@ static int ci_mc_load_microcode(struct radeon_device *rdev)
  */
 static int cik_init_microcode(struct radeon_device *rdev)
 {
-   struct platform_device *pdev;
const char *chip_name;
size_t pfp_req_size, me_req_size, ce_req_size,
mec_req_size, rlc_req_size, mc_req_size,
@@ -752,13 +750,6 @@ static int cik_init_microcode(struct radeon_device *rdev)

DRM_DEBUG("\n");

-   pdev = platform_device_register_simple("radeon_cp", 0, NULL, 0);
-   err = IS_ERR(pdev);
-   if (err) {
-   printk(KERN_ERR "radeon_cp: Failed to register firmware\n");
-   return -EINVAL;
-   }
-
switch (rdev->family) {
case CHIP_BONAIRE:
chip_name = "BONAIRE";
@@ -794,7 +785,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
DRM_INFO("Loading %s Microcode\n", chip_name);

snprintf(fw_name, sizeof(fw_name), "radeon/%s_pfp.bin", chip_name);
-   err = request_firmware(>pfp_fw, fw_name, >dev);
+   err = request_firmware(>pfp_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->pfp_fw->size != pfp_req_size) {
@@ -806,7 +797,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}

snprintf(fw_name, sizeof(fw_name), "radeon/%s_me.bin", chip_name);
-   err = request_firmware(>me_fw, fw_name, >dev);
+   err = request_firmware(>me_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->me_fw->size != me_req_size) {
@@ -817,7 +808,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}

snprintf(fw_name, sizeof(fw_name), "radeon/%s_ce.bin", chip_name);
-   err = request_firmware(>ce_fw, fw_name, >dev);
+   err = request_firmware(>ce_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->ce_fw->size != ce_req_size) {
@@ -828,7 +819,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}

snprintf(fw_name, sizeof(fw_name), "radeon/%s_mec.bin", chip_name);
-   err = request_firmware(>mec_fw, fw_name, >dev);
+   err = request_firmware(>mec_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->mec_fw->size != mec_req_size) {
@@ -839,7 +830,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}

snprintf(fw_name, sizeof(fw_name), "radeon/%s_rlc.bin", chip_name);
-   err = request_firmware(>rlc_fw, fw_name, >dev);
+   err = request_firmware(>rlc_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->rlc_fw->size != rlc_req_size) {
@@ -850,7 +841,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}

snprintf(fw_name, sizeof(fw_name), "radeon/%s_sdma.bin", chip_name);
-   err = request_firmware(>sdma_fw, fw_name, >dev);
+   err = request_firmware(>sdma_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->sdma_fw->size != sdma_req_size) {
@@ -863,7 +854,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
/* No MC ucode on APUs */
if (!(rdev->flags & RADEON_IS_IGP)) {
snprintf(fw_name, sizeof(fw_name), "radeon/%s_mc.bin", 
chip_name);
-   err = request_firmware(>mc_fw, fw_name, >dev);
+   err = request_firmware(>mc_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->mc_fw->size != mc_req_size) {
@@ -875,8 +866,6 @@ static int cik_init_microcode(struct radeon_device *rdev)
}

 out:
-   platform_device_unregister(pdev);
-
if (err) {
if (err != -EINVAL)
printk(KERN_ERR
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index f30127c..465b17e 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -22,7 +22,6 @@
  * Authors: Alex Deucher
  */
 #include 
-#include 
 #include 
 

[PATCH] drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate

[Alex Deucher]

I've picked up the patch for my fixes queue.  Thanks!

Alex

On Wed, Jul 10, 2013 at 6:26 AM, Maarten Lankhorst
 wrote:
> Op 10-07-13 12:03, Markus Trippelsdorf schreef:
>> On 2013.07.10 at 11:56 +0200, Maarten Lankhorst wrote:
>>> Op 10-07-13 11:46, Markus Trippelsdorf schreef:
 On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote:
> Op 10-07-13 11:22, Markus Trippelsdorf schreef:
>> By simply copy/pasting a big document under LibreOffice my system hangs
>> itself up. Only a hard reset gets it working again.
>> see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551
>>
>> I've bisected the issue to:
>>
>> commit ecff665f5e3f1c6909353e00b9420e45ae23d995
>> Author: Maarten Lankhorst 
>> Date:   Thu Jun 27 13:48:17 2013 +0200
>>
>> drm/ttm: make ttm reservation calls behave like reservation calls
>>
>> This commit converts the source of the val_seq counter to
>> the ww_mutex api. The reservation objects are converted later,
>> because there is still a lockdep splat in nouveau that has to
>> resolved first.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Reviewed-by: Jerome Glisse 
>> Signed-off-by: Dave Airlie 
> Hey,
>
> Can you try current head with CONFIG_PROVE_LOCKING set and post the
> lockdep splat from dmesg, if any? If there is any locking issue
> lockdep should warn about it.  Lockdep will turn itself off after the
> first splat, so if the lockdep splat happens before running the
> affected parts those will have to be fixed first.
 There was an unrelated EDAC lockdep splat, so I simply disabled it.

 This is what I get:

 Jul 10 11:40:44 x4 kernel: 
 Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
 Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
 Jul 10 11:40:44 x4 kernel: 
 Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still 
 held!
 Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
 Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, 
 at: [] radeon_bo_list_validate+0x20/0xd0
 Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: 
 [] ttm_eu_reserve_buffers+0x126/0x4b0
 Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
 Jul 10 11:40:53 x4 kernel: Emergency Sync complete

>>> Thanks, exactly what I thought. I missed a backoff somewhere..
>>>
>>> Does the below patch fix it?
>> Yes. Thank you for your quick reply.
>
> 8<--
> If radeon_cs_parser_relocs fails ttm_eu_backoff_reservation doesn't get 
> called.
> This left open a bug where ttm_eu_reserve_buffers succeeded but the bo's were
> not unlocked afterwards:
>
> Jul 10 11:40:44 x4 kernel: 
> Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
> Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
> Jul 10 11:40:44 x4 kernel: 
> Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
> Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
> Jul 10 11:40:44 x4 kernel: #0:  (reservation_ww_class_acquire){+.+.+.}, at: 
> [] radeon_bo_list_validate+0x20/0xd0
> Jul 10 11:40:44 x4 kernel: #1:  (reservation_ww_class_mutex){+.+.+.}, at: 
> [] ttm_eu_reserve_buffers+0x126/0x4b0
> Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
> Jul 10 11:40:53 x4 kernel: Emergency Sync complete
>
> This is a regression caused by commit ecff665f5e.
> "drm/ttm: make ttm reservation calls behave like reservation calls"
>
> Reported-by: Markus Trippelsdorf 
> Tested-by: Markus Trippelsdorf 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 0219d26..2020bf4 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -377,6 +377,7 @@ int radeon_bo_list_validate(struct ww_acquire_ctx *ticket,
> domain = lobj->alt_domain;
> goto retry;
> }
> +   ttm_eu_backoff_reservation(ticket, head);
> return r;
> }
> }
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/radeon: use CP DMA on r6xx for bo moves

[alexdeuc...@gmail.com]

From: Alex Deucher 

Lighter weight than using the 3D engine.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_asic.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index ea5c52b..fea997e 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,7 +1026,7 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = _copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = _copy_blit,
+   .copy = _copy_cpdma,
.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
@@ -1119,7 +1119,7 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = _copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = _copy_blit,
+   .copy = _copy_cpdma,
.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
@@ -1229,7 +1229,7 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = _copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = _copy_blit,
+   .copy = _copy_cpdma,
.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
-- 
1.7.7.5

[PATCH 2/3] drm/radeon: implement bo copy callback using CP DMA (v2)

[alexdeuc...@gmail.com]

From: Alex Deucher 

Lighter weight than using the 3D engine.

v2: fix ring count

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/r600.c|   81 ++
 drivers/gpu/drm/radeon/r600d.h   |1 +
 drivers/gpu/drm/radeon/radeon_asic.h |3 +
 3 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2d3655f..f7d494f 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3145,6 +3145,87 @@ int r600_copy_blit(struct radeon_device *rdev,
 }

 /**
+ * r600_copy_cpdma - copy pages using the CP DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the CP DMA engine (r6xx+).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int r600_copy_cpdma(struct radeon_device *rdev,
+   uint64_t src_offset, uint64_t dst_offset,
+   unsigned num_gpu_pages,
+   struct radeon_fence **fence)
+{
+   struct radeon_semaphore *sem = NULL;
+   int ring_index = rdev->asic->copy.blit_ring_index;
+   struct radeon_ring *ring = >ring[ring_index];
+   u32 size_in_bytes, cur_size_in_bytes, tmp;
+   int i, num_loops;
+   int r = 0;
+
+   r = radeon_semaphore_create(rdev, );
+   if (r) {
+   DRM_ERROR("radeon: moving bo (%d).\n", r);
+   return r;
+   }
+
+   size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);
+   num_loops = DIV_ROUND_UP(size_in_bytes, 0x1f);
+   r = radeon_ring_lock(rdev, ring, num_loops * 6 + 21);
+   if (r) {
+   DRM_ERROR("radeon: moving bo (%d).\n", r);
+   radeon_semaphore_free(rdev, , NULL);
+   return r;
+   }
+
+   if (radeon_fence_need_sync(*fence, ring->idx)) {
+   radeon_semaphore_sync_rings(rdev, sem, (*fence)->ring,
+   ring->idx);
+   radeon_fence_note_sync(*fence, ring->idx);
+   } else {
+   radeon_semaphore_free(rdev, , NULL);
+   }
+
+   for (i = 0; i < num_loops; i++) {
+   cur_size_in_bytes = size_in_bytes;
+   if (cur_size_in_bytes > 0x1f)
+   cur_size_in_bytes = 0x1f;
+   size_in_bytes -= cur_size_in_bytes;
+   tmp = upper_32_bits(src_offset) & 0xff;
+   if (size_in_bytes == 0)
+   tmp |= PACKET3_CP_DMA_CP_SYNC;
+   radeon_ring_write(ring, PACKET3(PACKET3_CP_DMA, 4));
+   radeon_ring_write(ring, src_offset & 0x);
+   radeon_ring_write(ring, tmp);
+   radeon_ring_write(ring, dst_offset & 0x);
+   radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
+   radeon_ring_write(ring, cur_size_in_bytes);
+   src_offset += cur_size_in_bytes;
+   dst_offset += cur_size_in_bytes;
+   }
+   radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
+   radeon_ring_write(ring, (WAIT_UNTIL - PACKET3_SET_CONFIG_REG_OFFSET) >> 
2);
+   radeon_ring_write(ring, WAIT_CP_DMA_IDLE_bit);
+
+   r = radeon_fence_emit(rdev, fence, ring->idx);
+   if (r) {
+   radeon_ring_unlock_undo(rdev, ring);
+   return r;
+   }
+
+   radeon_ring_unlock_commit(rdev, ring);
+   radeon_semaphore_free(rdev, , *fence);
+
+   return r;
+}
+
+/**
  * r600_copy_dma - copy pages using the DMA engine
  *
  * @rdev: radeon_device pointer
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index f1b3084..8e3fe81 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -602,6 +602,7 @@
 #defineL2_BUSY (1 << 0)

 #defineWAIT_UNTIL  0x8040
+#define WAIT_CP_DMA_IDLE_bit(1 << 8)
 #define WAIT_2D_IDLE_bit(1 << 14)
 #define WAIT_3D_IDLE_bit(1 << 15)
 #define WAIT_2D_IDLECLEAN_bit   (1 << 16)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 45d0693..b04b578 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -340,6 +340,9 @@ int r600_uvd_ring_test(struct radeon_device *rdev, struct 
radeon_ring *ring);
 int r600_copy_blit(struct radeon_device *rdev,
   uint64_t src_offset, uint64_t dst_offset,
   unsigned num_gpu_pages, struct radeon_fence **fence);
+int r600_copy_cpdma(struct radeon_device *rdev,
+   

[PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx

[alexdeuc...@gmail.com]

From: Alex Deucher 

They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.

A version of this patch should also go to stable kernels.

Tested-by: J.N. 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_asic.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = _copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = _copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = _copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = _copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = _copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = _copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = _copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = _copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = _copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
-- 
1.7.7.5

[PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx

[Ilija Hadzic]

Alex,

Can you please share some details about the nature or symptom of the 
"instability". One problem that I have been seeing on my end is that when 
I use the DMA ring intensively (by intensively I mean, calling the copy 
function every frame), combined with some 3D rendering that causes a lot 
of cs_ioctl calls, that I can provoke a corruption of the olist field in 
radeon_sa_bo structure, consequently causing an oops in 
radeon_sa_bo_try_free(). I have also found that I can suppress the problem 
if I add some padding fields at the beginnig of the radeon_sa_bo structure 
(essentially moving the olist field down).

So I speculate that the use of DMA somehow results in corrupting that 
structure, but I have not yet done enough experiments to prove or disprove 
that theory (so I have not spoke up yet). Also my kernel is full of my own 
internal hacks, and I have not yet taken the time to reproduce the problem 
with the "stock" kernel. However, after seeing your patch series, I am 
wondering if the instability you are referring to may be of the same 
or similar nature.

thanks,

Ilija


On Thu, 11 Jul 2013, alexdeucher at gmail.com wrote:

> From: Alex Deucher 
>
> They still seem to cause instability on some r6xx parts.
> As a follow up, we can switch to using CP DMA for bo
> moves on r6xx as a lighter weight alternative to using
> the 3D engine.
>
> A version of this patch should also go to stable kernels.
>
> Tested-by: J.N. 
> Signed-off-by: Alex Deucher 
> ---
> drivers/gpu/drm/radeon/radeon_asic.c |   12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 0970774..ea5c52b 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
>   .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>   .dma = _copy_dma,
>   .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
> - .copy = _copy_dma,
> - .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
> + .copy = _copy_blit,
> + .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>   },
>   .surface = {
>   .set_reg = r600_set_surface_reg,
> @@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
>   .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>   .dma = _copy_dma,
>   .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
> - .copy = _copy_dma,
> - .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
> + .copy = _copy_blit,
> + .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>   },
>   .surface = {
>   .set_reg = r600_set_surface_reg,
> @@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
>   .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>   .dma = _copy_dma,
>   .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
> - .copy = _copy_dma,
> - .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
> + .copy = _copy_blit,
> + .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>   },
>   .surface = {
>   .set_reg = r600_set_surface_reg,
> -- 
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PULL] drm-intel-fixes

[Daniel Vetter]

Cc lists this time around ...
-Daniel

On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter  wrote:
> Hi Dave,
>
> One feature latecomer, I've forgotten to merge the patch to reeanble the
> Haswell power well feature now that the audio interaction is fixed up.
> Since that was the only unfixed issue with it I've figured I could throw
> it in a bit late, and it's trivial to revert in case I'm wrong.
>
> Otherwise all bug/regression fixes:
> - Fix status page reinit after gpu hangs, spotted by more paranoid igt
>   checks.
> - Fix object list walking fumble regression in the shrinker (only the
>   counting part, the actual shrinking code was correct so no Oops
>   potential), from Xiong Zhang.
> - Fix DP 1.2 bw limits (Imre).
> - Restore legacy forcewake on ivb, too many broken biosen out there. We
>   dump a warn though that recent userspace might fall over with that
>   config (Guenter Roeck).
> - Patch up the gen2 cs tlb w/a.
> - Improve the fence coherency w/a now that we have a better understanding
>   what's going on. The removed wbinvd+ipi should make -rt folks happy. Big
>   thanks to Jon Bloomfield for figuring this out, patches from Chris.
> - Fix write-read race when switching ring (Chris). Spotted with code
>   inspection, but now we also have an igt for it.
>
> There's an ugly regression we're still working on introduced between
> 3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since
> that one fixes another regression :( I've asked Steven to include my
> -fixes branch into linux-next to prevent such fallout in the future,
> hopefully.
>
> Otherwise pretty calm thus far.
>
> Cheers, Daniel
>
> The following changes since commit 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e:
>
>   drm/i915: Don't try to tear down the stolen drm_mm if it's not there 
> (2013-07-02 11:47:19 +0200)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~danvet/drm-intel 
> tags/drm-intel-fixes-2013-07-11
>
> for you to fetch changes up to 46a0b638f35b45fc13d3dc0deb6a7e17988170b2:
>
>   Revert "drm/i915: Workaround incoherence between fences and LLC across 
> multiple CPUs" (2013-07-10 15:31:12 +0200)
>
> 
> Chris Wilson (3):
>   drm/i915: Fix write-read race with multiple rings
>   drm/i915: Fix incoherence with fence updates on Sandybridge+
>   Revert "drm/i915: Workaround incoherence between fences and LLC across 
> multiple CPUs"
>
> Daniel Vetter (2):
>   drm/i915: reinit status page registers after gpu reset
>   drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a
>
> Guenter Roeck (1):
>   Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
>
> Imre Deak (1):
>   drm/i915: fix lane bandwidth capping for DP 1.2 sinks
>
> Paulo Zanoni (1):
>   drm/i915: switch disable_power_well default value to 1
>
> Xiong Zhang (1):
>   drm/i915: Correct obj->mm_list link to 
> dev_priv->dev_priv->mm.inactive_list
>
>  drivers/gpu/drm/i915/i915_drv.c |  4 +-
>  drivers/gpu/drm/i915/i915_gem.c | 83 
> +
>  drivers/gpu/drm/i915/intel_dp.c |  5 ++
>  drivers/gpu/drm/i915/intel_pm.c | 31 +++-
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 38 +--
>  5 files changed, 93 insertions(+), 68 deletions(-)
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)

[Martin Peres]

On 11/07/2013 13:21, David Herrmann wrote:
> Hi
>
> On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres  
> wrote:
>> On 07/07/2013 19:17, David Herrmann wrote:
>>> Hi
>>>
>>> This is v2 of the unified VMA offset manager series. The first draft is
>>> available at LWN [1]. This series replaces the VMA offset managers in GEM
>>> and
>>> TTM with a unified implementation.
>>>
>>> The first 4 patches contain the new VMA offset manager and are the only
>>> patches
>>> that I propose for mainline inclusion.
>>> Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar
>>> patches in i915-next and I will rebase them once it is merged. Ignore
>>> them if you're not interested.
>>> Patches 9-19 implement mmap access control. Comments are welcome! They are
>>> intended for mainline inclusion, too, but probably require some more
>>> review
>>> rounds. I'd really appreciate if driver authors could comment on the
>>> implementation.
>>> Patch 20 shows the main motivation behind this whole series: render nodes.
>>> It is
>>> marked RFC and I will resend once the VMA manager is merged upstream. Feel
>>> free
>>> to test it.
>>>
>>> One more note regarding DRM-Master: Render-clients are independent of
>>> DRM-Master
>>> (see the DocBook documentation). It really doesn't make sense to
>>> create/bind a
>>> DRM-Master object to render-clients. However, a lot of core DRM code
>>> depends on
>>>->master != NULL. Drivers need to take care not to call into those core
>>> modules
>>> if they implement DRIVER_RENDER.
>>> I plan on removing multiple-master-support in the next series. So there
>>> will be
>>> only one global master and each open-file is bound to it. This will make
>>> it very
>>> easy to phase out "drm_master". The planned "modeset" nodes provide a nice
>>> replacement. If anyone knows a **currently used** use-case for
>>> multiple-masters,
>>> please tell me. I couldn't find one that _actually works_.
>>> (SetMaster+DropMaster
>>> will obviously stay functional even with drm_master removed).
>>>
>>>
>>> (series available at: https://github.com/dvdhrm/linux/tree/rnodes)
>>>
>>> Comments welcome!
>>> Cheers
>>> David
>> Hi David,
>>
>> Thanks for this patchset. I am away from my computers for testing but I was
>> wondering if you based your vma rework on Dave's implementation. If so,
>> you may have the same bug that I had with it.
>>
>> I cannot remember the details of the bug, but I could trigger it by
>> rebooting
>> kde around 13 times on radeon. I didn't have this problem with Nouveau.
> It is based on Dave's code, but I rewrote all of it and fixed several
> bugs. For instance, there was a TTM ref-count leak for BOs in TTM core
> and a TTM locking issue. I didn't encounter any bugs so far, but I
> didn't try to restart the xserver 13 times. I will do some more
> stress-tests, but it is quite likely you hit one of those two bugs
> with radeon.

Yeah, the problem I had was related to ref-count and I was trying
to fix the locking too.
>> I am not competent to judge this work but I will try to test it and check
>> with my security tests that I wrote that the problem is indeed solved
>> on nouveau and radeon.
> The changes are actually quite simple. I intentionally kept TTM
> locking as it was before, even though I think we could reduce it now.
> Anyway, I will resend v3 (which now includes tegra and staging) this
> weekend. Hopefully we can get it into linux-next soon.

Very nice! Looking forward to it.

[PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)

[David Herrmann]

Hi

On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres  wrote:
> On 07/07/2013 19:17, David Herrmann wrote:
>>
>> Hi
>>
>> This is v2 of the unified VMA offset manager series. The first draft is
>> available at LWN [1]. This series replaces the VMA offset managers in GEM
>> and
>> TTM with a unified implementation.
>>
>> The first 4 patches contain the new VMA offset manager and are the only
>> patches
>> that I propose for mainline inclusion.
>> Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar
>> patches in i915-next and I will rebase them once it is merged. Ignore
>> them if you're not interested.
>> Patches 9-19 implement mmap access control. Comments are welcome! They are
>> intended for mainline inclusion, too, but probably require some more
>> review
>> rounds. I'd really appreciate if driver authors could comment on the
>> implementation.
>> Patch 20 shows the main motivation behind this whole series: render nodes.
>> It is
>> marked RFC and I will resend once the VMA manager is merged upstream. Feel
>> free
>> to test it.
>>
>> One more note regarding DRM-Master: Render-clients are independent of
>> DRM-Master
>> (see the DocBook documentation). It really doesn't make sense to
>> create/bind a
>> DRM-Master object to render-clients. However, a lot of core DRM code
>> depends on
>>   ->master != NULL. Drivers need to take care not to call into those core
>> modules
>> if they implement DRIVER_RENDER.
>> I plan on removing multiple-master-support in the next series. So there
>> will be
>> only one global master and each open-file is bound to it. This will make
>> it very
>> easy to phase out "drm_master". The planned "modeset" nodes provide a nice
>> replacement. If anyone knows a **currently used** use-case for
>> multiple-masters,
>> please tell me. I couldn't find one that _actually works_.
>> (SetMaster+DropMaster
>> will obviously stay functional even with drm_master removed).
>>
>>
>> (series available at: https://github.com/dvdhrm/linux/tree/rnodes)
>>
>> Comments welcome!
>> Cheers
>> David
>
> Hi David,
>
> Thanks for this patchset. I am away from my computers for testing but I was
> wondering if you based your vma rework on Dave's implementation. If so,
> you may have the same bug that I had with it.
>
> I cannot remember the details of the bug, but I could trigger it by
> rebooting
> kde around 13 times on radeon. I didn't have this problem with Nouveau.

It is based on Dave's code, but I rewrote all of it and fixed several
bugs. For instance, there was a TTM ref-count leak for BOs in TTM core
and a TTM locking issue. I didn't encounter any bugs so far, but I
didn't try to restart the xserver 13 times. I will do some more
stress-tests, but it is quite likely you hit one of those two bugs
with radeon.

> I am not competent to judge this work but I will try to test it and check
> with my security tests that I wrote that the problem is indeed solved
> on nouveau and radeon.

The changes are actually quite simple. I intentionally kept TTM
locking as it was before, even though I think we could reduce it now.
Anyway, I will resend v3 (which now includes tegra and staging) this
weekend. Hopefully we can get it into linux-next soon.

Thanks!
David

> Looking forward to seeing your proposition for the userspace :)
>
> Cheers,
> Martin

[PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)

[Martin Peres]

On 07/07/2013 19:17, David Herrmann wrote:
> Hi
>
> This is v2 of the unified VMA offset manager series. The first draft is
> available at LWN [1]. This series replaces the VMA offset managers in GEM and
> TTM with a unified implementation.
>
> The first 4 patches contain the new VMA offset manager and are the only 
> patches
> that I propose for mainline inclusion.
> Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar
> patches in i915-next and I will rebase them once it is merged. Ignore
> them if you're not interested.
> Patches 9-19 implement mmap access control. Comments are welcome! They are
> intended for mainline inclusion, too, but probably require some more review
> rounds. I'd really appreciate if driver authors could comment on the
> implementation.
> Patch 20 shows the main motivation behind this whole series: render nodes. It 
> is
> marked RFC and I will resend once the VMA manager is merged upstream. Feel 
> free
> to test it.
>
> One more note regarding DRM-Master: Render-clients are independent of 
> DRM-Master
> (see the DocBook documentation). It really doesn't make sense to create/bind a
> DRM-Master object to render-clients. However, a lot of core DRM code depends 
> on
>   ->master != NULL. Drivers need to take care not to call into those core 
> modules
> if they implement DRIVER_RENDER.
> I plan on removing multiple-master-support in the next series. So there will 
> be
> only one global master and each open-file is bound to it. This will make it 
> very
> easy to phase out "drm_master". The planned "modeset" nodes provide a nice
> replacement. If anyone knows a **currently used** use-case for 
> multiple-masters,
> please tell me. I couldn't find one that _actually works_. 
> (SetMaster+DropMaster
> will obviously stay functional even with drm_master removed).
>
>
> (series available at: https://github.com/dvdhrm/linux/tree/rnodes)
>
> Comments welcome!
> Cheers
> David
Hi David,

Thanks for this patchset. I am away from my computers for testing but I was
wondering if you based your vma rework on Dave's implementation. If so,
you may have the same bug that I had with it.

I cannot remember the details of the bug, but I could trigger it by 
rebooting
kde around 13 times on radeon. I didn't have this problem with Nouveau.

I am not competent to judge this work but I will try to test it and check
with my security tests that I wrote that the problem is indeed solved
on nouveau and radeon.

Looking forward to seeing your proposition for the userspace :)

Cheers,
Martin

[PATCH 1/2] drm/gem: simplify object initialization

[Patrik Jakobsson]

On Thu, Jul 11, 2013 at 11:56 AM, David Herrmann  
wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
>
> Cc: Patrik Jakobsson 
> Signed-off-by: David Herrmann 
> ---
>  drivers/gpu/drm/drm_gem.c  | 20 
>  drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
>  drivers/gpu/drm/gma500/gem.c   |  7 ---
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
>  drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
>  drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
>  include/drm/drmP.h |  4 ++--
>  7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
>  int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
>  {
> -   BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> +   struct file *filp;
>
> -   obj->dev = dev;
> -   obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> -   if (IS_ERR(obj->filp))
> -   return PTR_ERR(obj->filp);
> +   filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> +   if (IS_ERR(filp))
> +   return PTR_ERR(filp);
>
> -   kref_init(>refcount);
> -   atomic_set(>handle_count, 0);
> -   obj->size = size;
> +   drm_gem_private_object_init(dev, obj, size);
> +   obj->filp = filp;
>
> return 0;
>  }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
>   * no GEM provided backing store. Instead the caller is responsible for
>   * backing the object and handling it.
>   */
> -int drm_gem_private_object_init(struct drm_device *dev,
> -   struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> +struct drm_gem_object *obj, size_t size)
>  {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(>refcount);
> atomic_set(>handle_count, 0);
> obj->size = size;
> -
> -   return 0;
>  }
>  EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> -   if (drm_gem_private_object_init(dev,
> -   >gem, aligned_size) == 0)
> -   return backing;
> -   psb_gtt_free_range(dev, backing);
> +   drm_gem_private_object_init(dev, >gem, aligned_size);
> +   return backing;
> }
> return NULL;
>  }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> -   if (drm_gem_private_object_init(dev, >gem, size) != 0)
> -   goto free_gtt;
> +
> +   drm_gem_private_object_init(dev, >gem, size);
> if (drm_gem_handle_create(file, >gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> +   drm_gem_object_release(>gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
> drm_device *dev,
> goto fail_detach;
> }
>
> -   ret = drm_gem_private_object_init(dev, >base, dma_buf->size);
> -   if (ret) {
> -   

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

--- Comment #22 from Christian K?nig  ---
(In reply to comment #21)
> I got this compile warning: 
> 
> /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function
> ?radeon_uvd_fini?:
> /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning:
> ?return? with a value, in function returning void [enabled by default]
>return 0;
>^

Just a stupid typo, going to fix that before I send it out to the list.

> Haven't had a chance to test just yet.  Will report back as soon as possible.

That would be greate, cause it's actually a quite serious bug.

I'm currently also locking into the other stability issues with 3.10, but can't
(yet) say if it's radeons fault or not.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d24b3874/attachment.html>

[PATCH v2 02/20] drm/gem: convert to new unified vma manager

[David Herrmann]

Hi

On Sun, Jul 7, 2013 at 7:17 PM, David Herrmann  wrote:
> Use the new vma manager instead of the old hashtable. Also convert all
> drivers to use the new convenience helpers. This drops all the
> (map_list.hash.key << PAGE_SHIFT) non-sense.
>
> Locking and access-management is exactly the same as before with an
> additional lock inside of the vma-manager, which strictly wouldn't be
> needed for gem.
>
> v2:
>  - rebase on drm-next
>  - init nodes via drm_vma_node_reset() in drm_gem.c

I missed the tegra driver and any staging driver. I will fix that in
v3 and reduce the series to a minimum.

Regards
David

> Signed-off-by: David Herrmann 
> ---
>  drivers/gpu/drm/drm_gem.c  | 90 
> ++
>  drivers/gpu/drm/drm_gem_cma_helper.c   |  9 +--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c|  7 ++-
>  drivers/gpu/drm/gma500/gem.c   |  8 +--
>  drivers/gpu/drm/i915/i915_gem.c|  9 +--
>  drivers/gpu/drm/omapdrm/omap_gem.c | 11 ++--
>  drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 49 +---
>  drivers/gpu/drm/udl/udl_gem.c  |  6 +-
>  include/drm/drmP.h |  7 +--
>  include/drm/drm_vma_manager.h  |  1 -
>  include/uapi/drm/drm.h |  2 +-
>  11 files changed, 49 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..b5db89b 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /** @file drm_gem.c
>   *
> @@ -102,14 +103,9 @@ drm_gem_init(struct drm_device *dev)
> }
>
> dev->mm_private = mm;
> -
> -   if (drm_ht_create(>offset_hash, 12)) {
> -   kfree(mm);
> -   return -ENOMEM;
> -   }
> -
> -   drm_mm_init(>offset_manager, DRM_FILE_PAGE_OFFSET_START,
> -   DRM_FILE_PAGE_OFFSET_SIZE);
> +   drm_vma_offset_manager_init(>vma_manager,
> +   DRM_FILE_PAGE_OFFSET_START,
> +   DRM_FILE_PAGE_OFFSET_SIZE);
>
> return 0;
>  }
> @@ -119,8 +115,7 @@ drm_gem_destroy(struct drm_device *dev)
>  {
> struct drm_gem_mm *mm = dev->mm_private;
>
> -   drm_mm_takedown(>offset_manager);
> -   drm_ht_remove(>offset_hash);
> +   drm_vma_offset_manager_destroy(>vma_manager);
> kfree(mm);
> dev->mm_private = NULL;
>  }
> @@ -141,6 +136,7 @@ int drm_gem_object_init(struct drm_device *dev,
>
> kref_init(>refcount);
> atomic_set(>handle_count, 0);
> +   drm_vma_node_reset(>vma_node);
> obj->size = size;
>
> return 0;
> @@ -162,6 +158,7 @@ int drm_gem_private_object_init(struct drm_device *dev,
>
> kref_init(>refcount);
> atomic_set(>handle_count, 0);
> +   drm_vma_node_reset(>vma_node);
> obj->size = size;
>
> return 0;
> @@ -306,12 +303,8 @@ drm_gem_free_mmap_offset(struct drm_gem_object *obj)
>  {
> struct drm_device *dev = obj->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> -   struct drm_map_list *list = >map_list;
>
> -   drm_ht_remove_item(>offset_hash, >hash);
> -   drm_mm_put_block(list->file_offset_node);
> -   kfree(list->map);
> -   list->map = NULL;
> +   drm_vma_offset_remove(>vma_manager, >vma_node);
>  }
>  EXPORT_SYMBOL(drm_gem_free_mmap_offset);
>
> @@ -331,54 +324,9 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj)
>  {
> struct drm_device *dev = obj->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> -   struct drm_map_list *list;
> -   struct drm_local_map *map;
> -   int ret;
> -
> -   /* Set the object up for mmap'ing */
> -   list = >map_list;
> -   list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
> -   if (!list->map)
> -   return -ENOMEM;
> -
> -   map = list->map;
> -   map->type = _DRM_GEM;
> -   map->size = obj->size;
> -   map->handle = obj;
> -
> -   /* Get a DRM GEM mmap offset allocated... */
> -   list->file_offset_node = drm_mm_search_free(>offset_manager,
> -   obj->size / PAGE_SIZE, 0, false);
> -
> -   if (!list->file_offset_node) {
> -   DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
> -   ret = -ENOSPC;
> -   goto out_free_list;
> -   }
>
> -   list->file_offset_node = drm_mm_get_block(list->file_offset_node,
> -   obj->size / PAGE_SIZE, 0);
> -   if (!list->file_offset_node) {
> -   ret = -ENOMEM;
> -   goto out_free_list;
> -   }
> -
> -   list->hash.key = list->file_offset_node->start;
> -   ret = drm_ht_insert_item(>offset_hash, >hash);
> -   if (ret) {
> -   DRM_ERROR("failed to add to map hash\n");
> -   goto out_free_mm;
> -   

[PATCH 1/2] drm/gem: simplify object initialization

[Daniel Vetter]

On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
> 
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
> 
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.

Generally commmit messages that have too many "also do foo" paragraphs
tack on scream for a patch split up ;-) But the diff here is little enough
that it's imo still ok. So for both patches in this series:

Reviewed-by: Daniel Vetter 

> 
> Cc: Patrik Jakobsson 
> Signed-off-by: David Herrmann 
> ---
>  drivers/gpu/drm/drm_gem.c  | 20 
>  drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
>  drivers/gpu/drm/gma500/gem.c   |  7 ---
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
>  drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
>  drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
>  include/drm/drmP.h |  4 ++--
>  7 files changed, 20 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
>  int drm_gem_object_init(struct drm_device *dev,
>   struct drm_gem_object *obj, size_t size)
>  {
> - BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> + struct file *filp;
>  
> - obj->dev = dev;
> - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> - if (IS_ERR(obj->filp))
> - return PTR_ERR(obj->filp);
> + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> + if (IS_ERR(filp))
> + return PTR_ERR(filp);
>  
> - kref_init(>refcount);
> - atomic_set(>handle_count, 0);
> - obj->size = size;
> + drm_gem_private_object_init(dev, obj, size);
> + obj->filp = filp;
>  
>   return 0;
>  }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
>   * no GEM provided backing store. Instead the caller is responsible for
>   * backing the object and handling it.
>   */
> -int drm_gem_private_object_init(struct drm_device *dev,
> - struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> +  struct drm_gem_object *obj, size_t size)
>  {
>   BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>  
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
>   kref_init(>refcount);
>   atomic_set(>handle_count, 0);
>   obj->size = size;
> -
> - return 0;
>  }
>  EXPORT_SYMBOL(drm_gem_private_object_init);
>  
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
> *dev, int aligned_size)
>   /* Begin by trying to use stolen memory backing */
>   backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
>   if (backing) {
> - if (drm_gem_private_object_init(dev,
> - >gem, aligned_size) == 0)
> - return backing;
> - psb_gtt_free_range(dev, backing);
> + drm_gem_private_object_init(dev, >gem, aligned_size);
> + return backing;
>   }
>   return NULL;
>  }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
> struct drm_device *dev,
>   struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
>   if (gtt == NULL)
>   return -ENOMEM;
> - if (drm_gem_private_object_init(dev, >gem, size) != 0)
> - goto free_gtt;
> +
> + drm_gem_private_object_init(dev, >gem, size);
>   if (drm_gem_handle_create(file, >gem, handle) == 0)
>   return 0;
> -free_gtt:
> +
> + drm_gem_object_release(>gem);
>   psb_gtt_free_range(dev, gtt);
>   return -ENOMEM;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
> drm_device 

[PATCH] drm: don't call ->firstopen for KMS drivers

[Daniel Vetter]

On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
>> It has way too much potential for driver writers to do stupid things
>> like delayed hw setup because the load sequence is somehow racy (e.g.
>> the imx driver in staging). So don't call it for modesetting drivers,
>> which reduces the complexity of the drm core -> driver interface a
>> notch.
>>
>> v2: Don't forget to update DocBook.
>>
>> Cc: Laurent Pinchart 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  Documentation/DocBook/drm.tmpl | 2 ++
>>  drivers/gpu/drm/drm_fops.c | 3 ++-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
>> index 4d54ac8..0e8a5a3 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
>> drm_file *); 
>>  The firstopen method is called by the DRM
>> core when an application opens a device that has no other opened file
>> handle.
>> + Not that this callback is only called for legacy ums drm drivers, not
>> + for drm drivers that implement modesetting in the kernel.
>>   Similarly the lastclose method is called when
>>   the last application holding a file handle opened on the device closes
>>   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
>
> What about

So if you think we should go overboard I guess it'd be useful to
explain what KMS drivers should and shouldn't do in lastclose:
- Delayed gpu switching with vga switcheroo.
- Restoring of the fbcon, as long as the core is still a bit deficient
in getting rid of mouse cursors and stupid sprite setups when X dies
untimely and leaves dirt behind. Eventually we should be able to get
rid of this though and rely on the magic sysrq to get out of graphics
mode and restore fbcon fully.
- Nothing else, ever, especially resource cleanups.

Can you maybe add a sentence or two to your proposed update for about
this? UMS drivers tend to do a lot of nefarious stuff in lastclose, so
stressing the difference would be good.

Otherwise I like your doc update much more than mine ;-)
-Daniel

>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7d1278e..afa8d40 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct 
> drm_file *);
>
>
>  The firstopen method is called by the DRM 
> core
> -   when an application opens a device that has no other opened file 
> handle.
> -   Similarly the lastclose method is called when
> -   the last application holding a file handle opened on the device closes
> -   it. Both methods are mostly used for UMS (User Mode Setting) drivers 
> to
> -   acquire and release device resources which should be done in the
> -   load and unload
> -   methods for KMS drivers.
> +   for legacy UMS (User Mode Setting) drivers only when an application
> +   opens a device that has no other opened file handle. UMS drivers can
> +   implement it to acquire device resources. KMS drivers can't use the
> +   method and must acquire resources in the load
> +   method instead.
>
>
> -Note that the lastclose method is also 
> called
> -   at module unload time or, for hot-pluggable devices, when the device 
> is
> -   unplugged. The firstopen and
> +   Similarly the lastclose method is called when
> +   the last application holding a file handle opened on the device closes
> +   it, for both UMS and KMS drivers. Additionally, the method is also
> +   called at module unload time or, for hot-pluggable devices, when the
> +   device is unplugged. The firstopen and
> lastclose calls can thus be unbalanced.
>
>
>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index 57e3014..fcde7d4 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
>>   int i;
>>   int ret;
>>
>> - if (dev->driver->firstopen) {
>> + if (dev->driver->firstopen &&
>> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
>>   ret = dev->driver->firstopen(dev);
>>   if (ret != 0)
>>   return ret;
>
> --
> Regards,
>
> Laurent Pinchart



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/2] drm/pci: remove useles #if 1

[David Herrmann]

These don't make any sense, really..

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_pci.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 80c0b2b..a7b46ff 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -52,10 +52,8 @@
 drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t 
align)
 {
drm_dma_handle_t *dmah;
-#if 1
unsigned long addr;
size_t sz;
-#endif

/* pci_alloc_consistent only guarantees alignment to the smallest
 * PAGE_SIZE order which is greater than or equal to the requested size.
@@ -97,10 +95,8 @@ EXPORT_SYMBOL(drm_pci_alloc);
  */
 void __drm_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
 {
-#if 1
unsigned long addr;
size_t sz;
-#endif

if (dmah->vaddr) {
/* XXX - Is virt_to_page() legal for consistent mem? */
-- 
1.8.3.2

[PATCH 1/2] drm/gem: simplify object initialization

[David Herrmann]

drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.

Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to keep it
around. This simplifies code paths in drivers, too.

Last but not least, fix gma500 to call drm_gem_object_release() before
freeing objects that were allocated via drm_gem_private_object_init().
That isn't actually necessary for now, but might be in the future.

Cc: Patrik Jakobsson 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_gem.c  | 20 
 drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
 drivers/gpu/drm/gma500/gem.c   |  7 ---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
 drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
 drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
 include/drm/drmP.h |  4 ++--
 7 files changed, 20 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 603f256..1ad9e7e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
 int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
 {
-   BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+   struct file *filp;

-   obj->dev = dev;
-   obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
-   if (IS_ERR(obj->filp))
-   return PTR_ERR(obj->filp);
+   filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
+   if (IS_ERR(filp))
+   return PTR_ERR(filp);

-   kref_init(>refcount);
-   atomic_set(>handle_count, 0);
-   obj->size = size;
+   drm_gem_private_object_init(dev, obj, size);
+   obj->filp = filp;

return 0;
 }
@@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
  * no GEM provided backing store. Instead the caller is responsible for
  * backing the object and handling it.
  */
-int drm_gem_private_object_init(struct drm_device *dev,
-   struct drm_gem_object *obj, size_t size)
+void drm_gem_private_object_init(struct drm_device *dev,
+struct drm_gem_object *obj, size_t size)
 {
BUG_ON((size & (PAGE_SIZE - 1)) != 0);

@@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
kref_init(>refcount);
atomic_set(>handle_count, 0);
obj->size = size;
-
-   return 0;
 }
 EXPORT_SYMBOL(drm_gem_private_object_init);

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 8b1b6d9..362dd2a 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
*dev, int aligned_size)
/* Begin by trying to use stolen memory backing */
backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
if (backing) {
-   if (drm_gem_private_object_init(dev,
-   >gem, aligned_size) == 0)
-   return backing;
-   psb_gtt_free_range(dev, backing);
+   drm_gem_private_object_init(dev, >gem, aligned_size);
+   return backing;
}
return NULL;
 }
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index eefd6cc..fe1d332 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
struct drm_device *dev,
struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
if (gtt == NULL)
return -ENOMEM;
-   if (drm_gem_private_object_init(dev, >gem, size) != 0)
-   goto free_gtt;
+
+   drm_gem_private_object_init(dev, >gem, size);
if (drm_gem_handle_create(file, >gem, handle) == 0)
return 0;
-free_gtt:
+
+   drm_gem_object_release(>gem);
psb_gtt_free_range(dev, gtt);
return -ENOMEM;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index dc53a52..f2e185c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
goto fail_detach;
}

-   ret = drm_gem_private_object_init(dev, >base, dma_buf->size);
-   if (ret) {
-   i915_gem_object_free(obj);
-   goto fail_detach;
-   }
-
+   drm_gem_private_object_init(dev, >base, dma_buf->size);
i915_gem_object_init(obj, _gem_object_dmabuf_ops);
obj->base.import_attach = attach;

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66450

--- Comment #7 from Christian K?nig  ---
Created attachment 82331
  --> https://bugs.freedesktop.org/attachment.cgi?id=82331=edit
Possible fix v2

Update patch, should work better this time.

But please note that shader based decoding is far away from beeing perfect
either.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/f8e790a2/attachment.html>

[PATCH 1/2] drm/gem: simplify object initialization

[Chris Wilson]

On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
> 
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
> 
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
> 
> Cc: Patrik Jakobsson 
> Signed-off-by: David Herrmann 

You should also CC any driver maintainers that the patch touches. They
should be acking it at the very least.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 66731] texture issues in xonotic with llvm+sb and offset mapping

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66731

--- Comment #2 from Stefano Teso  ---
Thanks for the quick response.

I just wanted to note that the glitch is still there with llvm 3.4 trunk.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/38e55943/attachment.html>

[PATCH 00/39] clean out drm cruft and hide it better for kms drivers

[Alex Deucher]

On Wed, Jul 10, 2013 at 8:11 AM, Daniel Vetter  
wrote:
> Hi all,
>
> I've figured that it's again time for a bit of (late) drm spring cleanup. This
> series here consists of a pile of "rip old stuff out" patches interleaved with
> "disable old cruft for kms drivers and hide it better".
>
> Comments, flames and review highly welcome. I'd be especially happy if the arm
> guys could check whether I haven't badly broken their drivers - 
> compile-testing
> arm is a pita, so I haven't yet done that.
>
> There's a few driver-wide patches included, but the more invasive ones (i.e.
> changing more than the drm driver vtable) are split out per-driver for easier
> merging. If no one screams my plan is to rebase this pile on top of -rc1, give
> it some more testing (check arm, ugh) and then send a pull request to Dave.
> That should reduce interference with ongoing driver work as much as possible I
> hope.
>
> My drm cruft todo list still has a pile of ideas, but I've figured I need to
> stop now for 3.12. For those interested further cleanups could include:
>
> - setversion/set_busid: All drm core version 1.1 is legacy cruft, kms drivers
>   should never run in this mode. We could clean up the setversion ioclt (and
>   move the drm core version handling into a legacy function) and set up the 
> bus
>   id unconditionally at driver load time.
>
> - There's a few more legacy ioctls/subsystems that could be blocked out for 
> kms
>   drivers (but the required git history digging tends to be tedious). Also I
>   think we could more aggressively move legacy cruft setup/teardown code
>   out-of-line from the main code by extracting it into drm_legacy_ functions
>   (like this series here already does for the context and dma stuff).
>
> - I think creating a drm_internal.h header for functions not exported to 
> drivers
>   would be useful. That way we could move all the legacy functions out of 
> drmP.h
>   (which are a lot of them), which should make it much clearer what the real 
> drm
>   driver interface actually is.
>
> - drm_os_linux.h should just die in fire.
>
> - There's a pile of needless indirection around our agp handling, we duplicate
>   the agp core's CONFIG_AGP=n no-oping function handling in large parts, among
>   other stuff.
>
> - The drm coherent dma alloc helpers could get ripped out, at least for kms
>   drivers. For ums drivers there's some funny cases where this mapping is
>   exchanged with userspace for e.g. register access. In a least one case
>   (i810.ko) userspace even sets up that mapping, which allows it to crash the
>   kernel at will (since those maps aren't refcounted). Maybe we need to shovel
>   those interfaces into a drm_legacy.ko module to keep them around but make 
> sure
>   that no new driver even thinks about using them.
>
> - There's also the matter of the vblank support code, imo that should be split
>   int a ums and a kms part. That'd would allow us to use struct drm_crtc * in
>   interfaces and proper locking (by grabbing crtc->mutex to exclude races with
>   dpms/modesets).
>
> If anyone wants to dig around in those areas please poke me.
>

For the series:

Reviewed-by: Alex Deucher 

> Cheers, Daniel
>
> Daniel Vetter (39):
>   drm: remove drm_modctx ioctl and use drm_noop instead
>   drm: kill dev->context_wait
>   drm: remove dev->last_switch
>   drm: kill dev->interrupt_flag and dev->dma_flag
>   drm: kill dev->ctx_start and dev->lck_start
>   drm/radoen: kill radeon_dma_ioctl_kms
>   drm: kill dev->buf_readers and dev->buf_writers
>   drm: remove redundant clears from drm_setup
>   drm/omap: kill firstopen callback
>   drm/radeon: kill firstopen callback for kms driver
>   drm/imx: kill firstopen callback
>   drm/vmwgfx: remove ->firstopen callback
>   drm: don't call ->firstopen for KMS drivers
>   drm: kill dev->driver->set_version
>   drm/radeon: remove DRIVER_HAS_DMA/SG/PCI_DMA from the kms driver
>   drm: fold in drm_sg_alloc into the ioctl
>   drm: hide legacy sg cleanup better from common code
>   drm: disallow legacy sg ioctls for modesetting drivers
>   drm: mark dma setup/teardown as legacy systems
>   drm/nouveau: drop DRIVER_PCI_DMA and DRIVER_SG
>   drm: disallow legacy dma ioctls for modesetting drivers
>   drm: move drm_getsarea into drm_bufs.c
>   drm/bufs: s/drm_order/order_base_2/
>   drm/r128: s/drm_order/order_base_2/
>   drm/radeon: s/drm_order/order_base_2/
>   drm: remove drm_order
>   drm: mark context support as a legacy subsystem
>   drm/vmwgfx: remove redundant clearing of driver->dma_quiescent
>   drm: remove FASYNC support
>   drm: rip out DRIVER_FB_DMA and related code
>   drm: rip out a few unused DRIVER flags
>   drm: remove a bunch of unused #defines from drmP.h
>   drm: rip out drm_core_has_MTRR checks
>   drm: remove the dma_ioctl special-case
>   drm/memory: don't export agp helpers
>   drm: hollow-out GET_CLIENT ioctl
>   drm: no-op out GET_STATS ioctl
>   drm: fix locking in gem debugfs/procfs file
>   drm: remove procfs code, 

Questions about TTM buffer object maping

[Jerome Glisse]

On Thu, Jul 11, 2013 at 2:24 AM, Daniel Vetter  wrote:
> On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
>> On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron
>>  wrote:
>> > Hello,
>> >
>> > I'm trying to understand how TTM buffer object mapping works on Linux, to
>> > make this behave properly on FreeBSD.
>> >
>> > Here's what I think I understand:
>> >
>> > When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's 
>> > a
>> > page fault, the page is looked up and inserted in the VMA using
>> > vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is
>> > called, which drops a reference. When the last reference is dropped, the
>> > buffer object is destroyed.
>> >
>> > What's still not clear to me is how munmap() works here. After talking 
>> > about
>> > this on IRC with some people, I think that unmap_mapping_range() (called by
>> > ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from
>> > userland. Is that true?
>>
>> Yes that's true.
>
> Afaik unmap_mapping_range only kills the ptes and doesn't remove the vma.
> So not equivalent to a munmap from userspace. It simply allows us to
> intercept the next access in the page fault handler and move the buffer
> back into place.
> -Daniel

Yes, i was talking from a page point of view, ie page no longer have
mapping and can
be free.

Cheers,
Jerome

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 10 July 2013 16:48:45 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the helper).
> 
> Only the grabbing of the underlying page array is anything we need to
> be concerned about, and either those pages are pinned independently,
> or we're screwed no matter what.
> 
> And indeed, nouveau/radeon pin the backing storage in their
> attach/detach functions.
> 
> Since I've created this patch cma prime support for dma_buf was added.
> drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates
> the sg table with dma_get_sgtable. It doesn't touch any gem object
> state otherwise. So the cma helpers also look safe.
> 
> The only thing we might claim it does is prevent concurrent mapping of
> dma_buf attachments. But a) that's not allowed and b) the current code
> is racy already since it checks whether the sg mapping exists _before_
> grabbing the lock.
> 
> So the dev->struct_mutex locking here does absolutely nothing useful,
> but only distracts. Remove it.
> 
> This should also help Maarten's work to eventually pin the backing
> storage more dynamically by preventing locking inversions around
> dev->struct_mutex.
> 
> v2: Add analysis for recently added cma helper prime code.
> 
> Cc: Laurent Pinchart 
> Cc: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_prime.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 85e450e..64a99b3 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -167,8 +167,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach, if (WARN_ON(prime_attach->dir != DMA_NONE))
>   return ERR_PTR(-EBUSY);
> 
> - mutex_lock(>dev->struct_mutex);
> -
>   sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
> 
>   if (!IS_ERR(sgt)) {
> @@ -182,7 +180,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach, }
>   }
> 
> - mutex_unlock(>dev->struct_mutex);
>   return sgt;
>  }
-- 
Regards,

Laurent Pinchart

Radeon HD 6310 (AMD Wrestler): [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[Christian König]

Am 11.07.2013 09:41, schrieb Paul Menzel:
> Dear Linux folks,
>
>
> using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged
> and built with `make deb-pkg`, it failed the last boot.
>
>  [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
>
> The strange thing is that it worked the last time I tried with the same
> Linux kernel image as I posted to the list [1]. I just booted an old
> 3.2.46 distribution Linux in between. (And it looked like the
> modesetting did not work when doing so. But I did not look further into
> it.)

The most likely problem is that you don't have the current firmware 
installed, beside the new UVD firmware you also need to update the RLC 
firmware.

Christian.

>
>  $ uname -a
>  Linux myhostname 3.10.0+ #105 SMP Sat Jul 6 13:33:47 CEST 2013 i686 
> GNU/Linux
>  $ lspci -s 01.0
>  00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. 
> [AMD/ATI] Wrestler [Radeon HD 6310]
>  $ md5sum /lib/firmware/3.10.0+/radeon/SUMO_uvd.bin
>  51d9e0e2247c313c5bfc8fa7bb5b213d  
> /lib/firmware/3.10.0+/radeon/SUMO_uvd.bin
>  $ cut -d " " -f 6- /var/log/kern.log
>  [...]
>  [0.152534] calling  trace_init_flags_sys_exit+0x0/0xd @ 1
>  [0.152540] initcall trace_init_flags_sys_exit+0x0/0xd returned 0 
> after 0 usecs
>  [0.152545] calling  trace_init_flags_sys_enter+0x0/0xd @ 1
>  [0.152550] initcall trace_init_flags_sys_enter+0x0/0xd returned 
> 0 after 0 usecs
>  [0.152555] calling  init_hw_perf_events+0x0/0x47e @ 1
>  [0.152557] Performance Events: AMD PMU driver.
>  [0.152565] ... version:0
>  [0.152567] ... bit width:  48
>  [0.152569] ... generic registers:  4
>  [0.152572] ... value mask: 
>  [0.152575] ... max period: 7fff
>  [0.152577] ... fixed-purpose events:   0
>  [0.152580] ... event mask: 000f
>  [0.152597] initcall init_hw_perf_events+0x0/0x47e returned 0 
> after 0 usecs
>  [0.152603] calling  register_trigger_all_cpu_backtrace+0x0/0xf @ 
> 1
>  [0.152609] initcall register_trigger_all_cpu_backtrace+0x0/0xf 
> returned 0 after 0 usecs
>  [0.152615] calling  spawn_ksoftirqd+0x0/0x1d @ 1
>  [0.152657] initcall spawn_ksoftirqd+0x0/0x1d returned 0 after 0 
> usecs
>  [0.152662] calling  init_workqueues+0x0/0x289 @ 1
>  [0.152800] initcall init_workqueues+0x0/0x289 returned 0 after 0 
> usecs
>  [0.152805] calling  check_cpu_stall_init+0x0/0x12 @ 1
>  [0.152810] initcall check_cpu_stall_init+0x0/0x12 returned 0 
> after 0 usecs
>  [0.152814] calling  migration_init+0x0/0x55 @ 1
>  [0.152820] initcall migration_init+0x0/0x55 returned 0 after 0 
> usecs
>  [0.152826] calling  cpu_stop_init+0x0/0x57 @ 1
>  [0.152863] initcall cpu_stop_init+0x0/0x57 returned 0 after 0 
> usecs
>  [0.152868] calling  rcu_register_oom_notifier+0x0/0xd @ 1
>  [0.152874] initcall rcu_register_oom_notifier+0x0/0xd returned 0 
> after 0 usecs
>  [0.152879] calling  rcu_scheduler_really_started+0x0/0xd @ 1
>  [0.152883] initcall rcu_scheduler_really_started+0x0/0xd 
> returned 0 after 0 usecs
>  [0.152888] calling  rcu_spawn_gp_kthread+0x0/0x6b @ 1
>  [0.152936] initcall rcu_spawn_gp_kthread+0x0/0x6b returned 0 
> after 0 usecs
>  [0.152941] calling  relay_init+0x0/0xd @ 1
>  [0.152946] initcall relay_init+0x0/0xd returned 0 after 0 usecs
>  [0.152950] calling  tracer_alloc_buffers+0x0/0x18b @ 1
>  [0.153030] initcall tracer_alloc_buffers+0x0/0x18b returned 0 
> after 0 usecs
>  [0.153034] calling  init_events+0x0/0x57 @ 1
>  [0.153041] initcall init_events+0x0/0x57 returned 0 after 0 usecs
>  [0.153046] calling  init_trace_printk+0x0/0xa @ 1
>  [0.153051] initcall init_trace_printk+0x0/0xa returned 0 after 0 
> usecs
>  [0.153055] calling  event_trace_memsetup+0x0/0x4a @ 1
>  [0.153067] initcall event_trace_memsetup+0x0/0x4a returned 0 
> after 0 usecs
>  [0.153158] NMI watchdog: enabled on all CPUs, permanently 
> consumes one hw-PMU counter.
>  [0.153361] CPU 1 irqstacks, hard=f40ae000 soft=f40b
>  [0.153365] smpboot: Booting Node   0, Processors  #1 OK
>  [0.163398] Initializing CPU#1
>  [0.166591] Brought up 2 CPUs
>  [0.166596] smpboot: Total of 2 processors activated (6399.62 
> BogoMIPS)
>  [0.168897] devtmpfs: initialized
>  [0.169277] calling  ipc_ns_init+0x0/0xd @ 1
>  [0.169284] 

[PATCH] drm: don't call ->firstopen for KMS drivers

[Laurent Pinchart]

Hi Daniel,

On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces the complexity of the drm core -> driver interface a
> notch.
> 
> v2: Don't forget to update DocBook.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/drm.tmpl | 2 ++
>  drivers/gpu/drm/drm_fops.c | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..0e8a5a3 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
> drm_file *); 
>  The firstopen method is called by the DRM
> core when an application opens a device that has no other opened file
> handle.
> + Not that this callback is only called for legacy ums drm drivers, not
> + for drm drivers that implement modesetting in the kernel.
>   Similarly the lastclose method is called when
>   the last application holding a file handle opened on the device closes
>   it. Both methods are mostly used for UMS (User Mode Setting) drivers to

What about

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7d1278e..afa8d40 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);
   
   
 The firstopen method is called by the DRM core
-   when an application opens a device that has no other opened file handle.
-   Similarly the lastclose method is called when
-   the last application holding a file handle opened on the device closes
-   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
-   acquire and release device resources which should be done in the
-   load and unload
-   methods for KMS drivers.
+   for legacy UMS (User Mode Setting) drivers only when an application
+   opens a device that has no other opened file handle. UMS drivers can
+   implement it to acquire device resources. KMS drivers can't use the
+   method and must acquire resources in the load
+   method instead.
   
   
-Note that the lastclose method is also called
-   at module unload time or, for hot-pluggable devices, when the device is
-   unplugged. The firstopen and
+   Similarly the lastclose method is called when
+   the last application holding a file handle opened on the device closes
+   it, for both UMS and KMS drivers. Additionally, the method is also
+   called at module unload time or, for hot-pluggable devices, when the
+   device is unplugged. The firstopen and
lastclose calls can thus be unbalanced.
   
   

> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 57e3014..fcde7d4 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
>   int i;
>   int ret;
> 
> - if (dev->driver->firstopen) {
> + if (dev->driver->firstopen &&
> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
>   ret = dev->driver->firstopen(dev);
>   if (ret != 0)
>   return ret;

-- 
Regards,

Laurent Pinchart

[Bug 66805] [radeonsi] half life 2 base games are segfaulting

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66805

--- Comment #2 from Laurent carlier  ---
Created attachment 82327
  --> https://bugs.freedesktop.org/attachment.cgi?id=82327=edit
shader dump from portal with RADEON_DUMP_SHADERS=1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/5a7a6ce4/attachment-0001.html>

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

--- Comment #21 from Austin Lund  ---
(In reply to comment #20)
> Created attachment 82325 [details] [review]
> Possible fix.
> 
> I was able to reproduce the problem, and this patch (only a slightly
> modified version of the old one) seems to fix it for me.
> 
> Please retest and provide new dmesg logs (as far as that is possible).
> 
> Also please try it a couple of times, cause at least on my test system
> suspend/resume on 3.10 seems to be a bit unstable (even without the radeon
> driver).

I got this compile warning: 

/home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function
?radeon_uvd_fini?:
/home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning:
?return? with a value, in function returning void [enabled by default]
   return 0;
   ^

Haven't had a chance to test just yet.  Will report back as soon as possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/ed0c8033/attachment.html>

Radeon HD 6310 (AMD Wrestler): [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[Paul Menzel]

Dear Linux folks,


using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged
and built with `make deb-pkg`, it failed the last boot.

[drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

The strange thing is that it worked the last time I tried with the same
Linux kernel image as I posted to the list [1]. I just booted an old
3.2.46 distribution Linux in between. (And it looked like the
modesetting did not work when doing so. But I did not look further into
it.)

$ uname -a
Linux myhostname 3.10.0+ #105 SMP Sat Jul 6 13:33:47 CEST 2013 i686 
GNU/Linux
$ lspci -s 01.0
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Wrestler [Radeon HD 6310]
$ md5sum /lib/firmware/3.10.0+/radeon/SUMO_uvd.bin
51d9e0e2247c313c5bfc8fa7bb5b213d  
/lib/firmware/3.10.0+/radeon/SUMO_uvd.bin
$ cut -d " " -f 6- /var/log/kern.log
[?]
[0.152534] calling  trace_init_flags_sys_exit+0x0/0xd @ 1
[0.152540] initcall trace_init_flags_sys_exit+0x0/0xd returned 0 
after 0 usecs
[0.152545] calling  trace_init_flags_sys_enter+0x0/0xd @ 1
[0.152550] initcall trace_init_flags_sys_enter+0x0/0xd returned 0 
after 0 usecs
[0.152555] calling  init_hw_perf_events+0x0/0x47e @ 1
[0.152557] Performance Events: AMD PMU driver.
[0.152565] ... version:0
[0.152567] ... bit width:  48
[0.152569] ... generic registers:  4
[0.152572] ... value mask: 
[0.152575] ... max period: 7fff
[0.152577] ... fixed-purpose events:   0
[0.152580] ... event mask: 000f
[0.152597] initcall init_hw_perf_events+0x0/0x47e returned 0 after 
0 usecs
[0.152603] calling  register_trigger_all_cpu_backtrace+0x0/0xf @ 1
[0.152609] initcall register_trigger_all_cpu_backtrace+0x0/0xf 
returned 0 after 0 usecs
[0.152615] calling  spawn_ksoftirqd+0x0/0x1d @ 1
[0.152657] initcall spawn_ksoftirqd+0x0/0x1d returned 0 after 0 
usecs
[0.152662] calling  init_workqueues+0x0/0x289 @ 1
[0.152800] initcall init_workqueues+0x0/0x289 returned 0 after 0 
usecs
[0.152805] calling  check_cpu_stall_init+0x0/0x12 @ 1
[0.152810] initcall check_cpu_stall_init+0x0/0x12 returned 0 after 
0 usecs
[0.152814] calling  migration_init+0x0/0x55 @ 1
[0.152820] initcall migration_init+0x0/0x55 returned 0 after 0 usecs
[0.152826] calling  cpu_stop_init+0x0/0x57 @ 1
[0.152863] initcall cpu_stop_init+0x0/0x57 returned 0 after 0 usecs
[0.152868] calling  rcu_register_oom_notifier+0x0/0xd @ 1
[0.152874] initcall rcu_register_oom_notifier+0x0/0xd returned 0 
after 0 usecs
[0.152879] calling  rcu_scheduler_really_started+0x0/0xd @ 1
[0.152883] initcall rcu_scheduler_really_started+0x0/0xd returned 0 
after 0 usecs
[0.152888] calling  rcu_spawn_gp_kthread+0x0/0x6b @ 1
[0.152936] initcall rcu_spawn_gp_kthread+0x0/0x6b returned 0 after 
0 usecs
[0.152941] calling  relay_init+0x0/0xd @ 1
[0.152946] initcall relay_init+0x0/0xd returned 0 after 0 usecs
[0.152950] calling  tracer_alloc_buffers+0x0/0x18b @ 1
[0.153030] initcall tracer_alloc_buffers+0x0/0x18b returned 0 after 
0 usecs
[0.153034] calling  init_events+0x0/0x57 @ 1
[0.153041] initcall init_events+0x0/0x57 returned 0 after 0 usecs
[0.153046] calling  init_trace_printk+0x0/0xa @ 1
[0.153051] initcall init_trace_printk+0x0/0xa returned 0 after 0 
usecs
[0.153055] calling  event_trace_memsetup+0x0/0x4a @ 1
[0.153067] initcall event_trace_memsetup+0x0/0x4a returned 0 after 
0 usecs
[0.153158] NMI watchdog: enabled on all CPUs, permanently consumes 
one hw-PMU counter.
[0.153361] CPU 1 irqstacks, hard=f40ae000 soft=f40b
[0.153365] smpboot: Booting Node   0, Processors  #1 OK
[0.163398] Initializing CPU#1
[0.166591] Brought up 2 CPUs
[0.166596] smpboot: Total of 2 processors activated (6399.62 
BogoMIPS)
[0.168897] devtmpfs: initialized
[0.169277] calling  ipc_ns_init+0x0/0xd @ 1
[0.169284] initcall ipc_ns_init+0x0/0xd returned 0 after 0 usecs
[0.169289] calling  init_mmap_min_addr+0x0/0xd @ 1
[0.169294] initcall init_mmap_min_addr+0x0/0xd returned 0 after 0 
usecs
[0.169302] calling  init_cpufreq_transition_notifier_list+0x0/0x14 
@ 1
[0.169315] initcall init_cpufreq_transition_notifier_list+0x0/0x14 
returned 0 after 0 usecs
[0.169320] calling  net_ns_init+0x0/0xca @ 1
[

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

Christian K?nig  changed:

   What|Removed |Added

  Attachment #81770|0   |1
is obsolete||
  Attachment #82190|0   |1
is obsolete||
  Attachment #82194|0   |1
is obsolete||
  Attachment #82196|0   |1
is obsolete||
  Attachment #82198|0   |1
is obsolete||
  Attachment #82226|0   |1
is obsolete||
  Attachment #82304|0   |1
is obsolete||

--- Comment #20 from Christian K?nig  ---
Created attachment 82325
  --> https://bugs.freedesktop.org/attachment.cgi?id=82325=edit
Possible fix.

I was able to reproduce the problem, and this patch (only a slightly modified
version of the old one) seems to fix it for me.

Please retest and provide new dmesg logs (as far as that is possible).

Also please try it a couple of times, cause at least on my test system
suspend/resume on 3.10 seems to be a bit unstable (even without the radeon
driver).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/f4ee69c8/attachment.html>

Radeon HD 6310 (AMD Wrestler): [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[Alex Deucher]

On Thu, Jul 11, 2013 at 3:41 AM, Paul Menzel
 wrote:
> Dear Linux folks,
>
>
> using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged
> and built with `make deb-pkg`, it failed the last boot.
>
> [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
>
> The strange thing is that it worked the last time I tried with the same
> Linux kernel image as I posted to the list [1]. I just booted an old
> 3.2.46 distribution Linux in between. (And it looked like the
> modesetting did not work when doing so. But I did not look further into
> it.)


Make sure you have the updated rlc and uvd ucode installed and that
the correct ucode is being used in your initrd, etc.

Alex

[PATCH 2/2] DRM: use anon_inode instead of delayed inode init

[Daniel Vetter]

On Thu, Jul 11, 2013 at 01:45:30AM +0200, David Herrmann wrote:
> Instead of delaying inode initialization until first ->open(), we can use
> an anonymous inode. This avoids modifying FS internal inode fields and
> provides us a private address_space right during initialization.
> 
> Delayed TTM dev_mapping initialization is currently left untouched to keep
> this simple. But we could now safely provide the address_space during
> ttm_bo_device_init() instead of delaying until first buffer ->mmap().
> 
> Note that this also fixes several bugs:
>  - We currently call iput(container_of(..dev_mapping..)) before
>drm_lastclose(), but we reset dev_mapping to zero at the end of
>drm_lastclose(). This fails if dev_mapping points to an address_space
>other than the current inode and the char-dev got already removed.
>  - We also drop dev_mapping during any drm_lastclose() call. So if
>user-space still has VMAs to our buffers, we will be unable to unmap
>them if the next ->firstopen() is on another inode. dev_mapping will
>then point to a new address_space and we leak mappings that we no
>longer control.

It's certainly ugly, but I don't think we have a real problem here. vma
grabs a reference to the open file at mmap time and we grab a reference to
the underlying gem object. So it shouldn't be possible to observe a
non-NULL dev_mapping while the inode refcount has already reached 0
anywhere we actually care. At least in drm/i915 since we never call
unmap_mapping_range if we know that there's no ptes around pointing at
this specific object (which we accurately keep track of in our fault
handler).

TTM might be different, and it's certainly good to rid us of this code.

>  - We ignore inode->i_mapping completely. It is unlikely that a FS uses it
>to overwrite inode->i_data for char-devs, but it definitely doesn't
>look very nice to ignore it silently.

Tbh I have no idea what the rules are here ... But since core vfs code
uses the filp->f_mapping at mmap time not frobbing inode->i_mapping looks
like the sane to do.

> Regarding legacy drivers: We no longer reset the address_space during
> drm_lastclose() to avoid re-allocating inodes all the time. However,
> legacy UMS drivers are weird and it is not clear to me whether some of the
> old drivers might depend on this (for what reason?), but I remember Daniel
> told me that i810 might.

i915 in gem+ums mode might. i810 is a different level of horror show
entirely, but since it doesn't do gem we can ignore it here.

> 
> Tested with nouveau on x86_64.
> 
> Signed-off-by: David Herrmann 

Reviewed-by: Daniel Vetter 

I guess it makes sense to merge that after your drm vma offset manager
changes with the little pte shootdown helper since that'll reduce the
diff?
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c  |  1 -
>  drivers/gpu/drm/drm_fops.c | 24 +++-
>  drivers/gpu/drm/drm_stub.c | 12 +++-
>  drivers/gpu/drm/i915/i915_gem.c|  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_gem.c  |  2 +-
>  drivers/gpu/drm/omapdrm/omap_gem.c |  7 ---
>  drivers/gpu/drm/qxl/qxl_object.c   |  2 +-
>  drivers/gpu/drm/qxl/qxl_ttm.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_object.c |  2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  2 +-
>  include/drm/drmP.h |  2 +-
>  12 files changed, 27 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 99fcd7c..9797613 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -232,7 +232,6 @@ int drm_lastclose(struct drm_device * dev)
>   !drm_core_check_feature(dev, DRIVER_MODESET))
>   drm_dma_takedown(dev);
>  
> - dev->dev_mapping = NULL;
>   mutex_unlock(>struct_mutex);
>  
>   DRM_DEBUG("lastclose completed\n");
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 3a24385..6752f59 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -122,8 +122,6 @@ int drm_open(struct inode *inode, struct file *filp)
>   struct drm_minor *minor;
>   int retcode = 0;
>   int need_setup = 0;
> - struct address_space *old_mapping;
> - struct address_space *old_imapping;
>  
>   minor = idr_find(_minors_idr, minor_id);
>   if (!minor)
> @@ -137,16 +135,9 @@ int drm_open(struct inode *inode, struct file *filp)
>  
>   if (!dev->open_count++)
>   need_setup = 1;
> - mutex_lock(>struct_mutex);
> - old_imapping = inode->i_mapping;
> - old_mapping = dev->dev_mapping;
> - if (old_mapping == NULL)
> - dev->dev_mapping = >i_data;
> - /* ihold ensures nobody can remove inode with our i_data */
> - ihold(container_of(dev->dev_mapping, struct inode, i_data));
> - inode->i_mapping = dev->dev_mapping;
> - filp->f_mapping = 

[Bug 66805] [radeonsi] half life 2 base games are segfaulting

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66805

--- Comment #1 from Michel D?nzer  ---
Can you provide the output from running with the environment variable
RADEON_DUMP_SHADERS=1 ? Beware that it might be large if the game compiles many
shaders before the failure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/4881a8a5/attachment.html>

[PATCH 1/2] anon_inodes: allow external inode allocations

[Daniel Vetter]

On Thu, Jul 11, 2013 at 01:45:29AM +0200, David Herrmann wrote:
> DRM core shares a single address_space across all inodes that belong to
> the same DRM device. This allows efficient unmapping of user-space
> mappings during buffer destruction. However, there is no easy way to get a
> shared address_space for DRM devices during initialization. Therefore, we
> currently delay this step until the first ->open() and save the given
> inode for future use.

Quick correction for the drm use-case: We don't need the address space at
buffer destruction, since each vma holds a reference to the backing gem
object. So buffer destruction can only happen once there's guaranteed to
be no mmapping around any more.

But we make extensive use of the address_space to shoot down ptes with
unmap_mapping_range before we evict a buffer from the mmio gart. In the
page fault handler we can then move the buffer object back to a place
userspace can get at it and set up new ptes.

> This causes ugly delayed initialization throughout the DRM core. TTM
> devices end up without a dev_mapping pointer and we have to carefully
> respect any underlying filesystem implementation so we don't corrupt the
> inode->i_mapping and inode->i_data fields.
> 
> We can avoid this if we were allowed to allocate an anonymous inode for
> each DRM device. We only have to set file->f_mapping during ->open()
> and no longer need to adjust inode mappings. As fs/anon_inodes.c already
> provides a minimal internal FS mount, we extend it to also provide
> anonymous inodes for use in drivers like DRM.
> 
> Signed-off-by: David Herrmann 

I'm not an fs guy so no comment on the patch itself, but having an
inode/address space available at driver load time will allow us to get rid
of tons of ulgy

if (dev_mapping)
unmap_mapping_rang(dev_mapping, ...);

code sprinkled all over drm core and drivers. So

Wanted-by: Daniel Vetter 

> ---
>  fs/anon_inodes.c| 36 +---
>  include/linux/anon_inodes.h |  1 +
>  2 files changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
> index 47a65df..7d8a80a 100644
> --- a/fs/anon_inodes.c
> +++ b/fs/anon_inodes.c
> @@ -25,6 +25,7 @@
>  static struct vfsmount *anon_inode_mnt __read_mostly;
>  static struct inode *anon_inode_inode;
>  static const struct file_operations anon_inode_fops;
> +static struct dentry *anon_inode_root;
>  
>  /*
>   * anon_inodefs_dname() is called from d_path().
> @@ -87,19 +88,18 @@ static struct inode *anon_inode_mkinode(struct 
> super_block *s)
>  static struct dentry *anon_inodefs_mount(struct file_system_type *fs_type,
>   int flags, const char *dev_name, void *data)
>  {
> - struct dentry *root;
> - root = mount_pseudo(fs_type, "anon_inode:", NULL,
> + anon_inode_root = mount_pseudo(fs_type, "anon_inode:", NULL,
>   _inodefs_dentry_operations, ANON_INODE_FS_MAGIC);
> - if (!IS_ERR(root)) {
> - struct super_block *s = root->d_sb;
> + if (!IS_ERR(anon_inode_root)) {
> + struct super_block *s = anon_inode_root->d_sb;
>   anon_inode_inode = anon_inode_mkinode(s);
>   if (IS_ERR(anon_inode_inode)) {
> - dput(root);
> + dput(anon_inode_root);
>   deactivate_locked_super(s);
> - root = ERR_CAST(anon_inode_inode);
> + anon_inode_root = ERR_CAST(anon_inode_inode);
>   }
>   }
> - return root;
> + return anon_inode_root;
>  }
>  
>  static struct file_system_type anon_inode_fs_type = {
> @@ -219,6 +219,28 @@ err_put_unused_fd:
>  }
>  EXPORT_SYMBOL_GPL(anon_inode_getfd);
>  
> +/**
> + * anon_inode_new - create private anonymous inode
> + *
> + * Creates a new inode on the anonymous inode FS for driver's use. The inode 
> has
> + * it's own address_space compared to the shared anon_inode_inode. It can be
> + * used in situations where user-space mappings have to be shared across
> + * different files but no backing inode is available.
> + *
> + * Call iput(inode) to release the inode.
> + *
> + * RETURNS:
> + * New inode on success, error pointer on failure.
> + */
> +struct inode *anon_inode_new(void)
> +{
> + if (IS_ERR(anon_inode_root))
> + return ERR_CAST(anon_inode_root);
> +
> + return anon_inode_mkinode(anon_inode_root->d_sb);
> +}
> +EXPORT_SYMBOL_GPL(anon_inode_new);
> +
>  static int __init anon_inode_init(void)
>  {
>   int error;
> diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
> index 8013a45..ddbd67f 100644
> --- a/include/linux/anon_inodes.h
> +++ b/include/linux/anon_inodes.h
> @@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
>   void *priv, int flags);
>  int anon_inode_getfd(const char *name, const struct file_operations *fops,
>void *priv, 

Questions about TTM buffer object maping

[Daniel Vetter]

On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
> On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron
>  wrote:
> > Hello,
> >
> > I'm trying to understand how TTM buffer object mapping works on Linux, to
> > make this behave properly on FreeBSD.
> >
> > Here's what I think I understand:
> >
> > When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's a
> > page fault, the page is looked up and inserted in the VMA using
> > vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is
> > called, which drops a reference. When the last reference is dropped, the
> > buffer object is destroyed.
> >
> > What's still not clear to me is how munmap() works here. After talking about
> > this on IRC with some people, I think that unmap_mapping_range() (called by
> > ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from
> > userland. Is that true?
> 
> Yes that's true.

Afaik unmap_mapping_range only kills the ptes and doesn't remove the vma.
So not equivalent to a munmap from userspace. It simply allows us to
intercept the next access in the page fault handler and move the buffer
back into place.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2] drm/gem: simplify object initialization

[Rob Clark]

On Thu, Jul 11, 2013 at 5:56 AM, David Herrmann  
wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
>
> Cc: Patrik Jakobsson 
> Signed-off-by: David Herrmann 

Acked-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_gem.c  | 20 
>  drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
>  drivers/gpu/drm/gma500/gem.c   |  7 ---
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
>  drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
>  drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
>  include/drm/drmP.h |  4 ++--
>  7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
>  int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
>  {
> -   BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> +   struct file *filp;
>
> -   obj->dev = dev;
> -   obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> -   if (IS_ERR(obj->filp))
> -   return PTR_ERR(obj->filp);
> +   filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> +   if (IS_ERR(filp))
> +   return PTR_ERR(filp);
>
> -   kref_init(>refcount);
> -   atomic_set(>handle_count, 0);
> -   obj->size = size;
> +   drm_gem_private_object_init(dev, obj, size);
> +   obj->filp = filp;
>
> return 0;
>  }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
>   * no GEM provided backing store. Instead the caller is responsible for
>   * backing the object and handling it.
>   */
> -int drm_gem_private_object_init(struct drm_device *dev,
> -   struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> +struct drm_gem_object *obj, size_t size)
>  {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(>refcount);
> atomic_set(>handle_count, 0);
> obj->size = size;
> -
> -   return 0;
>  }
>  EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> -   if (drm_gem_private_object_init(dev,
> -   >gem, aligned_size) == 0)
> -   return backing;
> -   psb_gtt_free_range(dev, backing);
> +   drm_gem_private_object_init(dev, >gem, aligned_size);
> +   return backing;
> }
> return NULL;
>  }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> -   if (drm_gem_private_object_init(dev, >gem, size) != 0)
> -   goto free_gtt;
> +
> +   drm_gem_private_object_init(dev, >gem, size);
> if (drm_gem_handle_create(file, >gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> +   drm_gem_object_release(>gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
> drm_device *dev,
> goto fail_detach;
> }
>
> -   ret = drm_gem_private_object_init(dev, >base, dma_buf->size);
> -   if (ret) 

[Bug 65723] Xonotic glsl 1.30 broken due to lack of derivatives support in radeonsi

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65723

--- Comment #7 from Rafael Castillo  ---
tested and working, many thanks for your hard work

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d1bdd6f9/attachment.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66558

Bj?rn Beutel  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/9beefb45/attachment.html>

Questions about TTM buffer object maping

[Jean-Sébastien Pédron]

Hello,

I'm trying to understand how TTM buffer object mapping works on Linux, 
to make this behave properly on FreeBSD.

Here's what I think I understand:

When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When 
there's a page fault, the page is looked up and inserted in the VMA 
using vm_insert_mixed(). When a buffer object is munmap()'d, 
ttm_bo_vm_close() is called, which drops a reference. When the last 
reference is dropped, the buffer object is destroyed.

What's still not clear to me is how munmap() works here. After talking 
about this on IRC with some people, I think that unmap_mapping_range() 
(called by ttm_bo_unmap_virtual_locked()) is equivalent to calling 
munmap() from userland. Is that true?

When a buffer object is moved, what happens to the mapping?

In particular, I see in ttm_bo_move_accel_cleanup() that the ttm 
structure can be transferred to ghost_obj, which is destroyed shortly 
after. This ends up in ttm_put_pages() which uses __free_page(), for 
each page of the buffer object. At this stage, is the ghost object 
already munmap()'d? Or does __free_page() unmap a page implicitly (ie. 
remove it from VMA)?

Sorry if my questions are stupid, I'm rather new to memory management.

-- 
Jean-S?bastien P?dron

[PATCH] drm: remove FASYNC support

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Wednesday 10 July 2013 17:25:04 Daniel Vetter wrote:
> So I've stumbled over drm_fasync and wondered what it does. Digging
> that up is quite a story.
> 
> First I've had to read up on what this does and ended up being rather
> bewildered why peopled loved signals so much back in the days that
> they've created SIGIO just for that ...
> 
> Then I wondered how this ever works, and what that strange "No-op."
> comment right above it should mean. After all calling the core fasync
> helper is pretty obviously not a noop. After reading through the
> kernels FASYNC implementation I've noticed that signals are only sent
> out to the processes attached with FASYNC by calling kill_fasync.
> 
> No merged drm driver has ever done that.
> 
> After more digging I've found out that the only driver that ever used
> this is the so called GAMMA driver. I've frankly never heard of such a
> gpu brand ever before. Now FASYNC seems to not have been the only bad
> thing with that driver, since Dave Airlie removed it from the drm
> driver with prejudice:
> 
> commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
> Author: Dave Airlie 
> Date:   Sun Aug 29 12:04:35 2004 +
> 
> Drop GAMMA DRM from a great height ...
> 
> Long story short, the drm fasync support seems to be doing absolutely
> nothing. And the only user of it was never merged into the upstream
> kernel. And we don't need any fops->fasync callback since the fcntl
> implementation in the kernel already implements the noop case
> correctly.
> 
> So stop this particular cargo-cult and rip it all out.
> 
> v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
> (somehow I've missed that one in staging). Also drop the reference in
> the drm DocBook. ARM compile-fail reported by Rob Clark.
> 
> v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
> patch here.
> 
> v4: Actually git add ... tsk.
> 
> Cc: Dave Airlie 
> Cc: Laurent Pinchart 
> Cc: Rob Clark 
> Signed-off-by: Daniel Vetter 

Acked-by: Laurent Pinchart 

> ---
>  Documentation/DocBook/drm.tmpl   |  1 -
>  drivers/gpu/drm/ast/ast_drv.c|  1 -
>  drivers/gpu/drm/cirrus/cirrus_drv.c  |  1 -
>  drivers/gpu/drm/drm_fops.c   | 14 --
>  drivers/gpu/drm/gma500/psb_drv.c |  1 -
>  drivers/gpu/drm/i810/i810_dma.c  |  1 -
>  drivers/gpu/drm/i810/i810_drv.c  |  1 -
>  drivers/gpu/drm/i915/i915_drv.c  |  1 -
>  drivers/gpu/drm/mga/mga_drv.c|  1 -
>  drivers/gpu/drm/mgag200/mgag200_drv.c|  1 -
>  drivers/gpu/drm/nouveau/nouveau_drm.c|  1 -
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  1 -
>  drivers/gpu/drm/qxl/qxl_drv.c|  1 -
>  drivers/gpu/drm/r128/r128_drv.c  |  1 -
>  drivers/gpu/drm/radeon/radeon_drv.c  |  2 --
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c|  1 -
>  drivers/gpu/drm/savage/savage_drv.c  |  1 -
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c |  1 -
>  drivers/gpu/drm/sis/sis_drv.c|  1 -
>  drivers/gpu/drm/tdfx/tdfx_drv.c  |  1 -
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  1 -
>  drivers/gpu/drm/udl/udl_drv.c|  1 -
>  drivers/gpu/drm/via/via_drv.c|  1 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  1 -
>  drivers/gpu/host1x/drm/drm.c |  1 -
>  drivers/staging/imx-drm/imx-drm-core.c   |  1 -
>  include/drm/drmP.h   |  3 ---
>  27 files changed, 43 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..79dd70e 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2498,7 +2498,6 @@ void (*postclose) (struct drm_device *, struct
> drm_file *); 
>   .poll = drm_poll,
>   .read = drm_read,
> - .fasync = drm_fasync,
>   .llseek = no_llseek,
>   
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index df0d0a0..16050ed 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -190,7 +190,6 @@ static const struct file_operations ast_fops = {
>   .unlocked_ioctl = drm_ioctl,
>   .mmap = ast_mmap,
>   .poll = drm_poll,
> - .fasync = drm_fasync,
>  #ifdef CONFIG_COMPAT
>   .compat_ioctl = drm_compat_ioctl,
>  #endif
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
> b/drivers/gpu/drm/cirrus/cirrus_drv.c index 8ecb601..85748f6 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> @@ -85,7 +85,6 @@ static const struct file_operations cirrus_driver_fops = {
> #ifdef CONFIG_COMPAT
>   .compat_ioctl = drm_compat_ioctl,
>  #endif
> - .fasync = drm_fasync,
>  };
>  static struct drm_driver driver = {
>   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_USE_MTRR,
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 14e0bb6..d1b4771 100644
> --- 

[PATCH 2/2] DRM: use anon_inode instead of delayed inode init

[David Herrmann]

Instead of delaying inode initialization until first ->open(), we can use
an anonymous inode. This avoids modifying FS internal inode fields and
provides us a private address_space right during initialization.

Delayed TTM dev_mapping initialization is currently left untouched to keep
this simple. But we could now safely provide the address_space during
ttm_bo_device_init() instead of delaying until first buffer ->mmap().

Note that this also fixes several bugs:
 - We currently call iput(container_of(..dev_mapping..)) before
   drm_lastclose(), but we reset dev_mapping to zero at the end of
   drm_lastclose(). This fails if dev_mapping points to an address_space
   other than the current inode and the char-dev got already removed.
 - We also drop dev_mapping during any drm_lastclose() call. So if
   user-space still has VMAs to our buffers, we will be unable to unmap
   them if the next ->firstopen() is on another inode. dev_mapping will
   then point to a new address_space and we leak mappings that we no
   longer control.
 - We ignore inode->i_mapping completely. It is unlikely that a FS uses it
   to overwrite inode->i_data for char-devs, but it definitely doesn't
   look very nice to ignore it silently.

Regarding legacy drivers: We no longer reset the address_space during
drm_lastclose() to avoid re-allocating inodes all the time. However,
legacy UMS drivers are weird and it is not clear to me whether some of the
old drivers might depend on this (for what reason?), but I remember Daniel
told me that i810 might.

Tested with nouveau on x86_64.

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_drv.c  |  1 -
 drivers/gpu/drm/drm_fops.c | 24 +++-
 drivers/gpu/drm/drm_stub.c | 12 +++-
 drivers/gpu/drm/i915/i915_gem.c|  4 ++--
 drivers/gpu/drm/nouveau/nouveau_gem.c  |  2 +-
 drivers/gpu/drm/omapdrm/omap_gem.c |  7 ---
 drivers/gpu/drm/qxl/qxl_object.c   |  2 +-
 drivers/gpu/drm/qxl/qxl_ttm.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_object.c |  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  2 +-
 include/drm/drmP.h |  2 +-
 12 files changed, 27 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 99fcd7c..9797613 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -232,7 +232,6 @@ int drm_lastclose(struct drm_device * dev)
!drm_core_check_feature(dev, DRIVER_MODESET))
drm_dma_takedown(dev);

-   dev->dev_mapping = NULL;
mutex_unlock(>struct_mutex);

DRM_DEBUG("lastclose completed\n");
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..6752f59 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -122,8 +122,6 @@ int drm_open(struct inode *inode, struct file *filp)
struct drm_minor *minor;
int retcode = 0;
int need_setup = 0;
-   struct address_space *old_mapping;
-   struct address_space *old_imapping;

minor = idr_find(_minors_idr, minor_id);
if (!minor)
@@ -137,16 +135,9 @@ int drm_open(struct inode *inode, struct file *filp)

if (!dev->open_count++)
need_setup = 1;
-   mutex_lock(>struct_mutex);
-   old_imapping = inode->i_mapping;
-   old_mapping = dev->dev_mapping;
-   if (old_mapping == NULL)
-   dev->dev_mapping = >i_data;
-   /* ihold ensures nobody can remove inode with our i_data */
-   ihold(container_of(dev->dev_mapping, struct inode, i_data));
-   inode->i_mapping = dev->dev_mapping;
-   filp->f_mapping = dev->dev_mapping;
-   mutex_unlock(>struct_mutex);
+
+   /* set address_space for shared mappings */
+   filp->f_mapping = dev->anon_inode->i_mapping;

retcode = drm_open_helper(inode, filp, dev);
if (retcode)
@@ -160,12 +151,6 @@ int drm_open(struct inode *inode, struct file *filp)
return 0;

 err_undo:
-   mutex_lock(>struct_mutex);
-   filp->f_mapping = old_imapping;
-   inode->i_mapping = old_imapping;
-   iput(container_of(dev->dev_mapping, struct inode, i_data));
-   dev->dev_mapping = old_mapping;
-   mutex_unlock(>struct_mutex);
dev->open_count--;
return retcode;
 }
@@ -543,9 +528,6 @@ int drm_release(struct inode *inode, struct file *filp)
}
}

-   BUG_ON(dev->dev_mapping == NULL);
-   iput(container_of(dev->dev_mapping, struct inode, i_data));
-
/* drop the reference held my the file priv */
drm_master_put(_priv->master);
file_priv->is_master = 0;
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 327ca19..45804f1 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -31,6 +31,7 @@
  * DEALINGS IN THE SOFTWARE.
  */

+#include 
 #include 
 #include 
 

[PATCH 1/2] anon_inodes: allow external inode allocations

[David Herrmann]

DRM core shares a single address_space across all inodes that belong to
the same DRM device. This allows efficient unmapping of user-space
mappings during buffer destruction. However, there is no easy way to get a
shared address_space for DRM devices during initialization. Therefore, we
currently delay this step until the first ->open() and save the given
inode for future use.

This causes ugly delayed initialization throughout the DRM core. TTM
devices end up without a dev_mapping pointer and we have to carefully
respect any underlying filesystem implementation so we don't corrupt the
inode->i_mapping and inode->i_data fields.

We can avoid this if we were allowed to allocate an anonymous inode for
each DRM device. We only have to set file->f_mapping during ->open()
and no longer need to adjust inode mappings. As fs/anon_inodes.c already
provides a minimal internal FS mount, we extend it to also provide
anonymous inodes for use in drivers like DRM.

Signed-off-by: David Herrmann 
---
 fs/anon_inodes.c| 36 +---
 include/linux/anon_inodes.h |  1 +
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 47a65df..7d8a80a 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -25,6 +25,7 @@
 static struct vfsmount *anon_inode_mnt __read_mostly;
 static struct inode *anon_inode_inode;
 static const struct file_operations anon_inode_fops;
+static struct dentry *anon_inode_root;

 /*
  * anon_inodefs_dname() is called from d_path().
@@ -87,19 +88,18 @@ static struct inode *anon_inode_mkinode(struct super_block 
*s)
 static struct dentry *anon_inodefs_mount(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
 {
-   struct dentry *root;
-   root = mount_pseudo(fs_type, "anon_inode:", NULL,
+   anon_inode_root = mount_pseudo(fs_type, "anon_inode:", NULL,
_inodefs_dentry_operations, ANON_INODE_FS_MAGIC);
-   if (!IS_ERR(root)) {
-   struct super_block *s = root->d_sb;
+   if (!IS_ERR(anon_inode_root)) {
+   struct super_block *s = anon_inode_root->d_sb;
anon_inode_inode = anon_inode_mkinode(s);
if (IS_ERR(anon_inode_inode)) {
-   dput(root);
+   dput(anon_inode_root);
deactivate_locked_super(s);
-   root = ERR_CAST(anon_inode_inode);
+   anon_inode_root = ERR_CAST(anon_inode_inode);
}
}
-   return root;
+   return anon_inode_root;
 }

 static struct file_system_type anon_inode_fs_type = {
@@ -219,6 +219,28 @@ err_put_unused_fd:
 }
 EXPORT_SYMBOL_GPL(anon_inode_getfd);

+/**
+ * anon_inode_new - create private anonymous inode
+ *
+ * Creates a new inode on the anonymous inode FS for driver's use. The inode 
has
+ * it's own address_space compared to the shared anon_inode_inode. It can be
+ * used in situations where user-space mappings have to be shared across
+ * different files but no backing inode is available.
+ *
+ * Call iput(inode) to release the inode.
+ *
+ * RETURNS:
+ * New inode on success, error pointer on failure.
+ */
+struct inode *anon_inode_new(void)
+{
+   if (IS_ERR(anon_inode_root))
+   return ERR_CAST(anon_inode_root);
+
+   return anon_inode_mkinode(anon_inode_root->d_sb);
+}
+EXPORT_SYMBOL_GPL(anon_inode_new);
+
 static int __init anon_inode_init(void)
 {
int error;
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 8013a45..ddbd67f 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
void *priv, int flags);
 int anon_inode_getfd(const char *name, const struct file_operations *fops,
 void *priv, int flags);
+struct inode *anon_inode_new(void);

 #endif /* _LINUX_ANON_INODES_H */

-- 
1.8.3.2

[PATCH 0/2] Anonymous Inode Allocations

[David Herrmann]

Hi

This implements anon_inodes_new() to create anonymous inodes. Patch #1
describes the changes to anon_inodes.c and why DRM could make great use of this.
Patch #2 converts DRM core to use anon_inodes_new() instead of delayed
dev_mapping initialization (but kept simple, TTM can be converted later).

The idea is to get an anonymous backing inode for DRM devices without waiting
for the first char-dev inode. We use it to unmap userspace mappings via
unmap_mapping_range() if we have to evict buffers if GTT runs short or if the FW
framebuffers are destroyed.
We need the inode only once the first user-space mapping was created, but the
delayed initialization causes an ugly code base and keeps inodes of char-devs
around just to preserve the address_space.

We actually only need the address_space, but mm core requires an corresponding
file* and FS core requires mapping->host to be set (although I am not sure
whether we can hit those paths with char-devs). So I went with the whole
anonymous inode approach.

If anyone has an idea how to use an embedded "struct address_space" inside of
"drm_device" and set "dev_mapping->host" to the shared anon_inode_inode, I'd be
happy to implement it. However, I didn't succeed and I am actually not sure that
separate "struct address_space" are actually supported. For instance, DRM core
uses code like:
  container_of(dev_mapping, struct inode, i_data)
So I didn't spent much time on that approach.

Cheers
David

David Herrmann (2):
  anon_inodes: allow external inode allocations
  DRM: use anon_inode instead of delayed inode init

 drivers/gpu/drm/drm_drv.c  |  1 -
 drivers/gpu/drm/drm_fops.c | 24 +++
 drivers/gpu/drm/drm_stub.c | 12 +++-
 drivers/gpu/drm/i915/i915_gem.c|  4 ++--
 drivers/gpu/drm/nouveau/nouveau_gem.c  |  2 +-
 drivers/gpu/drm/omapdrm/omap_gem.c |  7 ---
 drivers/gpu/drm/qxl/qxl_object.c   |  2 +-
 drivers/gpu/drm/qxl/qxl_ttm.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_object.c |  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  2 +-
 fs/anon_inodes.c   | 36 +++---
 include/drm/drmP.h |  2 +-
 include/linux/anon_inodes.h|  1 +
 14 files changed, 57 insertions(+), 42 deletions(-)

-- 
1.8.3.2

[Bug 66805] New: [radeonsi] half life 2 base games are segfaulting

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66805

  Priority: medium
Bug ID: 66805
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [radeonsi] half life 2 base games are segfaulting
  Severity: blocker
Classification: Unclassified
OS: All
  Reporter: lordheavym at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

* radeon HD7870:
 OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
 OpenGL version string: 2.1 Mesa 9.2.0-devel (git-b042aae)
 OpenGL shading language version string: 1.30
* llvm 3.4svn

HL2 based game are all segfaulting (here portal):
--8<--
SDL video target is 'x11'
SDL video target is 'x11'
SDL failed to create GL compatibility profile (whichProfile=0)!
Installing breakpad exception handler for
appid(gameoverlayui)/version(20130709174336_client)
Installing breakpad exception handler for
appid(gameoverlayui)/version(1.0_client)
Installing breakpad exception handler for
appid(gameoverlayui)/version(1.0_client)
Installing breakpad exception handler for
appid(gameoverlayui)/version(1.0_client)
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70:
non-double matrix element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70:
non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78:
saw unknown, expected number
[0711/011648:WARNING:proxy_service.cc(958)] PAC support disabled because there
is no system implementation
Using breakpad crash handler
Setting breakpad minidump AppID = 400
Forcing breakpad minidump interfaces to load
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561197992653503 [API loaded
yes]
Steam_SetMinidumpSteamID:  Setting Steam ID:  76561197992653503
Did not detect any valid joysticks.
[0711/011652:ERROR:resource_bundle.cc(411)] Failed to load
/home/lordh/.local/share/Steam/SteamApps/common/Portal/cef_gtk.pak
Some features may not be available.
[0711/011652:WARNING:proxy_service.cc(646)] PAC support disabled because there
is no system implementation
Could not load program cache file glbaseshaders.cfg
Could not find base GL shader cache file
CGLMShaderPair::SetProgramPair: Centroid masks differ at link time of vertex
shader lightmappedgeneric_vs20 and pixel shader
decalbasetimeslightmapalphablendselfillum2_ps20b!
Loaded program cache file "glshaders.cfg", total keyvalues: 189, total
successfully linked: 189
Precache: Took 8048 ms, Vertex 486, Pixel 906
ConVarRef mat_dxlevel doesn't point to an existing ConVar
Game.so loaded for "Half-Life 2"
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70:
non-double matrix element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70:
non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78:
saw unknown, expected number
This system supports the OpenGL extension GL_EXT_framebuffer_object.
This system supports the OpenGL extension GL_EXT_framebuffer_blit.
This system DOES NOT support the OpenGL extension
GL_EXT_framebuffer_multisample.
This system DOES NOT support the OpenGL extension GL_APPLE_fence.
This system DOES NOT support the OpenGL extension GL_NV_fence.
This system supports the OpenGL extension GL_ARB_sync.
This system supports the OpenGL extension GL_EXT_draw_buffers2.
This system DOES NOT support the OpenGL extension GL_EXT_bindable_uniform.
This system DOES NOT support the OpenGL extension GL_APPLE_flush_buffer_range.
This system supports the OpenGL extension GL_ARB_map_buffer_range.
This system supports the OpenGL extension GL_ARB_vertex_buffer_object.
This system supports the OpenGL extension GL_ARB_occlusion_query.
This system DOES NOT support the OpenGL extension GL_APPLE_texture_range.
This system DOES NOT support the OpenGL extension GL_APPLE_client_storage.
This system DOES NOT support the OpenGL extension GL_ARB_uniform_buffer.
This system supports the OpenGL extension GL_ARB_vertex_array_bgra.
This system supports the OpenGL extension GL_EXT_vertex_array_bgra.
This system supports the OpenGL extension GL_ARB_framebuffer_object.
This system DOES NOT support the OpenGL extension GL_GREMEDY_string_marker.
This system supports the OpenGL extension GL_ARB_debug_output.
This system DOES NOT support the OpenGL extension GL_EXT_direct_state_access.
This system DOES NOT support the OpenGL extension GL_NV_bindless_texture.
This system DOES NOT support the OpenGL extension GL_AMD_pinned_memory.
This system DOES NOT support the OpenGL extension
GL_EXT_framebuffer_multisample_blit_scaled.
This system supports the OpenGL extension GL_EXT_texture_sRGB_decode.
This system DOES NOT support the OpenGL extension 

[Bug 65723] Xonotic glsl 1.30 broken due to lack of derivatives support in radeonsi

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65723

--- Comment #7 from Rafael Castillo jrch2...@gmail.com ---
tested and working, many thanks for your hard work

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Questions about TTM buffer object maping

[Daniel Vetter]

On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
 On Wed, Jul 10, 2013 at 8:27 PM, Jean-Sébastien Pédron
 jean-sebastien.ped...@dumbbell.fr wrote:
  Hello,
 
  I'm trying to understand how TTM buffer object mapping works on Linux, to
  make this behave properly on FreeBSD.
 
  Here's what I think I understand:
 
  When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's a
  page fault, the page is looked up and inserted in the VMA using
  vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is
  called, which drops a reference. When the last reference is dropped, the
  buffer object is destroyed.
 
  What's still not clear to me is how munmap() works here. After talking about
  this on IRC with some people, I think that unmap_mapping_range() (called by
  ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from
  userland. Is that true?
 
 Yes that's true.

Afaik unmap_mapping_range only kills the ptes and doesn't remove the vma.
So not equivalent to a munmap from userspace. It simply allows us to
intercept the next access in the page fault handler and move the buffer
back into place.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] anon_inodes: allow external inode allocations

[Daniel Vetter]

On Thu, Jul 11, 2013 at 01:45:29AM +0200, David Herrmann wrote:
 DRM core shares a single address_space across all inodes that belong to
 the same DRM device. This allows efficient unmapping of user-space
 mappings during buffer destruction. However, there is no easy way to get a
 shared address_space for DRM devices during initialization. Therefore, we
 currently delay this step until the first -open() and save the given
 inode for future use.

Quick correction for the drm use-case: We don't need the address space at
buffer destruction, since each vma holds a reference to the backing gem
object. So buffer destruction can only happen once there's guaranteed to
be no mmapping around any more.

But we make extensive use of the address_space to shoot down ptes with
unmap_mapping_range before we evict a buffer from the mmio gart. In the
page fault handler we can then move the buffer object back to a place
userspace can get at it and set up new ptes.

 This causes ugly delayed initialization throughout the DRM core. TTM
 devices end up without a dev_mapping pointer and we have to carefully
 respect any underlying filesystem implementation so we don't corrupt the
 inode-i_mapping and inode-i_data fields.
 
 We can avoid this if we were allowed to allocate an anonymous inode for
 each DRM device. We only have to set file-f_mapping during -open()
 and no longer need to adjust inode mappings. As fs/anon_inodes.c already
 provides a minimal internal FS mount, we extend it to also provide
 anonymous inodes for use in drivers like DRM.
 
 Signed-off-by: David Herrmann dh.herrm...@gmail.com

I'm not an fs guy so no comment on the patch itself, but having an
inode/address space available at driver load time will allow us to get rid
of tons of ulgy

if (dev_mapping)
unmap_mapping_rang(dev_mapping, ...);

code sprinkled all over drm core and drivers. So

Wanted-by: Daniel Vetter daniel.vet...@ffwll.ch

 ---
  fs/anon_inodes.c| 36 +---
  include/linux/anon_inodes.h |  1 +
  2 files changed, 30 insertions(+), 7 deletions(-)
 
 diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
 index 47a65df..7d8a80a 100644
 --- a/fs/anon_inodes.c
 +++ b/fs/anon_inodes.c
 @@ -25,6 +25,7 @@
  static struct vfsmount *anon_inode_mnt __read_mostly;
  static struct inode *anon_inode_inode;
  static const struct file_operations anon_inode_fops;
 +static struct dentry *anon_inode_root;
  
  /*
   * anon_inodefs_dname() is called from d_path().
 @@ -87,19 +88,18 @@ static struct inode *anon_inode_mkinode(struct 
 super_block *s)
  static struct dentry *anon_inodefs_mount(struct file_system_type *fs_type,
   int flags, const char *dev_name, void *data)
  {
 - struct dentry *root;
 - root = mount_pseudo(fs_type, anon_inode:, NULL,
 + anon_inode_root = mount_pseudo(fs_type, anon_inode:, NULL,
   anon_inodefs_dentry_operations, ANON_INODE_FS_MAGIC);
 - if (!IS_ERR(root)) {
 - struct super_block *s = root-d_sb;
 + if (!IS_ERR(anon_inode_root)) {
 + struct super_block *s = anon_inode_root-d_sb;
   anon_inode_inode = anon_inode_mkinode(s);
   if (IS_ERR(anon_inode_inode)) {
 - dput(root);
 + dput(anon_inode_root);
   deactivate_locked_super(s);
 - root = ERR_CAST(anon_inode_inode);
 + anon_inode_root = ERR_CAST(anon_inode_inode);
   }
   }
 - return root;
 + return anon_inode_root;
  }
  
  static struct file_system_type anon_inode_fs_type = {
 @@ -219,6 +219,28 @@ err_put_unused_fd:
  }
  EXPORT_SYMBOL_GPL(anon_inode_getfd);
  
 +/**
 + * anon_inode_new - create private anonymous inode
 + *
 + * Creates a new inode on the anonymous inode FS for driver's use. The inode 
 has
 + * it's own address_space compared to the shared anon_inode_inode. It can be
 + * used in situations where user-space mappings have to be shared across
 + * different files but no backing inode is available.
 + *
 + * Call iput(inode) to release the inode.
 + *
 + * RETURNS:
 + * New inode on success, error pointer on failure.
 + */
 +struct inode *anon_inode_new(void)
 +{
 + if (IS_ERR(anon_inode_root))
 + return ERR_CAST(anon_inode_root);
 +
 + return anon_inode_mkinode(anon_inode_root-d_sb);
 +}
 +EXPORT_SYMBOL_GPL(anon_inode_new);
 +
  static int __init anon_inode_init(void)
  {
   int error;
 diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
 index 8013a45..ddbd67f 100644
 --- a/include/linux/anon_inodes.h
 +++ b/include/linux/anon_inodes.h
 @@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
   void *priv, int flags);
  int anon_inode_getfd(const char *name, const struct file_operations *fops,
void *priv, int flags);
 +struct inode *anon_inode_new(void);
  
  #endif /* 

Re: Bug in warning message from MTRR rework in uvesafb

[Andy Lutomirski]

On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
just.for.l...@googlemail.com wrote:
 Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, uvesafb: Clean up
 MTRR code contains the following change:

 @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
  }
  }

 +if (mtrr != 3  mtrr != 1)
 +pr_warn(uvesafb: mtrr should be set to 0 or 3; %d is
 unsupported, mtrr);
 +
  return 0;
  }
  #endif /* !MODULE */

 Shouldn't this be  mtrr != 0?

Indeed, and Sylvain Hitier (cc'd) sent a patch (off-list) that must
have gotten lost somewhere.

--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] DRM: use anon_inode instead of delayed inode init

[Daniel Vetter]

On Thu, Jul 11, 2013 at 01:45:30AM +0200, David Herrmann wrote:
 Instead of delaying inode initialization until first -open(), we can use
 an anonymous inode. This avoids modifying FS internal inode fields and
 provides us a private address_space right during initialization.
 
 Delayed TTM dev_mapping initialization is currently left untouched to keep
 this simple. But we could now safely provide the address_space during
 ttm_bo_device_init() instead of delaying until first buffer -mmap().
 
 Note that this also fixes several bugs:
  - We currently call iput(container_of(..dev_mapping..)) before
drm_lastclose(), but we reset dev_mapping to zero at the end of
drm_lastclose(). This fails if dev_mapping points to an address_space
other than the current inode and the char-dev got already removed.
  - We also drop dev_mapping during any drm_lastclose() call. So if
user-space still has VMAs to our buffers, we will be unable to unmap
them if the next -firstopen() is on another inode. dev_mapping will
then point to a new address_space and we leak mappings that we no
longer control.

It's certainly ugly, but I don't think we have a real problem here. vma
grabs a reference to the open file at mmap time and we grab a reference to
the underlying gem object. So it shouldn't be possible to observe a
non-NULL dev_mapping while the inode refcount has already reached 0
anywhere we actually care. At least in drm/i915 since we never call
unmap_mapping_range if we know that there's no ptes around pointing at
this specific object (which we accurately keep track of in our fault
handler).

TTM might be different, and it's certainly good to rid us of this code.

  - We ignore inode-i_mapping completely. It is unlikely that a FS uses it
to overwrite inode-i_data for char-devs, but it definitely doesn't
look very nice to ignore it silently.

Tbh I have no idea what the rules are here ... But since core vfs code
uses the filp-f_mapping at mmap time not frobbing inode-i_mapping looks
like the sane to do.

 Regarding legacy drivers: We no longer reset the address_space during
 drm_lastclose() to avoid re-allocating inodes all the time. However,
 legacy UMS drivers are weird and it is not clear to me whether some of the
 old drivers might depend on this (for what reason?), but I remember Daniel
 told me that i810 might.

i915 in gem+ums mode might. i810 is a different level of horror show
entirely, but since it doesn't do gem we can ignore it here.

 
 Tested with nouveau on x86_64.
 
 Signed-off-by: David Herrmann dh.herrm...@gmail.com

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

I guess it makes sense to merge that after your drm vma offset manager
changes with the little pte shootdown helper since that'll reduce the
diff?
-Daniel

 ---
  drivers/gpu/drm/drm_drv.c  |  1 -
  drivers/gpu/drm/drm_fops.c | 24 +++-
  drivers/gpu/drm/drm_stub.c | 12 +++-
  drivers/gpu/drm/i915/i915_gem.c|  4 ++--
  drivers/gpu/drm/nouveau/nouveau_gem.c  |  2 +-
  drivers/gpu/drm/omapdrm/omap_gem.c |  7 ---
  drivers/gpu/drm/qxl/qxl_object.c   |  2 +-
  drivers/gpu/drm/qxl/qxl_ttm.c  |  2 +-
  drivers/gpu/drm/radeon/radeon_object.c |  2 +-
  drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  2 +-
  include/drm/drmP.h |  2 +-
  12 files changed, 27 insertions(+), 35 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index 99fcd7c..9797613 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -232,7 +232,6 @@ int drm_lastclose(struct drm_device * dev)
   !drm_core_check_feature(dev, DRIVER_MODESET))
   drm_dma_takedown(dev);
  
 - dev-dev_mapping = NULL;
   mutex_unlock(dev-struct_mutex);
  
   DRM_DEBUG(lastclose completed\n);
 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 3a24385..6752f59 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -122,8 +122,6 @@ int drm_open(struct inode *inode, struct file *filp)
   struct drm_minor *minor;
   int retcode = 0;
   int need_setup = 0;
 - struct address_space *old_mapping;
 - struct address_space *old_imapping;
  
   minor = idr_find(drm_minors_idr, minor_id);
   if (!minor)
 @@ -137,16 +135,9 @@ int drm_open(struct inode *inode, struct file *filp)
  
   if (!dev-open_count++)
   need_setup = 1;
 - mutex_lock(dev-struct_mutex);
 - old_imapping = inode-i_mapping;
 - old_mapping = dev-dev_mapping;
 - if (old_mapping == NULL)
 - dev-dev_mapping = inode-i_data;
 - /* ihold ensures nobody can remove inode with our i_data */
 - ihold(container_of(dev-dev_mapping, struct inode, i_data));
 - inode-i_mapping = dev-dev_mapping;
 - filp-f_mapping = dev-dev_mapping;
 - mutex_unlock(dev-struct_mutex);
 

Re: Bug in warning message from MTRR rework in uvesafb

[Dave Airlie]

On Thu, Jul 11, 2013 at 3:36 AM, Andy Lutomirski l...@amacapital.net wrote:
 On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
 just.for.l...@googlemail.com wrote:
 Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, uvesafb: Clean up
 MTRR code contains the following change:

 @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
  }
  }

 +if (mtrr != 3  mtrr != 1)
 +pr_warn(uvesafb: mtrr should be set to 0 or 3; %d is
 unsupported, mtrr);
 +
  return 0;
  }
  #endif /* !MODULE */

 Shouldn't this be  mtrr != 0?

 Indeed, and Sylvain Hitier (cc'd) sent a patch (off-list) that must
 have gotten lost somewhere.



Yeah I should get an email reply thing for off-list stuff, as its even
more likely I'll lose it.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: don't call -firstopen for KMS drivers

[Laurent Pinchart]

Hi Daniel,

On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
 It has way too much potential for driver writers to do stupid things
 like delayed hw setup because the load sequence is somehow racy (e.g.
 the imx driver in staging). So don't call it for modesetting drivers,
 which reduces the complexity of the drm core - driver interface a
 notch.
 
 v2: Don't forget to update DocBook.
 
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  Documentation/DocBook/drm.tmpl | 2 ++
  drivers/gpu/drm/drm_fops.c | 3 ++-
  2 files changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 4d54ac8..0e8a5a3 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
 drm_file *);/synopsis para
  The methodnamefirstopen/methodname method is called by the DRM
 core when an application opens a device that has no other opened file
 handle.
 + Not that this callback is only called for legacy ums drm drivers, not
 + for drm drivers that implement modesetting in the kernel.
   Similarly the methodnamelastclose/methodname method is called when
   the last application holding a file handle opened on the device closes
   it. Both methods are mostly used for UMS (User Mode Setting) drivers to

What about

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7d1278e..afa8d40 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);/synopsis
   /abstract
   para
 The methodnamefirstopen/methodname method is called by the DRM core
-   when an application opens a device that has no other opened file handle.
-   Similarly the methodnamelastclose/methodname method is called when
-   the last application holding a file handle opened on the device closes
-   it. Both methods are mostly used for UMS (User Mode Setting) drivers to
-   acquire and release device resources which should be done in the
-   methodnameload/methodname and methodnameunload/methodname
-   methods for KMS drivers.
+   for legacy UMS (User Mode Setting) drivers only when an application
+   opens a device that has no other opened file handle. UMS drivers can
+   implement it to acquire device resources. KMS drivers can't use the
+   method and must acquire resources in the methodnameload/methodname
+   method instead.
   /para
   para
-Note that the methodnamelastclose/methodname method is also called
-   at module unload time or, for hot-pluggable devices, when the device is
-   unplugged. The methodnamefirstopen/methodname and
+   Similarly the methodnamelastclose/methodname method is called when
+   the last application holding a file handle opened on the device closes
+   it, for both UMS and KMS drivers. Additionally, the method is also
+   called at module unload time or, for hot-pluggable devices, when the
+   device is unplugged. The methodnamefirstopen/methodname and
methodnamelastclose/methodname calls can thus be unbalanced.
   /para
   para

 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 57e3014..fcde7d4 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
   int i;
   int ret;
 
 - if (dev-driver-firstopen) {
 + if (dev-driver-firstopen 
 + !drm_core_check_feature(dev, DRIVER_MODESET)) {
   ret = dev-driver-firstopen(dev);
   if (ret != 0)
   return ret;

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: remove cargo-cult locking from map_sg helper

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 10 July 2013 16:48:45 Daniel Vetter wrote:
 I've checked both implementations (radeon/nouveau) and they both grab
 the page array from ttm simply by dereferencing it and then wrapping
 it up with drm_prime_pages_to_sg in the callback and map it with
 dma_map_sg (in the helper).
 
 Only the grabbing of the underlying page array is anything we need to
 be concerned about, and either those pages are pinned independently,
 or we're screwed no matter what.
 
 And indeed, nouveau/radeon pin the backing storage in their
 attach/detach functions.
 
 Since I've created this patch cma prime support for dma_buf was added.
 drm_gem_cma_prime_get_sg_table only calls kzalloc and the createsmaps
 the sg table with dma_get_sgtable. It doesn't touch any gem object
 state otherwise. So the cma helpers also look safe.
 
 The only thing we might claim it does is prevent concurrent mapping of
 dma_buf attachments. But a) that's not allowed and b) the current code
 is racy already since it checks whether the sg mapping exists _before_
 grabbing the lock.
 
 So the dev-struct_mutex locking here does absolutely nothing useful,
 but only distracts. Remove it.
 
 This should also help Maarten's work to eventually pin the backing
 storage more dynamically by preventing locking inversions around
 dev-struct_mutex.
 
 v2: Add analysis for recently added cma helper prime code.
 
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Maarten Lankhorst maarten.lankho...@canonical.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  drivers/gpu/drm/drm_prime.c | 3 ---
  1 file changed, 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
 index 85e450e..64a99b3 100644
 --- a/drivers/gpu/drm/drm_prime.c
 +++ b/drivers/gpu/drm/drm_prime.c
 @@ -167,8 +167,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
 dma_buf_attachment *attach, if (WARN_ON(prime_attach-dir != DMA_NONE))
   return ERR_PTR(-EBUSY);
 
 - mutex_lock(obj-dev-struct_mutex);
 -
   sgt = obj-dev-driver-gem_prime_get_sg_table(obj);
 
   if (!IS_ERR(sgt)) {
 @@ -182,7 +180,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
 dma_buf_attachment *attach, }
   }
 
 - mutex_unlock(obj-dev-struct_mutex);
   return sgt;
  }
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66805] [radeonsi] half life 2 base games are segfaulting

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66805

--- Comment #1 from Michel Dänzer mic...@daenzer.net ---
Can you provide the output from running with the environment variable
RADEON_DUMP_SHADERS=1 ? Beware that it might be large if the game compiles many
shaders before the failure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66425] failed testing IB on ring 5 when suspending to disk

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

  Attachment #81770|0   |1
is obsolete||
  Attachment #82190|0   |1
is obsolete||
  Attachment #82194|0   |1
is obsolete||
  Attachment #82196|0   |1
is obsolete||
  Attachment #82198|0   |1
is obsolete||
  Attachment #82226|0   |1
is obsolete||
  Attachment #82304|0   |1
is obsolete||

--- Comment #20 from Christian König deathsim...@vodafone.de ---
Created attachment 82325
  -- https://bugs.freedesktop.org/attachment.cgi?id=82325action=edit
Possible fix.

I was able to reproduce the problem, and this patch (only a slightly modified
version of the old one) seems to fix it for me.

Please retest and provide new dmesg logs (as far as that is possible).

Also please try it a couple of times, cause at least on my test system
suspend/resume on 3.10 seems to be a bit unstable (even without the radeon
driver).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66425] failed testing IB on ring 5 when suspending to disk

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

--- Comment #21 from Austin Lund austin.l...@gmail.com ---
(In reply to comment #20)
 Created attachment 82325 [details] [review]
 Possible fix.
 
 I was able to reproduce the problem, and this patch (only a slightly
 modified version of the old one) seems to fix it for me.
 
 Please retest and provide new dmesg logs (as far as that is possible).
 
 Also please try it a couple of times, cause at least on my test system
 suspend/resume on 3.10 seems to be a bit unstable (even without the radeon
 driver).

I got this compile warning: 

/home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function
‘radeon_uvd_fini’:
/home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning:
‘return’ with a value, in function returning void [enabled by default]
   return 0;
   ^

Haven't had a chance to test just yet.  Will report back as soon as possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66805] [radeonsi] half life 2 base games are segfaulting

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66805

--- Comment #2 from Laurent carlier lordhea...@gmail.com ---
Created attachment 82327
  -- https://bugs.freedesktop.org/attachment.cgi?id=82327action=edit
shader dump from portal with RADEON_DUMP_SHADERS=1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/gem: simplify object initialization

[David Herrmann]

drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.

Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to keep it
around. This simplifies code paths in drivers, too.

Last but not least, fix gma500 to call drm_gem_object_release() before
freeing objects that were allocated via drm_gem_private_object_init().
That isn't actually necessary for now, but might be in the future.

Cc: Patrik Jakobsson patrik.r.jakobs...@gmail.com
Signed-off-by: David Herrmann dh.herrm...@gmail.com
---
 drivers/gpu/drm/drm_gem.c  | 20 
 drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
 drivers/gpu/drm/gma500/gem.c   |  7 ---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
 drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
 drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
 include/drm/drmP.h |  4 ++--
 7 files changed, 20 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 603f256..1ad9e7e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
 int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
 {
-   BUG_ON((size  (PAGE_SIZE - 1)) != 0);
+   struct file *filp;
 
-   obj-dev = dev;
-   obj-filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
-   if (IS_ERR(obj-filp))
-   return PTR_ERR(obj-filp);
+   filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
+   if (IS_ERR(filp))
+   return PTR_ERR(filp);
 
-   kref_init(obj-refcount);
-   atomic_set(obj-handle_count, 0);
-   obj-size = size;
+   drm_gem_private_object_init(dev, obj, size);
+   obj-filp = filp;
 
return 0;
 }
@@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
  * no GEM provided backing store. Instead the caller is responsible for
  * backing the object and handling it.
  */
-int drm_gem_private_object_init(struct drm_device *dev,
-   struct drm_gem_object *obj, size_t size)
+void drm_gem_private_object_init(struct drm_device *dev,
+struct drm_gem_object *obj, size_t size)
 {
BUG_ON((size  (PAGE_SIZE - 1)) != 0);
 
@@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
kref_init(obj-refcount);
atomic_set(obj-handle_count, 0);
obj-size = size;
-
-   return 0;
 }
 EXPORT_SYMBOL(drm_gem_private_object_init);
 
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 8b1b6d9..362dd2a 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
*dev, int aligned_size)
/* Begin by trying to use stolen memory backing */
backing = psb_gtt_alloc_range(dev, aligned_size, fb, 1);
if (backing) {
-   if (drm_gem_private_object_init(dev,
-   backing-gem, aligned_size) == 0)
-   return backing;
-   psb_gtt_free_range(dev, backing);
+   drm_gem_private_object_init(dev, backing-gem, aligned_size);
+   return backing;
}
return NULL;
 }
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index eefd6cc..fe1d332 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
struct drm_device *dev,
struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, gem, 1);
if (gtt == NULL)
return -ENOMEM;
-   if (drm_gem_private_object_init(dev, gtt-gem, size) != 0)
-   goto free_gtt;
+
+   drm_gem_private_object_init(dev, gtt-gem, size);
if (drm_gem_handle_create(file, gtt-gem, handle) == 0)
return 0;
-free_gtt:
+
+   drm_gem_object_release(gtt-gem);
psb_gtt_free_range(dev, gtt);
return -ENOMEM;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index dc53a52..f2e185c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
goto fail_detach;
}
 
-   ret = drm_gem_private_object_init(dev, obj-base, dma_buf-size);
-   if (ret) {
-   i915_gem_object_free(obj);
-   goto fail_detach;
-   }
-
+   drm_gem_private_object_init(dev, obj-base, dma_buf-size);
i915_gem_object_init(obj, i915_gem_object_dmabuf_ops);

[PATCH 2/2] drm/pci: remove useles #if 1

[David Herrmann]

These don't make any sense, really..

Signed-off-by: David Herrmann dh.herrm...@gmail.com
---
 drivers/gpu/drm/drm_pci.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 80c0b2b..a7b46ff 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -52,10 +52,8 @@
 drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t 
align)
 {
drm_dma_handle_t *dmah;
-#if 1
unsigned long addr;
size_t sz;
-#endif
 
/* pci_alloc_consistent only guarantees alignment to the smallest
 * PAGE_SIZE order which is greater than or equal to the requested size.
@@ -97,10 +95,8 @@ EXPORT_SYMBOL(drm_pci_alloc);
  */
 void __drm_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
 {
-#if 1
unsigned long addr;
size_t sz;
-#endif
 
if (dmah-vaddr) {
/* XXX - Is virt_to_page() legal for consistent mem? */
-- 
1.8.3.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66731] texture issues in xonotic with llvm+sb and offset mapping

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66731

--- Comment #2 from Stefano Teso stefano.t...@gmail.com ---
Thanks for the quick response.

I just wanted to note that the glitch is still there with llvm 3.4 trunk.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: don't call -firstopen for KMS drivers

[Daniel Vetter]

On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Daniel,

 On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
 It has way too much potential for driver writers to do stupid things
 like delayed hw setup because the load sequence is somehow racy (e.g.
 the imx driver in staging). So don't call it for modesetting drivers,
 which reduces the complexity of the drm core - driver interface a
 notch.

 v2: Don't forget to update DocBook.

 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  Documentation/DocBook/drm.tmpl | 2 ++
  drivers/gpu/drm/drm_fops.c | 3 ++-
  2 files changed, 4 insertions(+), 1 deletion(-)

 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 4d54ac8..0e8a5a3 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
 drm_file *);/synopsis para
  The methodnamefirstopen/methodname method is called by the DRM
 core when an application opens a device that has no other opened file
 handle.
 + Not that this callback is only called for legacy ums drm drivers, not
 + for drm drivers that implement modesetting in the kernel.
   Similarly the methodnamelastclose/methodname method is called when
   the last application holding a file handle opened on the device closes
   it. Both methods are mostly used for UMS (User Mode Setting) drivers to

 What about

So if you think we should go overboard I guess it'd be useful to
explain what KMS drivers should and shouldn't do in lastclose:
- Delayed gpu switching with vga switcheroo.
- Restoring of the fbcon, as long as the core is still a bit deficient
in getting rid of mouse cursors and stupid sprite setups when X dies
untimely and leaves dirt behind. Eventually we should be able to get
rid of this though and rely on the magic sysrq to get out of graphics
mode and restore fbcon fully.
- Nothing else, ever, especially resource cleanups.

Can you maybe add a sentence or two to your proposed update for about
this? UMS drivers tend to do a lot of nefarious stuff in lastclose, so
stressing the difference would be good.

Otherwise I like your doc update much more than mine ;-)
-Daniel


 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 7d1278e..afa8d40 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct 
 drm_file *);/synopsis
/abstract
para
  The methodnamefirstopen/methodname method is called by the DRM 
 core
 -   when an application opens a device that has no other opened file 
 handle.
 -   Similarly the methodnamelastclose/methodname method is called when
 -   the last application holding a file handle opened on the device closes
 -   it. Both methods are mostly used for UMS (User Mode Setting) drivers 
 to
 -   acquire and release device resources which should be done in the
 -   methodnameload/methodname and methodnameunload/methodname
 -   methods for KMS drivers.
 +   for legacy UMS (User Mode Setting) drivers only when an application
 +   opens a device that has no other opened file handle. UMS drivers can
 +   implement it to acquire device resources. KMS drivers can't use the
 +   method and must acquire resources in the methodnameload/methodname
 +   method instead.
/para
para
 -Note that the methodnamelastclose/methodname method is also 
 called
 -   at module unload time or, for hot-pluggable devices, when the device 
 is
 -   unplugged. The methodnamefirstopen/methodname and
 +   Similarly the methodnamelastclose/methodname method is called when
 +   the last application holding a file handle opened on the device closes
 +   it, for both UMS and KMS drivers. Additionally, the method is also
 +   called at module unload time or, for hot-pluggable devices, when the
 +   device is unplugged. The methodnamefirstopen/methodname and
 methodnamelastclose/methodname calls can thus be unbalanced.
/para
para

 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 57e3014..fcde7d4 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
   int i;
   int ret;

 - if (dev-driver-firstopen) {
 + if (dev-driver-firstopen 
 + !drm_core_check_feature(dev, DRIVER_MODESET)) {
   ret = dev-driver-firstopen(dev);
   if (ret != 0)
   return ret;

 --
 Regards,

 Laurent Pinchart



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list

Re: [PATCH 1/2] drm/gem: simplify object initialization

[Chris Wilson]

On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
 drm_gem_object_init() and drm_gem_private_object_init() do exactly the
 same (except for shmem alloc) so make the first use the latter to reduce
 code duplication.
 
 Also drop the return code from drm_gem_private_object_init(). It seems
 unlikely that we will extend it any time soon so no reason to keep it
 around. This simplifies code paths in drivers, too.
 
 Last but not least, fix gma500 to call drm_gem_object_release() before
 freeing objects that were allocated via drm_gem_private_object_init().
 That isn't actually necessary for now, but might be in the future.
 
 Cc: Patrik Jakobsson patrik.r.jakobs...@gmail.com
 Signed-off-by: David Herrmann dh.herrm...@gmail.com

You should also CC any driver maintainers that the patch touches. They
should be acking it at the very least.
-Chris

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

Re: [PATCH 1/2] drm/gem: simplify object initialization

[Daniel Vetter]

On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
 drm_gem_object_init() and drm_gem_private_object_init() do exactly the
 same (except for shmem alloc) so make the first use the latter to reduce
 code duplication.
 
 Also drop the return code from drm_gem_private_object_init(). It seems
 unlikely that we will extend it any time soon so no reason to keep it
 around. This simplifies code paths in drivers, too.
 
 Last but not least, fix gma500 to call drm_gem_object_release() before
 freeing objects that were allocated via drm_gem_private_object_init().
 That isn't actually necessary for now, but might be in the future.

Generally commmit messages that have too many also do foo paragraphs
tack on scream for a patch split up ;-) But the diff here is little enough
that it's imo still ok. So for both patches in this series:

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

 
 Cc: Patrik Jakobsson patrik.r.jakobs...@gmail.com
 Signed-off-by: David Herrmann dh.herrm...@gmail.com
 ---
  drivers/gpu/drm/drm_gem.c  | 20 
  drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
  drivers/gpu/drm/gma500/gem.c   |  7 ---
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
  drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
  drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
  include/drm/drmP.h |  4 ++--
  7 files changed, 20 insertions(+), 31 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index 603f256..1ad9e7e 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
  int drm_gem_object_init(struct drm_device *dev,
   struct drm_gem_object *obj, size_t size)
  {
 - BUG_ON((size  (PAGE_SIZE - 1)) != 0);
 + struct file *filp;
  
 - obj-dev = dev;
 - obj-filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
 - if (IS_ERR(obj-filp))
 - return PTR_ERR(obj-filp);
 + filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
 + if (IS_ERR(filp))
 + return PTR_ERR(filp);
  
 - kref_init(obj-refcount);
 - atomic_set(obj-handle_count, 0);
 - obj-size = size;
 + drm_gem_private_object_init(dev, obj, size);
 + obj-filp = filp;
  
   return 0;
  }
 @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
   * no GEM provided backing store. Instead the caller is responsible for
   * backing the object and handling it.
   */
 -int drm_gem_private_object_init(struct drm_device *dev,
 - struct drm_gem_object *obj, size_t size)
 +void drm_gem_private_object_init(struct drm_device *dev,
 +  struct drm_gem_object *obj, size_t size)
  {
   BUG_ON((size  (PAGE_SIZE - 1)) != 0);
  
 @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
   kref_init(obj-refcount);
   atomic_set(obj-handle_count, 0);
   obj-size = size;
 -
 - return 0;
  }
  EXPORT_SYMBOL(drm_gem_private_object_init);
  
 diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
 b/drivers/gpu/drm/gma500/framebuffer.c
 index 8b1b6d9..362dd2a 100644
 --- a/drivers/gpu/drm/gma500/framebuffer.c
 +++ b/drivers/gpu/drm/gma500/framebuffer.c
 @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
 *dev, int aligned_size)
   /* Begin by trying to use stolen memory backing */
   backing = psb_gtt_alloc_range(dev, aligned_size, fb, 1);
   if (backing) {
 - if (drm_gem_private_object_init(dev,
 - backing-gem, aligned_size) == 0)
 - return backing;
 - psb_gtt_free_range(dev, backing);
 + drm_gem_private_object_init(dev, backing-gem, aligned_size);
 + return backing;
   }
   return NULL;
  }
 diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
 index eefd6cc..fe1d332 100644
 --- a/drivers/gpu/drm/gma500/gem.c
 +++ b/drivers/gpu/drm/gma500/gem.c
 @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
 struct drm_device *dev,
   struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, gem, 1);
   if (gtt == NULL)
   return -ENOMEM;
 - if (drm_gem_private_object_init(dev, gtt-gem, size) != 0)
 - goto free_gtt;
 +
 + drm_gem_private_object_init(dev, gtt-gem, size);
   if (drm_gem_handle_create(file, gtt-gem, handle) == 0)
   return 0;
 -free_gtt:
 +
 + drm_gem_object_release(gtt-gem);
   psb_gtt_free_range(dev, gtt);
   return -ENOMEM;
  }
 diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
 b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 index dc53a52..f2e185c 100644
 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
 drm_device *dev,
   goto 

Re: [PATCH v2 02/20] drm/gem: convert to new unified vma manager

[David Herrmann]

Hi

On Sun, Jul 7, 2013 at 7:17 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Use the new vma manager instead of the old hashtable. Also convert all
 drivers to use the new convenience helpers. This drops all the
 (map_list.hash.key  PAGE_SHIFT) non-sense.

 Locking and access-management is exactly the same as before with an
 additional lock inside of the vma-manager, which strictly wouldn't be
 needed for gem.

 v2:
  - rebase on drm-next
  - init nodes via drm_vma_node_reset() in drm_gem.c

I missed the tegra driver and any staging driver. I will fix that in
v3 and reduce the series to a minimum.

Regards
David

 Signed-off-by: David Herrmann dh.herrm...@gmail.com
 ---
  drivers/gpu/drm/drm_gem.c  | 90 
 ++
  drivers/gpu/drm/drm_gem_cma_helper.c   |  9 +--
  drivers/gpu/drm/exynos/exynos_drm_gem.c|  7 ++-
  drivers/gpu/drm/gma500/gem.c   |  8 +--
  drivers/gpu/drm/i915/i915_gem.c|  9 +--
  drivers/gpu/drm/omapdrm/omap_gem.c | 11 ++--
  drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 49 +---
  drivers/gpu/drm/udl/udl_gem.c  |  6 +-
  include/drm/drmP.h |  7 +--
  include/drm/drm_vma_manager.h  |  1 -
  include/uapi/drm/drm.h |  2 +-
  11 files changed, 49 insertions(+), 150 deletions(-)

 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index 603f256..b5db89b 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -37,6 +37,7 @@
  #include linux/shmem_fs.h
  #include linux/dma-buf.h
  #include drm/drmP.h
 +#include drm/drm_vma_manager.h

  /** @file drm_gem.c
   *
 @@ -102,14 +103,9 @@ drm_gem_init(struct drm_device *dev)
 }

 dev-mm_private = mm;
 -
 -   if (drm_ht_create(mm-offset_hash, 12)) {
 -   kfree(mm);
 -   return -ENOMEM;
 -   }
 -
 -   drm_mm_init(mm-offset_manager, DRM_FILE_PAGE_OFFSET_START,
 -   DRM_FILE_PAGE_OFFSET_SIZE);
 +   drm_vma_offset_manager_init(mm-vma_manager,
 +   DRM_FILE_PAGE_OFFSET_START,
 +   DRM_FILE_PAGE_OFFSET_SIZE);

 return 0;
  }
 @@ -119,8 +115,7 @@ drm_gem_destroy(struct drm_device *dev)
  {
 struct drm_gem_mm *mm = dev-mm_private;

 -   drm_mm_takedown(mm-offset_manager);
 -   drm_ht_remove(mm-offset_hash);
 +   drm_vma_offset_manager_destroy(mm-vma_manager);
 kfree(mm);
 dev-mm_private = NULL;
  }
 @@ -141,6 +136,7 @@ int drm_gem_object_init(struct drm_device *dev,

 kref_init(obj-refcount);
 atomic_set(obj-handle_count, 0);
 +   drm_vma_node_reset(obj-vma_node);
 obj-size = size;

 return 0;
 @@ -162,6 +158,7 @@ int drm_gem_private_object_init(struct drm_device *dev,

 kref_init(obj-refcount);
 atomic_set(obj-handle_count, 0);
 +   drm_vma_node_reset(obj-vma_node);
 obj-size = size;

 return 0;
 @@ -306,12 +303,8 @@ drm_gem_free_mmap_offset(struct drm_gem_object *obj)
  {
 struct drm_device *dev = obj-dev;
 struct drm_gem_mm *mm = dev-mm_private;
 -   struct drm_map_list *list = obj-map_list;

 -   drm_ht_remove_item(mm-offset_hash, list-hash);
 -   drm_mm_put_block(list-file_offset_node);
 -   kfree(list-map);
 -   list-map = NULL;
 +   drm_vma_offset_remove(mm-vma_manager, obj-vma_node);
  }
  EXPORT_SYMBOL(drm_gem_free_mmap_offset);

 @@ -331,54 +324,9 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj)
  {
 struct drm_device *dev = obj-dev;
 struct drm_gem_mm *mm = dev-mm_private;
 -   struct drm_map_list *list;
 -   struct drm_local_map *map;
 -   int ret;
 -
 -   /* Set the object up for mmap'ing */
 -   list = obj-map_list;
 -   list-map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
 -   if (!list-map)
 -   return -ENOMEM;
 -
 -   map = list-map;
 -   map-type = _DRM_GEM;
 -   map-size = obj-size;
 -   map-handle = obj;
 -
 -   /* Get a DRM GEM mmap offset allocated... */
 -   list-file_offset_node = drm_mm_search_free(mm-offset_manager,
 -   obj-size / PAGE_SIZE, 0, false);
 -
 -   if (!list-file_offset_node) {
 -   DRM_ERROR(failed to allocate offset for bo %d\n, obj-name);
 -   ret = -ENOSPC;
 -   goto out_free_list;
 -   }

 -   list-file_offset_node = drm_mm_get_block(list-file_offset_node,
 -   obj-size / PAGE_SIZE, 0);
 -   if (!list-file_offset_node) {
 -   ret = -ENOMEM;
 -   goto out_free_list;
 -   }
 -
 -   list-hash.key = list-file_offset_node-start;
 -   ret = drm_ht_insert_item(mm-offset_hash, list-hash);
 -   if (ret) {
 -   DRM_ERROR(failed to add to map hash\n);
 -   goto out_free_mm;
 -   }
 -
 -   

Re: [PATCH 1/2] drm/gem: simplify object initialization

[Patrik Jakobsson]

On Thu, Jul 11, 2013 at 11:56 AM, David Herrmann dh.herrm...@gmail.com wrote:
 drm_gem_object_init() and drm_gem_private_object_init() do exactly the
 same (except for shmem alloc) so make the first use the latter to reduce
 code duplication.

 Also drop the return code from drm_gem_private_object_init(). It seems
 unlikely that we will extend it any time soon so no reason to keep it
 around. This simplifies code paths in drivers, too.

 Last but not least, fix gma500 to call drm_gem_object_release() before
 freeing objects that were allocated via drm_gem_private_object_init().
 That isn't actually necessary for now, but might be in the future.

 Cc: Patrik Jakobsson patrik.r.jakobs...@gmail.com
 Signed-off-by: David Herrmann dh.herrm...@gmail.com
 ---
  drivers/gpu/drm/drm_gem.c  | 20 
  drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
  drivers/gpu/drm/gma500/gem.c   |  7 ---
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
  drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
  drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
  include/drm/drmP.h |  4 ++--
  7 files changed, 20 insertions(+), 31 deletions(-)

 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index 603f256..1ad9e7e 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
  int drm_gem_object_init(struct drm_device *dev,
 struct drm_gem_object *obj, size_t size)
  {
 -   BUG_ON((size  (PAGE_SIZE - 1)) != 0);
 +   struct file *filp;

 -   obj-dev = dev;
 -   obj-filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
 -   if (IS_ERR(obj-filp))
 -   return PTR_ERR(obj-filp);
 +   filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
 +   if (IS_ERR(filp))
 +   return PTR_ERR(filp);

 -   kref_init(obj-refcount);
 -   atomic_set(obj-handle_count, 0);
 -   obj-size = size;
 +   drm_gem_private_object_init(dev, obj, size);
 +   obj-filp = filp;

 return 0;
  }
 @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
   * no GEM provided backing store. Instead the caller is responsible for
   * backing the object and handling it.
   */
 -int drm_gem_private_object_init(struct drm_device *dev,
 -   struct drm_gem_object *obj, size_t size)
 +void drm_gem_private_object_init(struct drm_device *dev,
 +struct drm_gem_object *obj, size_t size)
  {
 BUG_ON((size  (PAGE_SIZE - 1)) != 0);

 @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
 kref_init(obj-refcount);
 atomic_set(obj-handle_count, 0);
 obj-size = size;
 -
 -   return 0;
  }
  EXPORT_SYMBOL(drm_gem_private_object_init);

 diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
 b/drivers/gpu/drm/gma500/framebuffer.c
 index 8b1b6d9..362dd2a 100644
 --- a/drivers/gpu/drm/gma500/framebuffer.c
 +++ b/drivers/gpu/drm/gma500/framebuffer.c
 @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
 *dev, int aligned_size)
 /* Begin by trying to use stolen memory backing */
 backing = psb_gtt_alloc_range(dev, aligned_size, fb, 1);
 if (backing) {
 -   if (drm_gem_private_object_init(dev,
 -   backing-gem, aligned_size) == 0)
 -   return backing;
 -   psb_gtt_free_range(dev, backing);
 +   drm_gem_private_object_init(dev, backing-gem, aligned_size);
 +   return backing;
 }
 return NULL;
  }
 diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
 index eefd6cc..fe1d332 100644
 --- a/drivers/gpu/drm/gma500/gem.c
 +++ b/drivers/gpu/drm/gma500/gem.c
 @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
 struct drm_device *dev,
 struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, gem, 1);
 if (gtt == NULL)
 return -ENOMEM;
 -   if (drm_gem_private_object_init(dev, gtt-gem, size) != 0)
 -   goto free_gtt;
 +
 +   drm_gem_private_object_init(dev, gtt-gem, size);
 if (drm_gem_handle_create(file, gtt-gem, handle) == 0)
 return 0;
 -free_gtt:
 +
 +   drm_gem_object_release(gtt-gem);
 psb_gtt_free_range(dev, gtt);
 return -ENOMEM;
  }
 diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
 b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 index dc53a52..f2e185c 100644
 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
 drm_device *dev,
 goto fail_detach;
 }

 -   ret = drm_gem_private_object_init(dev, obj-base, dma_buf-size);
 -   if (ret) {
 -   i915_gem_object_free(obj);
 - 

Re: [PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)

[David Herrmann]

Hi

On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres martin.pe...@labri.fr wrote:
 On 07/07/2013 19:17, David Herrmann wrote:

 Hi

 This is v2 of the unified VMA offset manager series. The first draft is
 available at LWN [1]. This series replaces the VMA offset managers in GEM
 and
 TTM with a unified implementation.

 The first 4 patches contain the new VMA offset manager and are the only
 patches
 that I propose for mainline inclusion.
 Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar
 patches in i915-next and I will rebase them once it is merged. Ignore
 them if you're not interested.
 Patches 9-19 implement mmap access control. Comments are welcome! They are
 intended for mainline inclusion, too, but probably require some more
 review
 rounds. I'd really appreciate if driver authors could comment on the
 implementation.
 Patch 20 shows the main motivation behind this whole series: render nodes.
 It is
 marked RFC and I will resend once the VMA manager is merged upstream. Feel
 free
 to test it.

 One more note regarding DRM-Master: Render-clients are independent of
 DRM-Master
 (see the DocBook documentation). It really doesn't make sense to
 create/bind a
 DRM-Master object to render-clients. However, a lot of core DRM code
 depends on
   -master != NULL. Drivers need to take care not to call into those core
 modules
 if they implement DRIVER_RENDER.
 I plan on removing multiple-master-support in the next series. So there
 will be
 only one global master and each open-file is bound to it. This will make
 it very
 easy to phase out drm_master. The planned modeset nodes provide a nice
 replacement. If anyone knows a **currently used** use-case for
 multiple-masters,
 please tell me. I couldn't find one that _actually works_.
 (SetMaster+DropMaster
 will obviously stay functional even with drm_master removed).


 (series available at: https://github.com/dvdhrm/linux/tree/rnodes)

 Comments welcome!
 Cheers
 David

 Hi David,

 Thanks for this patchset. I am away from my computers for testing but I was
 wondering if you based your vma rework on Dave's implementation. If so,
 you may have the same bug that I had with it.

 I cannot remember the details of the bug, but I could trigger it by
 rebooting
 kde around 13 times on radeon. I didn't have this problem with Nouveau.

It is based on Dave's code, but I rewrote all of it and fixed several
bugs. For instance, there was a TTM ref-count leak for BOs in TTM core
and a TTM locking issue. I didn't encounter any bugs so far, but I
didn't try to restart the xserver 13 times. I will do some more
stress-tests, but it is quite likely you hit one of those two bugs
with radeon.

 I am not competent to judge this work but I will try to test it and check
 with my security tests that I wrote that the problem is indeed solved
 on nouveau and radeon.

The changes are actually quite simple. I intentionally kept TTM
locking as it was before, even though I think we could reduce it now.
Anyway, I will resend v3 (which now includes tegra and staging) this
weekend. Hopefully we can get it into linux-next soon.

Thanks!
David

 Looking forward to seeing your proposition for the userspace :)

 Cheers,
 Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66450

--- Comment #7 from Christian König deathsim...@vodafone.de ---
Created attachment 82331
  -- https://bugs.freedesktop.org/attachment.cgi?id=82331action=edit
Possible fix v2

Update patch, should work better this time.

But please note that shader based decoding is far away from beeing perfect
either.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/gem: simplify object initialization

[Rob Clark]

On Thu, Jul 11, 2013 at 5:56 AM, David Herrmann dh.herrm...@gmail.com wrote:
 drm_gem_object_init() and drm_gem_private_object_init() do exactly the
 same (except for shmem alloc) so make the first use the latter to reduce
 code duplication.

 Also drop the return code from drm_gem_private_object_init(). It seems
 unlikely that we will extend it any time soon so no reason to keep it
 around. This simplifies code paths in drivers, too.

 Last but not least, fix gma500 to call drm_gem_object_release() before
 freeing objects that were allocated via drm_gem_private_object_init().
 That isn't actually necessary for now, but might be in the future.

 Cc: Patrik Jakobsson patrik.r.jakobs...@gmail.com
 Signed-off-by: David Herrmann dh.herrm...@gmail.com

Acked-by: Rob Clark robdcl...@gmail.com

 ---
  drivers/gpu/drm/drm_gem.c  | 20 
  drivers/gpu/drm/gma500/framebuffer.c   |  6 ++
  drivers/gpu/drm/gma500/gem.c   |  7 ---
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  7 +--
  drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +---
  drivers/gpu/drm/omapdrm/omap_gem.c |  3 ++-
  include/drm/drmP.h |  4 ++--
  7 files changed, 20 insertions(+), 31 deletions(-)

 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index 603f256..1ad9e7e 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
  int drm_gem_object_init(struct drm_device *dev,
 struct drm_gem_object *obj, size_t size)
  {
 -   BUG_ON((size  (PAGE_SIZE - 1)) != 0);
 +   struct file *filp;

 -   obj-dev = dev;
 -   obj-filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
 -   if (IS_ERR(obj-filp))
 -   return PTR_ERR(obj-filp);
 +   filp = shmem_file_setup(drm mm object, size, VM_NORESERVE);
 +   if (IS_ERR(filp))
 +   return PTR_ERR(filp);

 -   kref_init(obj-refcount);
 -   atomic_set(obj-handle_count, 0);
 -   obj-size = size;
 +   drm_gem_private_object_init(dev, obj, size);
 +   obj-filp = filp;

 return 0;
  }
 @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
   * no GEM provided backing store. Instead the caller is responsible for
   * backing the object and handling it.
   */
 -int drm_gem_private_object_init(struct drm_device *dev,
 -   struct drm_gem_object *obj, size_t size)
 +void drm_gem_private_object_init(struct drm_device *dev,
 +struct drm_gem_object *obj, size_t size)
  {
 BUG_ON((size  (PAGE_SIZE - 1)) != 0);

 @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
 kref_init(obj-refcount);
 atomic_set(obj-handle_count, 0);
 obj-size = size;
 -
 -   return 0;
  }
  EXPORT_SYMBOL(drm_gem_private_object_init);

 diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
 b/drivers/gpu/drm/gma500/framebuffer.c
 index 8b1b6d9..362dd2a 100644
 --- a/drivers/gpu/drm/gma500/framebuffer.c
 +++ b/drivers/gpu/drm/gma500/framebuffer.c
 @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
 *dev, int aligned_size)
 /* Begin by trying to use stolen memory backing */
 backing = psb_gtt_alloc_range(dev, aligned_size, fb, 1);
 if (backing) {
 -   if (drm_gem_private_object_init(dev,
 -   backing-gem, aligned_size) == 0)
 -   return backing;
 -   psb_gtt_free_range(dev, backing);
 +   drm_gem_private_object_init(dev, backing-gem, aligned_size);
 +   return backing;
 }
 return NULL;
  }
 diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
 index eefd6cc..fe1d332 100644
 --- a/drivers/gpu/drm/gma500/gem.c
 +++ b/drivers/gpu/drm/gma500/gem.c
 @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, 
 struct drm_device *dev,
 struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, gem, 1);
 if (gtt == NULL)
 return -ENOMEM;
 -   if (drm_gem_private_object_init(dev, gtt-gem, size) != 0)
 -   goto free_gtt;
 +
 +   drm_gem_private_object_init(dev, gtt-gem, size);
 if (drm_gem_handle_create(file, gtt-gem, handle) == 0)
 return 0;
 -free_gtt:
 +
 +   drm_gem_object_release(gtt-gem);
 psb_gtt_free_range(dev, gtt);
 return -ENOMEM;
  }
 diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
 b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 index dc53a52..f2e185c 100644
 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
 @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
 drm_device *dev,
 goto fail_detach;
 }

 -   ret = drm_gem_private_object_init(dev, obj-base, dma_buf-size);
 -   if (ret) {
 -

Re: [PULL] drm-intel-fixes

[Daniel Vetter]

Cc lists this time around ...
-Daniel

On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter dan...@ffwll.ch wrote:
 Hi Dave,

 One feature latecomer, I've forgotten to merge the patch to reeanble the
 Haswell power well feature now that the audio interaction is fixed up.
 Since that was the only unfixed issue with it I've figured I could throw
 it in a bit late, and it's trivial to revert in case I'm wrong.

 Otherwise all bug/regression fixes:
 - Fix status page reinit after gpu hangs, spotted by more paranoid igt
   checks.
 - Fix object list walking fumble regression in the shrinker (only the
   counting part, the actual shrinking code was correct so no Oops
   potential), from Xiong Zhang.
 - Fix DP 1.2 bw limits (Imre).
 - Restore legacy forcewake on ivb, too many broken biosen out there. We
   dump a warn though that recent userspace might fall over with that
   config (Guenter Roeck).
 - Patch up the gen2 cs tlb w/a.
 - Improve the fence coherency w/a now that we have a better understanding
   what's going on. The removed wbinvd+ipi should make -rt folks happy. Big
   thanks to Jon Bloomfield for figuring this out, patches from Chris.
 - Fix write-read race when switching ring (Chris). Spotted with code
   inspection, but now we also have an igt for it.

 There's an ugly regression we're still working on introduced between
 3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since
 that one fixes another regression :( I've asked Steven to include my
 -fixes branch into linux-next to prevent such fallout in the future,
 hopefully.

 Otherwise pretty calm thus far.

 Cheers, Daniel

 The following changes since commit 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e:

   drm/i915: Don't try to tear down the stolen drm_mm if it's not there 
 (2013-07-02 11:47:19 +0200)

 are available in the git repository at:

   git://people.freedesktop.org/~danvet/drm-intel 
 tags/drm-intel-fixes-2013-07-11

 for you to fetch changes up to 46a0b638f35b45fc13d3dc0deb6a7e17988170b2:

   Revert drm/i915: Workaround incoherence between fences and LLC across 
 multiple CPUs (2013-07-10 15:31:12 +0200)

 
 Chris Wilson (3):
   drm/i915: Fix write-read race with multiple rings
   drm/i915: Fix incoherence with fence updates on Sandybridge+
   Revert drm/i915: Workaround incoherence between fences and LLC across 
 multiple CPUs

 Daniel Vetter (2):
   drm/i915: reinit status page registers after gpu reset
   drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a

 Guenter Roeck (1):
   Partially revert drm/i915: unconditionally use mt forcewake on hsw/ivb

 Imre Deak (1):
   drm/i915: fix lane bandwidth capping for DP 1.2 sinks

 Paulo Zanoni (1):
   drm/i915: switch disable_power_well default value to 1

 Xiong Zhang (1):
   drm/i915: Correct obj-mm_list link to 
 dev_priv-dev_priv-mm.inactive_list

  drivers/gpu/drm/i915/i915_drv.c |  4 +-
  drivers/gpu/drm/i915/i915_gem.c | 83 
 +
  drivers/gpu/drm/i915/intel_dp.c |  5 ++
  drivers/gpu/drm/i915/intel_pm.c | 31 +++-
  drivers/gpu/drm/i915/intel_ringbuffer.c | 38 +--
  5 files changed, 93 insertions(+), 68 deletions(-)
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon HD 6310 (AMD Wrestler): [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[Alex Deucher]

On Thu, Jul 11, 2013 at 3:41 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Dear Linux folks,


 using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged
 and built with `make deb-pkg`, it failed the last boot.

 [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

 The strange thing is that it worked the last time I tried with the same
 Linux kernel image as I posted to the list [1]. I just booted an old
 3.2.46 distribution Linux in between. (And it looked like the
 modesetting did not work when doing so. But I did not look further into
 it.)


Make sure you have the updated rlc and uvd ucode installed and that
the correct ucode is being used in your initrd, etc.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66425] failed testing IB on ring 5 when suspending to disk

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

--- Comment #22 from Christian König deathsim...@vodafone.de ---
(In reply to comment #21)
 I got this compile warning: 
 
 /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function
 ‘radeon_uvd_fini’:
 /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning:
 ‘return’ with a value, in function returning void [enabled by default]
return 0;
^

Just a stupid typo, going to fix that before I send it out to the list.

 Haven't had a chance to test just yet.  Will report back as soon as possible.

That would be greate, cause it's actually a quite serious bug.

I'm currently also locking into the other stability issues with 3.10, but can't
(yet) say if it's radeons fault or not.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Questions about TTM buffer object maping

[Jerome Glisse]

On Thu, Jul 11, 2013 at 2:24 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
 On Wed, Jul 10, 2013 at 8:27 PM, Jean-Sébastien Pédron
 jean-sebastien.ped...@dumbbell.fr wrote:
  Hello,
 
  I'm trying to understand how TTM buffer object mapping works on Linux, to
  make this behave properly on FreeBSD.
 
  Here's what I think I understand:
 
  When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's 
  a
  page fault, the page is looked up and inserted in the VMA using
  vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is
  called, which drops a reference. When the last reference is dropped, the
  buffer object is destroyed.
 
  What's still not clear to me is how munmap() works here. After talking 
  about
  this on IRC with some people, I think that unmap_mapping_range() (called by
  ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from
  userland. Is that true?

 Yes that's true.

 Afaik unmap_mapping_range only kills the ptes and doesn't remove the vma.
 So not equivalent to a munmap from userspace. It simply allows us to
 intercept the next access in the page fault handler and move the buffer
 back into place.
 -Daniel

Yes, i was talking from a page point of view, ie page no longer have
mapping and can
be free.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/39] clean out drm cruft and hide it better for kms drivers

[Alex Deucher]

On Wed, Jul 10, 2013 at 8:11 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Hi all,

 I've figured that it's again time for a bit of (late) drm spring cleanup. This
 series here consists of a pile of rip old stuff out patches interleaved with
 disable old cruft for kms drivers and hide it better.

 Comments, flames and review highly welcome. I'd be especially happy if the arm
 guys could check whether I haven't badly broken their drivers - 
 compile-testing
 arm is a pita, so I haven't yet done that.

 There's a few driver-wide patches included, but the more invasive ones (i.e.
 changing more than the drm driver vtable) are split out per-driver for easier
 merging. If no one screams my plan is to rebase this pile on top of -rc1, give
 it some more testing (check arm, ugh) and then send a pull request to Dave.
 That should reduce interference with ongoing driver work as much as possible I
 hope.

 My drm cruft todo list still has a pile of ideas, but I've figured I need to
 stop now for 3.12. For those interested further cleanups could include:

 - setversion/set_busid: All drm core version 1.1 is legacy cruft, kms drivers
   should never run in this mode. We could clean up the setversion ioclt (and
   move the drm core version handling into a legacy function) and set up the 
 bus
   id unconditionally at driver load time.

 - There's a few more legacy ioctls/subsystems that could be blocked out for 
 kms
   drivers (but the required git history digging tends to be tedious). Also I
   think we could more aggressively move legacy cruft setup/teardown code
   out-of-line from the main code by extracting it into drm_legacy_ functions
   (like this series here already does for the context and dma stuff).

 - I think creating a drm_internal.h header for functions not exported to 
 drivers
   would be useful. That way we could move all the legacy functions out of 
 drmP.h
   (which are a lot of them), which should make it much clearer what the real 
 drm
   driver interface actually is.

 - drm_os_linux.h should just die in fire.

 - There's a pile of needless indirection around our agp handling, we duplicate
   the agp core's CONFIG_AGP=n no-oping function handling in large parts, among
   other stuff.

 - The drm coherent dma alloc helpers could get ripped out, at least for kms
   drivers. For ums drivers there's some funny cases where this mapping is
   exchanged with userspace for e.g. register access. In a least one case
   (i810.ko) userspace even sets up that mapping, which allows it to crash the
   kernel at will (since those maps aren't refcounted). Maybe we need to shovel
   those interfaces into a drm_legacy.ko module to keep them around but make 
 sure
   that no new driver even thinks about using them.

 - There's also the matter of the vblank support code, imo that should be split
   int a ums and a kms part. That'd would allow us to use struct drm_crtc * in
   interfaces and proper locking (by grabbing crtc-mutex to exclude races with
   dpms/modesets).

 If anyone wants to dig around in those areas please poke me.


For the series:

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 Cheers, Daniel

 Daniel Vetter (39):
   drm: remove drm_modctx ioctl and use drm_noop instead
   drm: kill dev-context_wait
   drm: remove dev-last_switch
   drm: kill dev-interrupt_flag and dev-dma_flag
   drm: kill dev-ctx_start and dev-lck_start
   drm/radoen: kill radeon_dma_ioctl_kms
   drm: kill dev-buf_readers and dev-buf_writers
   drm: remove redundant clears from drm_setup
   drm/omap: kill firstopen callback
   drm/radeon: kill firstopen callback for kms driver
   drm/imx: kill firstopen callback
   drm/vmwgfx: remove -firstopen callback
   drm: don't call -firstopen for KMS drivers
   drm: kill dev-driver-set_version
   drm/radeon: remove DRIVER_HAS_DMA/SG/PCI_DMA from the kms driver
   drm: fold in drm_sg_alloc into the ioctl
   drm: hide legacy sg cleanup better from common code
   drm: disallow legacy sg ioctls for modesetting drivers
   drm: mark dma setup/teardown as legacy systems
   drm/nouveau: drop DRIVER_PCI_DMA and DRIVER_SG
   drm: disallow legacy dma ioctls for modesetting drivers
   drm: move drm_getsarea into drm_bufs.c
   drm/bufs: s/drm_order/order_base_2/
   drm/r128: s/drm_order/order_base_2/
   drm/radeon: s/drm_order/order_base_2/
   drm: remove drm_order
   drm: mark context support as a legacy subsystem
   drm/vmwgfx: remove redundant clearing of driver-dma_quiescent
   drm: remove FASYNC support
   drm: rip out DRIVER_FB_DMA and related code
   drm: rip out a few unused DRIVER flags
   drm: remove a bunch of unused #defines from drmP.h
   drm: rip out drm_core_has_MTRR checks
   drm: remove the dma_ioctl special-case
   drm/memory: don't export agp helpers
   drm: hollow-out GET_CLIENT ioctl
   drm: no-op out GET_STATS ioctl
   drm: fix locking in gem debugfs/procfs file
   drm: remove procfs code, take 2

  drivers/gpu/drm/Makefile |   2 +-
  

[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=44772

Harald Judt h.j...@gmx.at changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Harald Judt h.j...@gmx.at ---
Reopened because it happens with 3.10 now even with pm_async set to 0. It
happens with older kernel releases too when pm_async is set to 0, but is much
harder to reproduce.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66425] failed testing IB on ring 5 when suspending to disk

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66425

--- Comment #23 from Harald Judt h.j...@gmx.at ---
Thanks, I confirm that the patch fixes the problem!

I've tested this at least 5 times with both the vanilla and the tuxonice
hibernation, and both now work pretty stable with 3.10. (As a side note: The
BFQ IO scheduler patch makes my system hang when suspending, but that is a
different issue and really not a concern for this bug report.)

Now I'm still plagued by bug #44772, which is similar in that it only happens
when resuming from hibernation, not when suspending, and it seems to occur much
more often with 3.10 with pm_async=0 than before.

As far as my machine is concerned, I consider this solved and 3.10 has become
usable for me. Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=44772

Harald Judt h.j...@gmx.at changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |MOVED

--- Comment #12 from Harald Judt h.j...@gmx.at ---
Just for reference: Since I've never got a response here, I've opened a bug
report at kernel bugzilla in the hope of someone helping me collect more debug
data: https://bugzilla.kernel.org/show_bug.cgi?id=57381

Since everything's documented there, I'll finally close this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.

A version of this patch should also go to stable kernels.

Tested-by: J.N. golden.flee...@gmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon_asic.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = r600_copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = r600_copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = r600_copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = r600_copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = r600_copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = r600_copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/radeon: implement bo copy callback using CP DMA (v2)

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Lighter weight than using the 3D engine.

v2: fix ring count

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/r600.c|   81 ++
 drivers/gpu/drm/radeon/r600d.h   |1 +
 drivers/gpu/drm/radeon/radeon_asic.h |3 +
 3 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2d3655f..f7d494f 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3145,6 +3145,87 @@ int r600_copy_blit(struct radeon_device *rdev,
 }
 
 /**
+ * r600_copy_cpdma - copy pages using the CP DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the CP DMA engine (r6xx+).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int r600_copy_cpdma(struct radeon_device *rdev,
+   uint64_t src_offset, uint64_t dst_offset,
+   unsigned num_gpu_pages,
+   struct radeon_fence **fence)
+{
+   struct radeon_semaphore *sem = NULL;
+   int ring_index = rdev-asic-copy.blit_ring_index;
+   struct radeon_ring *ring = rdev-ring[ring_index];
+   u32 size_in_bytes, cur_size_in_bytes, tmp;
+   int i, num_loops;
+   int r = 0;
+
+   r = radeon_semaphore_create(rdev, sem);
+   if (r) {
+   DRM_ERROR(radeon: moving bo (%d).\n, r);
+   return r;
+   }
+
+   size_in_bytes = (num_gpu_pages  RADEON_GPU_PAGE_SHIFT);
+   num_loops = DIV_ROUND_UP(size_in_bytes, 0x1f);
+   r = radeon_ring_lock(rdev, ring, num_loops * 6 + 21);
+   if (r) {
+   DRM_ERROR(radeon: moving bo (%d).\n, r);
+   radeon_semaphore_free(rdev, sem, NULL);
+   return r;
+   }
+
+   if (radeon_fence_need_sync(*fence, ring-idx)) {
+   radeon_semaphore_sync_rings(rdev, sem, (*fence)-ring,
+   ring-idx);
+   radeon_fence_note_sync(*fence, ring-idx);
+   } else {
+   radeon_semaphore_free(rdev, sem, NULL);
+   }
+
+   for (i = 0; i  num_loops; i++) {
+   cur_size_in_bytes = size_in_bytes;
+   if (cur_size_in_bytes  0x1f)
+   cur_size_in_bytes = 0x1f;
+   size_in_bytes -= cur_size_in_bytes;
+   tmp = upper_32_bits(src_offset)  0xff;
+   if (size_in_bytes == 0)
+   tmp |= PACKET3_CP_DMA_CP_SYNC;
+   radeon_ring_write(ring, PACKET3(PACKET3_CP_DMA, 4));
+   radeon_ring_write(ring, src_offset  0x);
+   radeon_ring_write(ring, tmp);
+   radeon_ring_write(ring, dst_offset  0x);
+   radeon_ring_write(ring, upper_32_bits(dst_offset)  0xff);
+   radeon_ring_write(ring, cur_size_in_bytes);
+   src_offset += cur_size_in_bytes;
+   dst_offset += cur_size_in_bytes;
+   }
+   radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
+   radeon_ring_write(ring, (WAIT_UNTIL - PACKET3_SET_CONFIG_REG_OFFSET)  
2);
+   radeon_ring_write(ring, WAIT_CP_DMA_IDLE_bit);
+
+   r = radeon_fence_emit(rdev, fence, ring-idx);
+   if (r) {
+   radeon_ring_unlock_undo(rdev, ring);
+   return r;
+   }
+
+   radeon_ring_unlock_commit(rdev, ring);
+   radeon_semaphore_free(rdev, sem, *fence);
+
+   return r;
+}
+
+/**
  * r600_copy_dma - copy pages using the DMA engine
  *
  * @rdev: radeon_device pointer
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index f1b3084..8e3fe81 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -602,6 +602,7 @@
 #defineL2_BUSY (1  0)
 
 #defineWAIT_UNTIL  0x8040
+#define WAIT_CP_DMA_IDLE_bit(1  8)
 #define WAIT_2D_IDLE_bit(1  14)
 #define WAIT_3D_IDLE_bit(1  15)
 #define WAIT_2D_IDLECLEAN_bit   (1  16)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 45d0693..b04b578 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -340,6 +340,9 @@ int r600_uvd_ring_test(struct radeon_device *rdev, struct 
radeon_ring *ring);
 int r600_copy_blit(struct radeon_device *rdev,
   uint64_t src_offset, uint64_t dst_offset,
   unsigned num_gpu_pages, struct radeon_fence **fence);
+int r600_copy_cpdma(struct radeon_device 

Re: [PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx

[Alex Deucher]

On Thu, Jul 11, 2013 at 3:59 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:

 Alex,

 Can you please share some details about the nature or symptom of the
 instability. One problem that I have been seeing on my end is that when I
 use the DMA ring intensively (by intensively I mean, calling the copy
 function every frame), combined with some 3D rendering that causes a lot of
 cs_ioctl calls, that I can provoke a corruption of the olist field in
 radeon_sa_bo structure, consequently causing an oops in
 radeon_sa_bo_try_free(). I have also found that I can suppress the problem
 if I add some padding fields at the beginnig of the radeon_sa_bo structure
 (essentially moving the olist field down).

 So I speculate that the use of DMA somehow results in corrupting that
 structure, but I have not yet done enough experiments to prove or disprove
 that theory (so I have not spoke up yet). Also my kernel is full of my own
 internal hacks, and I have not yet taken the time to reproduce the problem
 with the stock kernel. However, after seeing your patch series, I am
 wondering if the instability you are referring to may be of the same or
 similar nature.

Basically using the DMA engine on r6xx seems to lead to hangs on
certain chips when the bo copy callback gets triggered a lot (e.g., a
web page with lots of images, etc.).  Switching back to the 3D engine
fixes the issue.  R6xx was the first asic family with the async dma
engines, so there are likely some hw bugs at play.  Unfortunately, the
hw guys haven't looked at 6xx in probably 8 years, so I don't hold out
much chance of getting to the root of the problem at this point.

Alex


 thanks,

 Ilija



 On Thu, 11 Jul 2013, alexdeuc...@gmail.com wrote:

 From: Alex Deucher alexander.deuc...@amd.com

 They still seem to cause instability on some r6xx parts.
 As a follow up, we can switch to using CP DMA for bo
 moves on r6xx as a lighter weight alternative to using
 the 3D engine.

 A version of this patch should also go to stable kernels.

 Tested-by: J.N. golden.flee...@gmail.com
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
 drivers/gpu/drm/radeon/radeon_asic.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
 b/drivers/gpu/drm/radeon/radeon_asic.c
 index 0970774..ea5c52b 100644
 --- a/drivers/gpu/drm/radeon/radeon_asic.c
 +++ b/drivers/gpu/drm/radeon/radeon_asic.c
 @@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
 .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
 .dma = r600_copy_dma,
 .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
 -   .copy = r600_copy_dma,
 -   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
 +   .copy = r600_copy_blit,
 +   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
 },
 .surface = {
 .set_reg = r600_set_surface_reg,
 @@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
 .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
 .dma = r600_copy_dma,
 .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
 -   .copy = r600_copy_dma,
 -   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
 +   .copy = r600_copy_blit,
 +   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
 },
 .surface = {
 .set_reg = r600_set_surface_reg,
 @@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
 .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
 .dma = r600_copy_dma,
 .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
 -   .copy = r600_copy_dma,
 -   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
 +   .copy = r600_copy_blit,
 +   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
 },
 .surface = {
 .set_reg = r600_set_surface_reg,
 --
 1.7.7.5

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx

[Ilija Hadzic]

Alex,

Can you please share some details about the nature or symptom of the 
instability. One problem that I have been seeing on my end is that when 
I use the DMA ring intensively (by intensively I mean, calling the copy 
function every frame), combined with some 3D rendering that causes a lot 
of cs_ioctl calls, that I can provoke a corruption of the olist field in 
radeon_sa_bo structure, consequently causing an oops in 
radeon_sa_bo_try_free(). I have also found that I can suppress the problem 
if I add some padding fields at the beginnig of the radeon_sa_bo structure 
(essentially moving the olist field down).


So I speculate that the use of DMA somehow results in corrupting that 
structure, but I have not yet done enough experiments to prove or disprove 
that theory (so I have not spoke up yet). Also my kernel is full of my own 
internal hacks, and I have not yet taken the time to reproduce the problem 
with the stock kernel. However, after seeing your patch series, I am 
wondering if the instability you are referring to may be of the same 
or similar nature.


thanks,

Ilija


On Thu, 11 Jul 2013, alexdeuc...@gmail.com wrote:


From: Alex Deucher alexander.deuc...@amd.com

They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.

A version of this patch should also go to stable kernels.

Tested-by: J.N. golden.flee...@gmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/radeon_asic.c |   12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = r600_copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = r600_copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = r600_copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = r600_copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-   .copy = r600_copy_dma,
-   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+   .copy = r600_copy_blit,
+   .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66450

--- Comment #8 from Eugene Shalygin eugene.shalygin+bugzilla@gmail.com ---
With this patch playback works. Thank you!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61470] Driver does not turn on LCD backlight on resume

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61470

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Alex Deucher ag...@yahoo.com ---


*** This bug has been marked as a duplicate of bug 43829 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=43829

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 CC||webmas...@jamescobban.net

--- Comment #25 from Alex Deucher ag...@yahoo.com ---
*** Bug 61470 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=43829

--- Comment #26 from Alex Deucher ag...@yahoo.com ---
Created attachment 82347
  -- https://bugs.freedesktop.org/attachment.cgi?id=82347action=edit
possible fix

Does the attached patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/radeon: add fault decode function for cayman/TN (v2)

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.

v2: simplify fault decoding

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Christian König christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/evergreen.c |   10 ++-
 drivers/gpu/drm/radeon/ni.c|  161 
 drivers/gpu/drm/radeon/nid.h   |   16 
 3 files changed, 185 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 9e14007..bc6936a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -139,6 +139,8 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev);
 void evergreen_program_aspm(struct radeon_device *rdev);
 extern void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
 int ring, u32 cp_int_cntl);
+extern void cayman_vm_decode_fault(struct radeon_device *rdev,
+  u32 status, u32 addr);
 
 static const u32 evergreen_golden_registers[] =
 {
@@ -4629,6 +4631,7 @@ int evergreen_irq_process(struct radeon_device *rdev)
bool queue_hotplug = false;
bool queue_hdmi = false;
bool queue_thermal = false;
+   u32 status, addr;
 
if (!rdev-ih.enabled || rdev-shutdown)
return IRQ_NONE;
@@ -4915,11 +4918,14 @@ restart_ih:
break;
case 146:
case 147:
+   addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
+   status = RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS);
dev_err(rdev-dev, GPU fault detected: %d 0x%08x\n, 
src_id, src_data);
dev_err(rdev-dev,   VM_CONTEXT1_PROTECTION_FAULT_ADDR 
  0x%08X\n,
-   RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
+   addr);
dev_err(rdev-dev,   
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n,
-   RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
+   status);
+   cayman_vm_decode_fault(rdev, status, addr);
/* reset addr and status */
WREG32_P(VM_CONTEXT1_CNTL2, 1, ~1);
break;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 465b17e..56bd4f3 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2450,6 +2450,167 @@ void cayman_vm_fini(struct radeon_device *rdev)
 {
 }
 
+/**
+ * cayman_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (cayman/TN).
+ */
+void cayman_vm_decode_fault(struct radeon_device *rdev,
+   u32 status, u32 addr)
+{
+   u32 mc_id = (status  MEMORY_CLIENT_ID_MASK)  MEMORY_CLIENT_ID_SHIFT;
+   u32 vmid = (status  FAULT_VMID_MASK)  FAULT_VMID_SHIFT;
+   u32 protections = (status  PROTECTIONS_MASK)  PROTECTIONS_SHIFT;
+   char *block;
+
+   switch (mc_id) {
+   case 32:
+   case 16:
+   case 96:
+   case 80:
+   case 160:
+   case 144:
+   case 224:
+   case 208:
+   block = CB;
+   break;
+   case 33:
+   case 17:
+   case 97:
+   case 81:
+   case 161:
+   case 145:
+   case 225:
+   case 209:
+   block = CB_FMASK;
+   break;
+   case 34:
+   case 18:
+   case 98:
+   case 82:
+   case 162:
+   case 146:
+   case 226:
+   case 210:
+   block = CB_CMASK;
+   break;
+   case 35:
+   case 19:
+   case 99:
+   case 83:
+   case 163:
+   case 147:
+   case 227:
+   case 211:
+   block = CB_IMMED;
+   break;
+   case 36:
+   case 20:
+   case 100:
+   case 84:
+   case 164:
+   case 148:
+   case 228:
+   case 212:
+   block = DB;
+   break;
+   case 37:
+   case 21:
+   case 101:
+   case 85:
+   case 165:
+   case 149:
+   case 229:
+   case 213:
+   block = DB_HTILE;
+   break;
+   case 38:
+   case 22:
+   case 102:
+   case 86:
+   case 166:
+   case 150:
+   case 230:
+   case 214:
+   block = SX;
+   break;
+   case 39:
+   case 23:
+   case 103:
+   case 87:
+   case 167:
+   case 151:
+   case 231:
+   case 215:
+   block = DB_STEN;
+   break;
+   case 40:
+   case 24:
+   case 104:
+   case 88:
+   

[PATCH 2/3] drm/radeon: add fault decode function for SI (v2)

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.

v2: simplify fault decoding

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Christian König christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/si.c  |  272 +-
 drivers/gpu/drm/radeon/sid.h |   14 ++
 2 files changed, 284 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index f305768..d3f0507 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4390,6 +4390,270 @@ void si_vm_fini(struct radeon_device *rdev)
 }
 
 /**
+ * si_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (SI).
+ */
+static void si_vm_decode_fault(struct radeon_device *rdev,
+  u32 status, u32 addr)
+{
+   u32 mc_id = (status  MEMORY_CLIENT_ID_MASK)  MEMORY_CLIENT_ID_SHIFT;
+   u32 vmid = (status  FAULT_VMID_MASK)  FAULT_VMID_SHIFT;
+   u32 protections = (status  PROTECTIONS_MASK)  PROTECTIONS_SHIFT;
+   char *block;
+
+   if (rdev-family == CHIP_TAHITI) {
+   switch (mc_id) {
+   case 160:
+   case 144:
+   case 96:
+   case 80:
+   case 224:
+   case 208:
+   case 32:
+   case 16:
+   block = CB;
+   break;
+   case 161:
+   case 145:
+   case 97:
+   case 81:
+   case 225:
+   case 209:
+   case 33:
+   case 17:
+   block = CB_FMASK;
+   break;
+   case 162:
+   case 146:
+   case 98:
+   case 82:
+   case 226:
+   case 210:
+   case 34:
+   case 18:
+   block = CB_CMASK;
+   break;
+   case 163:
+   case 147:
+   case 99:
+   case 83:
+   case 227:
+   case 211:
+   case 35:
+   case 19:
+   block = CB_IMMED;
+   break;
+   case 164:
+   case 148:
+   case 100:
+   case 84:
+   case 228:
+   case 212:
+   case 36:
+   case 20:
+   block = DB;
+   break;
+   case 165:
+   case 149:
+   case 101:
+   case 85:
+   case 229:
+   case 213:
+   case 37:
+   case 21:
+   block = DB_HTILE;
+   break;
+   case 167:
+   case 151:
+   case 103:
+   case 87:
+   case 231:
+   case 215:
+   case 39:
+   case 23:
+   block = DB_STEN;
+   break;
+   case 72:
+   case 68:
+   case 64:
+   case 8:
+   case 4:
+   case 0:
+   case 136:
+   case 132:
+   case 128:
+   case 200:
+   case 196:
+   case 192:
+   block = TC;
+   break;
+   case 112:
+   case 48:
+   block = CP;
+   break;
+   case 49:
+   case 177:
+   case 50:
+   case 178:
+   block = SH;
+   break;
+   case 53:
+   case 190:
+   block = VGT;
+   break;
+   case 117:
+   block = IH;
+   break;
+   case 51:
+   case 115:
+   block = RLC;
+   break;
+   case 119:
+   case 183:
+   block = DMA0;
+   break;
+   case 61:
+   block = DMA1;
+   break;
+   case 248:
+   case 120:
+   block = HDP;
+   break;
+   default:
+   block = unknown;
+   break;
+   }
+   } else {
+   switch (mc_id) {
+   case 32:
+   case 16:
+   case 96:
+   case 80:
+   case 160:
+   case 144:
+ 

Re: Questions about TTM buffer object maping

[Jerome Glisse]

On Thu, Jul 11, 2013 at 5:43 PM, Jean-Sébastien Pédron
jean-sebastien.ped...@dumbbell.fr wrote:
 Hi,

 Thank you Jérôme and Daniel for your input, that's really helpful!

 I have another question: in ttm_bo_mmap(), a reference to the buffer object
 is acquired at the beginning of the function. Another reference is acquired
 in ttm_bo_vm_open() (released in ttm_bo_vm_close()).

 But where is the first reference released?

 --
 Jean-Sébastien Pédron

the ttm_bo_vm_open is not call on first time a vma is mmap, ie when
userspace do mmap it call driver
mmap callback which call ttm_bo_mmap but ttm_bo_vm_open is never call.
If the same process or
another process mmap the same area or subarea the ttm_bo_vm_open is
call. Then on each unmap
ttm_bo_vm_close is call.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Questions about TTM buffer object maping

[David Herrmann]

Hi

On Thu, Jul 11, 2013 at 11:43 PM, Jean-Sébastien Pédron
jean-sebastien.ped...@dumbbell.fr wrote:
 Hi,

 Thank you Jérôme and Daniel for your input, that's really helpful!

 I have another question: in ttm_bo_mmap(), a reference to the buffer object
 is acquired at the beginning of the function. Another reference is acquired
 in ttm_bo_vm_open() (released in ttm_bo_vm_close()).

 But where is the first reference released?

-vm_open() isn't called for the first mmap(), afaik (only called
during fork()s or similar). So the reference in ttm_bo_mmap() is a
replacement for the reference you take in the -vm_open() callback.

Cheers
David

 --
 Jean-Sébastien Pédron

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel