[PATCH 0/6] Radeon memory management improvements

[Marek Olšák]

On Tue, Feb 25, 2014 at 11:11 AM, Christian K?nig
 wrote:
> Am 24.02.2014 20:39, schrieb Marek Ol??k:
>
>> On Mon, Feb 24, 2014 at 5:40 PM, Christian K?nig
>>  wrote:
>>>
>>> Am 24.02.2014 16:20, schrieb Marek Ol??k:

 1) Add virtual memory support for VRAM. Our GPUs support virtual memory,
 which not only solves fragmentation issues, but it also allows each
 buffer
 to be partially in VRAM and partially in GTT, which becomes more
 important
 with large buffers like 100 MB. Moving whole buffers back and forth
 between
 VRAM and GTT is inefficient if you can do it at page granularity. Also,
 due
 to fragmentation, we can never really use all of VRAM, but only about
 90-95%.
>>>
>>>
>>> Yeah, I'm also thinking about this for quite some time now. The basic
>>> problem is that while our GPUs support VM they don't support faulting
>>> pages
>>> in and continuing (at least nobody got that working reliable so far).
>>> E.g.
>>> when you hit a page fault you can't relocate the page and then continue.
>>>
>>> Support for partially resident textures on newer hardware currently works
>>> by
>>> splitting the buffer up into smaller buffers in userspace and then
>>> actively
>>> checking in the shader if we hit a buffer that's not currently in memory,
>>> but that's not really applicable in the general use case (to much shader
>>> overhead).
>>
>> I was thinking of splitting buffers into smaller chunks and treating
>> them like independent TTM buffers, i.e. one radeon_bo would contain an
>> array of TTM buffers which would be validated independently of each
>> other. The chunks would only be mapped together to make them look like
>> one buffer. This would be hidden from userspace and there would only
>> be one GEM handle for the whole buffer, so that DRI2 sharing works.
>
>
> My thoughts where more to to this on the userspace side, but doing it in the
> kernel indeed avoids a bunch of problems with sharing the buffer.
>
> Sounds like a plan to me. The only thing I can currently see missing is
> handling of scanout buffers. Do we have a flag for this while creating the
> buffer?

We have a flag in Mesa, but not in the kernel. We can put it in
drm_radeon_gem_create::flags though.

Marek

[Bug 75234] UVD initialization fails while dGPU is powered on by DRI_PRIME

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

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

--- Comment #4 from Hohahiu  ---
(In reply to comment #2)
> Created attachment 94435 [details] [review]
> debugging output
> 
> Can you attach your dmesg output with this patch applied?

Alex, is there anything else I can help in fixing 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/20140226/ef6a9109/attachment.html>

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

[Marek Olšák]

From: Marek Ol??k 

When passing buffers between processes, the receiving process needs to know
the original buffer domain, so that it doesn't accidentally move the buffer.

Signed-off-by: Marek Ol??k 
---
 drivers/gpu/drm/radeon/radeon.h|  3 +++
 drivers/gpu/drm/radeon/radeon_drv.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_gem.c| 36 ++
 drivers/gpu/drm/radeon/radeon_kms.c|  1 +
 drivers/gpu/drm/radeon/radeon_object.c |  3 +++
 include/uapi/drm/radeon_drm.h  | 12 
 6 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a415f8e..3f10782 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -454,6 +454,7 @@ struct radeon_bo {
/* Protected by gem.mutex */
struct list_headlist;
/* Protected by tbo.reserved */
+   u32 initial_domain;
u32 placements[3];
struct ttm_placementplacement;
struct ttm_buffer_objecttbo;
@@ -2114,6 +2115,8 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
void *data,
  struct drm_file *filp);
 int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
+int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
 int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp);
 int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 84a1bbb7..4392b7c 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -79,9 +79,10 @@
  *   2.35.0 - Add CIK macrotile mode array query
  *   2.36.0 - Fix CIK DCE tiling setup
  *   2.37.0 - allow GS ring setup on r6xx/r7xx
+ *   2.38.0 - RADEON_GEM_OP (GET_INITIAL_DOMAIN, SET_INITIAL_DOMAIN)
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   37
+#define KMS_DRIVER_MINOR   38
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index b96c819..9863ca7 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -533,6 +533,42 @@ out:
return r;
 }

+int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp)
+{
+   struct drm_radeon_gem_op *args = data;
+   struct drm_gem_object *gobj;
+   struct radeon_bo *robj;
+   int r;
+
+   gobj = drm_gem_object_lookup(dev, filp, args->handle);
+   if (gobj == NULL) {
+   return -ENOENT;
+   }
+   robj = gem_to_radeon_bo(gobj);
+   r = radeon_bo_reserve(robj, false);
+   if (unlikely(r))
+   goto out;
+
+   switch (args->op) {
+   case RADEON_GEM_OP_GET_INITIAL_DOMAIN:
+   args->value = robj->initial_domain;
+   break;
+   case RADEON_GEM_OP_SET_INITIAL_DOMAIN:
+   robj->initial_domain = args->value & (RADEON_GEM_DOMAIN_VRAM |
+ RADEON_GEM_DOMAIN_GTT |
+ RADEON_GEM_DOMAIN_CPU);
+   break;
+   default:
+   r = -EINVAL;
+   }
+
+   radeon_bo_unreserve(robj);
+out:
+   drm_gem_object_unreference_unlocked(gobj);
+   return r;
+}
+
 int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index baff98b..0b631eb 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -814,5 +814,6 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_OP, radeon_gem_op_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 08595cf..dd12bb4 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ 

[Bug 75432] fedora rawhide, since linux 3.14, dota2 main menu runs at 2 fps

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

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

Sylvain BERTRAND  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Sylvain BERTRAND  ---
It was fixed with the last 3.14 kernel update: 3.14.0-0.rc4.git0.1.fc21.x86_64

-- 
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/20140226/ac4d4157/attachment.html>

[Bug 75357] Barts (HD6850): Failure in evergreen_surface_check_2d

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

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

--- Comment #9 from Michel D?nzer  ---
Does ColorTiling2D work better with a newer version of the mesa-dri-drivers
and/or libdrm(-radeon) packages?

-- 
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/20140226/67833799/attachment.html>

[Bug 73911] Color Banding on R600 (7660G + 7670M)

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

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

--- Comment #16 from scix55 at gmail.com ---
I'm experiencing the same problem with an AMD A10-4600M in an Asus N56DP
laptop. I don't have an external screen to test at the moment, so can't be sure
if it's evident there as well.

I tried the patch with both 3.13 and 3.14-rc4 (with some edits due to it not
applying cleanly for the latter) and the patch actually causes a flickering
black screen on boot, with some faint green line popping up periodically.
Perhaps I applied the patch inproperly, though.

As far as the banding goes, the problem is particularly evident when running
Steam and looking at the grey background, which is filled with multi-coloured
banding.

-- 
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/20140226/a5a4e6cf/attachment-0001.html>

[Bug 75361] freeze in Mass Effect 3 (wine)

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

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

--- Comment #10 from Michel D?nzer  ---
(In reply to comment #9)
> apitrace replay freeze w at the end trace when obscure screen with ships and
> planet. Absolutely also as game.

Hmm. I do see a little freeze at the end of the trace, but only for about three
seconds, then it exits normally.


> After kill game process - Xorg 100% working.

So, does the freezing process hog the CPU?

If you don't kill the freezing process, does it remain frozen forever, or does
it recover or fail somehow after a while?

Can you attach gdb to the freezing process and get a backtrace? Probably best
to attempt this from ssh, but switching to console and doing it from there
might be fine as well.


Does it still happen with current LLVM SVN and Mesa Git? What configure options
do you use for building LLVM and Mesa?

-- 
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/20140226/e948f892/attachment.html>

[Bug 75491] Radeon HD7750 no Monitors connected

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

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

--- Comment #2 from Eric Gr?ttefien  ---
Created attachment 94755
  --> https://bugs.freedesktop.org/attachment.cgi?id=94755=edit
Kernel no force connect

-- 
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/20140226/34f941dc/attachment.html>

[Bug 75491] Radeon HD7750 no Monitors connected

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

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

--- Comment #3 from Eric Gr?ttefien  ---
Created attachment 94756
  --> https://bugs.freedesktop.org/attachment.cgi?id=94756=edit
kernel force connect

-- 
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/20140226/39b7294a/attachment.html>

[Bug 75491] Radeon HD7750 no Monitors connected

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

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

--- Comment #5 from Eric Gr?ttefien  ---
I'm sure they are pasive ones. They cost 1 Eur each ;-)

-- 
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/20140226/5a888772/attachment.html>

[Bug 15701] glMultiDrawElements() yelds strange results in a display list.

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

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

--- Comment #4 from smoki  ---

 This is present even in 7.5 branch and UMS mode, but works and render
correctly today i tried on r200 KMS with mesa 10.2.

-- 
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/20140226/0561fc03/attachment.html>

[Bug 73911] Color Banding on R600 (7660G + 7670M)

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

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

--- Comment #17 from Kertesz Laszlo  ---
I have a A8-6500 (kernel, mesa from git) and i too have banding in Steam and
the xfce desktop if i set gradient background. 
But this doesnt show in gimp for example is i create a gradient.

-- 
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/20140226/d12e7427/attachment.html>

[Bug 27702] [KMS] rv280 segfaults in texdown becnhmark

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

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

--- Comment #6 from smoki  ---
(In reply to comment #0)
> 
> I got segfault if i press b (banchmark) in progs/tests/texdown

 That works today, no segfault when i press b... tried with mesa 10.2 :).

-- 
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/20140226/89bfee0d/attachment-0001.html>

[Bug 27464] Mesa 7.8: screen/keyboard frozen when using menus in GLUT application

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

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

--- Comment #6 from smoki  ---
(In reply to comment #4)
> 
> - still there is heavy CPU load when displaying WireTeapot

 Today it use ZERO CPU :) tested with mesa 10.2... Overall no problem here at
all now wit this example, so this bug can be closed.

-- 
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/20140226/926ab965/attachment.html>

Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
> > Also IVB, model 58?
> >
> Yes.

Right, so it must be chipset-specific.

> > Dunno. What do you mean by "pm callbacks" exactly? I don't know that
> > code so I have to ask.
> >
> power management callbacks.

Ok, just as I thought. But why would they be relevant if this happens
very early during boot?

> > #define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
> Yes. Needs to point to the DRAM controller.

It seems I have it :-)

$ lspci -xxx -s 00.0
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller 
(rev 09)
00: 86 80 54 01 06 00 90 20 09 00 00 06 00 00 00 00
  ^

10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 fa 21
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00
50: 11 02 00 00 11 00 00 00 07 00 90 df 01 00 00 db
60: 05 00 00 f8 00 00 00 00 01 80 d1 fe 00 00 00 00
70: 00 00 00 fe 01 00 00 00 00 0c 00 fe 7f 00 00 00
80: 10 11 11 11 11 11 11 00 1a 00 00 00 00 00 00 00
90: 01 00 00 fe 01 00 00 00 01 00 50 1e 02 00 00 00
a0: 01 00 00 00 02 00 00 00 01 00 60 1e 02 00 00 00
b0: 01 00 a0 db 01 00 80 db 01 00 00 db 01 00 a0 df
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 09 00 0c 01 9b 61 00 e2 d0 00 e8 76 00 00 00 00
f0: 00 00 00 01 00 00 00 00 c8 0f 09 00 00 00 00 00

Anyway, here's some more debugging output and some more staring:

So we're correctly getting 0x154 and then snb_uncore_imc_init_box()
tries to ioremap 0xfed1 but this fails the resource map check with:

[0.485356] resource map sanity check conflict: 0xfed1 0xfed15fff 
0xfed1 0xfed13fff pnp 00:01

and the pnp 00:01 device already partially occupies that range (from
/proc/iomem):

  fed1-fed13fff : pnp 00:01

Oh, and snb_uncore_imc_init_box() gets that address from
SNB_UNCORE_PCI_IMC_BAR_OFFSET and SNB_UNCORE_PCI_IMC_BAR_OFFSET+4 and
they start at offset 0x48 in the PCI config space above, i.e.

40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00
^^^

which is 0x00fed10001 (the 0x1 bit disappears after addr &= ~(PAGE_SIZE - 
1);)

So I'm guessing it is time to talk to platform guys and ask them why
they're putting SNB_UNCORE_PCI_IMC_BAR_OFFSET{,+4} in an overlapping
range with pnp 00:01.

[0.484023] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[0.484108] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at 
[8800cac3-8800cec2]
[0.484971] DBG: will get device: 0x8086:154
[0.485054] DBG: Got device, bus: 0x0
[0.485254] DBG: ioremapping addr: 0xfed1
[0.485356] resource map sanity check conflict: 0xfed1 0xfed15fff 
0xfed1 0xfed13fff pnp 00:01
[0.485460] [ cut here ]
[0.485544] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 
__ioremap_caller+0x372/0x380()
[0.485643] Info: mapping multiple BARs. Your kernel is fine.
[0.485709] Modules linked in:
[0.485935] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #6
[0.486019] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 
11/13/2012
[0.486117]  00ab 880213d01ad8 81611339 
0006
[0.486411]  880213d01b28 880213d01b18 8104e9cc 
880213d01b08
[0.488308]  c9c58000 fed1 fed1 
6000
[0.488595] Call Trace:
[0.488671]  [] dump_stack+0x4f/0x7c
[0.488754]  [] warn_slowpath_common+0x8c/0xc0
[0.488877]  [] warn_slowpath_fmt+0x46/0x50
[0.488966]  [] __ioremap_caller+0x372/0x380
[0.489052]  [] ? snb_uncore_imc_init_box+0x76/0xa0
[0.489137]  [] ioremap_nocache+0x17/0x20
[0.489221]  [] snb_uncore_imc_init_box+0x76/0xa0
[0.489307]  [] uncore_pci_probe+0xe5/0x1e0
[0.489391]  [] local_pci_probe+0x4e/0xa0
[0.489474]  [] ? get_device+0x19/0x20
[0.489558]  [] pci_device_probe+0xe1/0x130
[0.489642]  [] driver_probe_device+0x7b/0x240
[0.489726]  [] __driver_attach+0xab/0xb0
[0.489834]  [] ? driver_probe_device+0x240/0x240
[0.489920]  [] bus_for_each_dev+0x5e/0x90
[0.490003]  [] driver_attach+0x1e/0x20
[0.490086]  [] bus_add_driver+0x117/0x230
[0.490170]  [] driver_register+0x64/0xf0
[0.490251]  [] __pci_register_driver+0x64/0x70
[0.490337]  [] ? uncore_types_init+0x19c/0x19c
[0.490421]  [] intel_uncore_init+0x196/0x462
[0.490504]  [] ? uncore_types_init+0x19c/0x19c
[0.490591]  [] do_one_initcall+0x4e/0x170
[0.490676]  [] ? parse_args+0x50/0x360
[0.490762]  [] kernel_init_freeable+0x106/0x19a
[0.490863]  [] ? do_early_param+0x86/0x86
[0.490948]  [] ? rest_init+0xd0/0xd0
[0.491032]  [] kernel_init+0xe/0xf0
[0.491116]  [] ret_from_fork+0x7c/0xb0
[0.491199]  [] ? rest_init+0xd0/0xd0
[0.491289] ---[ end trace b31a7f760e34b24a 

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

[Christian König]

Am 26.02.2014 01:44, schrieb Marek Ol??k:
> From: Marek Ol??k 
>
> When passing buffers between processes, the receiving process needs to know
> the original buffer domain, so that it doesn't accidentally move the buffer.
>
> Signed-off-by: Marek Ol??k 

This patch is: Reviewed-by: Christian K?nig 

Where is the rest of the series? At least I didn't got it in my mailbox, 
and I would like to apply it to drm-next-3.15.

Cheers,
Christian.

> ---
>   drivers/gpu/drm/radeon/radeon.h|  3 +++
>   drivers/gpu/drm/radeon/radeon_drv.c|  3 ++-
>   drivers/gpu/drm/radeon/radeon_gem.c| 36 
> ++
>   drivers/gpu/drm/radeon/radeon_kms.c|  1 +
>   drivers/gpu/drm/radeon/radeon_object.c |  3 +++
>   include/uapi/drm/radeon_drm.h  | 12 
>   6 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index a415f8e..3f10782 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -454,6 +454,7 @@ struct radeon_bo {
>   /* Protected by gem.mutex */
>   struct list_headlist;
>   /* Protected by tbo.reserved */
> + u32 initial_domain;
>   u32 placements[3];
>   struct ttm_placementplacement;
>   struct ttm_buffer_objecttbo;
> @@ -2114,6 +2115,8 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
> void *data,
> struct drm_file *filp);
>   int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp);
> +int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *filp);
>   int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file 
> *filp);
>   int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *filp);
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 84a1bbb7..4392b7c 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -79,9 +79,10 @@
>*   2.35.0 - Add CIK macrotile mode array query
>*   2.36.0 - Fix CIK DCE tiling setup
>*   2.37.0 - allow GS ring setup on r6xx/r7xx
> + *   2.38.0 - RADEON_GEM_OP (GET_INITIAL_DOMAIN, SET_INITIAL_DOMAIN)
>*/
>   #define KMS_DRIVER_MAJOR2
> -#define KMS_DRIVER_MINOR 37
> +#define KMS_DRIVER_MINOR 38
>   #define KMS_DRIVER_PATCHLEVEL   0
>   int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>   int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index b96c819..9863ca7 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -533,6 +533,42 @@ out:
>   return r;
>   }
>   
> +int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *filp)
> +{
> + struct drm_radeon_gem_op *args = data;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> + int r;
> +
> + gobj = drm_gem_object_lookup(dev, filp, args->handle);
> + if (gobj == NULL) {
> + return -ENOENT;
> + }
> + robj = gem_to_radeon_bo(gobj);
> + r = radeon_bo_reserve(robj, false);
> + if (unlikely(r))
> + goto out;
> +
> + switch (args->op) {
> + case RADEON_GEM_OP_GET_INITIAL_DOMAIN:
> + args->value = robj->initial_domain;
> + break;
> + case RADEON_GEM_OP_SET_INITIAL_DOMAIN:
> + robj->initial_domain = args->value & (RADEON_GEM_DOMAIN_VRAM |
> +   RADEON_GEM_DOMAIN_GTT |
> +   RADEON_GEM_DOMAIN_CPU);
> + break;
> + default:
> + r = -EINVAL;
> + }
> +
> + radeon_bo_unreserve(robj);
> +out:
> + drm_gem_object_unreference_unlocked(gobj);
> + return r;
> +}
> +
>   int radeon_mode_dumb_create(struct drm_file *file_priv,
>   struct drm_device *dev,
>   struct drm_mode_create_dumb *args)
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index baff98b..0b631eb 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -814,5 +814,6 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
>   DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + 

Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

Can you please, pretty please, not top-post...

On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
> Hi,
> 
> Ok, so I am getting the same error message as you.
> I checked my syslog now.
> 
> I have my uncore_imc addr=0xfed1 (after masking)
> 
> And I also have pnp 00:01 overlapping the imc range completely.
> 
> What pnp device does  it really represent? the DRAM controller?
> 
> So I think my laptop behaves like yours.

grep -Er . /sys/devices/pnp0/00\:01/* 2>/dev/null
/sys/devices/pnp0/00:01/firmware_node/hid:PNP0C02
...

so this PNP0C02 is 

[0.363943] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)

@Rafael, can you please make sense of this whole ACPI gunk?

We have a resource conflict with pnp 00:01, analysis here:
http://lkml.kernel.org/r/20140226092903.GA22639 at pd.tnic

This is the rest of the 00:01 info from sysfs:

/sys/devices/pnp0/00:01/firmware_node/uid:0
/sys/devices/pnp0/00:01/firmware_node/path:\_SB_.PCI0.LPC_.SIO_
/sys/devices/pnp0/00:01/firmware_node/power/control:auto
/sys/devices/pnp0/00:01/firmware_node/power/runtime_active_time:0
/sys/devices/pnp0/00:01/firmware_node/power/runtime_status:unsupported
/sys/devices/pnp0/00:01/firmware_node/power/runtime_suspended_time:0
/sys/devices/pnp0/00:01/firmware_node/modalias:acpi:PNP0C02:
/sys/devices/pnp0/00:01/firmware_node/uevent:MODALIAS=acpi:PNP0C02:
/sys/devices/pnp0/00:01/id:PNP0c02
/sys/devices/pnp0/00:01/power/control:auto
/sys/devices/pnp0/00:01/power/runtime_active_time:0
/sys/devices/pnp0/00:01/power/runtime_status:unsupported
/sys/devices/pnp0/00:01/power/runtime_suspended_time:0
/sys/devices/pnp0/00:01/resources:state = active
/sys/devices/pnp0/00:01/resources:io 0x10-0x1f
/sys/devices/pnp0/00:01/resources:io 0x90-0x9f
/sys/devices/pnp0/00:01/resources:io 0x24-0x25
/sys/devices/pnp0/00:01/resources:io 0x28-0x29
/sys/devices/pnp0/00:01/resources:io 0x2c-0x2d
/sys/devices/pnp0/00:01/resources:io 0x30-0x31
/sys/devices/pnp0/00:01/resources:io 0x34-0x35
/sys/devices/pnp0/00:01/resources:io 0x38-0x39
/sys/devices/pnp0/00:01/resources:io 0x3c-0x3d
/sys/devices/pnp0/00:01/resources:io 0xa4-0xa5
/sys/devices/pnp0/00:01/resources:io 0xa8-0xa9
/sys/devices/pnp0/00:01/resources:io 0xac-0xad
/sys/devices/pnp0/00:01/resources:io 0xb0-0xb5
/sys/devices/pnp0/00:01/resources:io 0xb8-0xb9
/sys/devices/pnp0/00:01/resources:io 0xbc-0xbd
/sys/devices/pnp0/00:01/resources:io 0x50-0x53
/sys/devices/pnp0/00:01/resources:io 0x72-0x77
/sys/devices/pnp0/00:01/resources:io 0x400-0x47f
/sys/devices/pnp0/00:01/resources:io 0x500-0x57f
/sys/devices/pnp0/00:01/resources:io 0x800-0x80f
/sys/devices/pnp0/00:01/resources:io 0x15e0-0x15ef
/sys/devices/pnp0/00:01/resources:io 0x1600-0x167f
/sys/devices/pnp0/00:01/resources:mem 0xf800-0xfbff
/sys/devices/pnp0/00:01/resources:mem 0xf000-0x
/sys/devices/pnp0/00:01/resources:mem 0xfed1c000-0xfed1
/sys/devices/pnp0/00:01/resources:mem 0xfed1-0xfed13fff
/sys/devices/pnp0/00:01/resources:mem 0xfed18000-0xfed18fff
/sys/devices/pnp0/00:01/resources:mem 0xfed19000-0xfed19fff
/sys/devices/pnp0/00:01/resources:mem 0xfed45000-0xfed4bfff
/sys/devices/pnp0/00:01/resources:mem 0xfed4-0xfed44fff
/sys/devices/pnp0/00:01/subsystem/drivers_autoprobe:1
/sys/devices/pnp0/00:01/uevent:DRIVER=system

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

[Marek Olšák]

I'll send the other patches today.

Marek

On Wed, Feb 26, 2014 at 10:39 AM, Christian K?nig
 wrote:
> Am 26.02.2014 01:44, schrieb Marek Ol??k:
>
>> From: Marek Ol??k 
>>
>> When passing buffers between processes, the receiving process needs to
>> know
>> the original buffer domain, so that it doesn't accidentally move the
>> buffer.
>>
>> Signed-off-by: Marek Ol??k 
>
>
> This patch is: Reviewed-by: Christian K?nig 
>
> Where is the rest of the series? At least I didn't got it in my mailbox, and
> I would like to apply it to drm-next-3.15.
>
> Cheers,
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/radeon/radeon.h|  3 +++
>>   drivers/gpu/drm/radeon/radeon_drv.c|  3 ++-
>>   drivers/gpu/drm/radeon/radeon_gem.c| 36
>> ++
>>   drivers/gpu/drm/radeon/radeon_kms.c|  1 +
>>   drivers/gpu/drm/radeon/radeon_object.c |  3 +++
>>   include/uapi/drm/radeon_drm.h  | 12 
>>   6 files changed, 57 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index a415f8e..3f10782 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -454,6 +454,7 @@ struct radeon_bo {
>> /* Protected by gem.mutex */
>> struct list_headlist;
>> /* Protected by tbo.reserved */
>> +   u32 initial_domain;
>> u32 placements[3];
>> struct ttm_placementplacement;
>> struct ttm_buffer_objecttbo;
>> @@ -2114,6 +2115,8 @@ int radeon_gem_wait_idle_ioctl(struct drm_device
>> *dev, void *data,
>>   struct drm_file *filp);
>>   int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
>>   struct drm_file *filp);
>> +int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
>> +   struct drm_file *filp);
>>   int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file
>> *filp);
>>   int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
>> struct drm_file *filp);
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 84a1bbb7..4392b7c 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -79,9 +79,10 @@
>>*   2.35.0 - Add CIK macrotile mode array query
>>*   2.36.0 - Fix CIK DCE tiling setup
>>*   2.37.0 - allow GS ring setup on r6xx/r7xx
>> + *   2.38.0 - RADEON_GEM_OP (GET_INITIAL_DOMAIN, SET_INITIAL_DOMAIN)
>>*/
>>   #define KMS_DRIVER_MAJOR  2
>> -#define KMS_DRIVER_MINOR   37
>> +#define KMS_DRIVER_MINOR   38
>>   #define KMS_DRIVER_PATCHLEVEL 0
>>   int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>>   int radeon_driver_unload_kms(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
>> b/drivers/gpu/drm/radeon/radeon_gem.c
>> index b96c819..9863ca7 100644
>> --- a/drivers/gpu/drm/radeon/radeon_gem.c
>> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
>> @@ -533,6 +533,42 @@ out:
>> return r;
>>   }
>>   +int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
>> +   struct drm_file *filp)
>> +{
>> +   struct drm_radeon_gem_op *args = data;
>> +   struct drm_gem_object *gobj;
>> +   struct radeon_bo *robj;
>> +   int r;
>> +
>> +   gobj = drm_gem_object_lookup(dev, filp, args->handle);
>> +   if (gobj == NULL) {
>> +   return -ENOENT;
>> +   }
>> +   robj = gem_to_radeon_bo(gobj);
>> +   r = radeon_bo_reserve(robj, false);
>> +   if (unlikely(r))
>> +   goto out;
>> +
>> +   switch (args->op) {
>> +   case RADEON_GEM_OP_GET_INITIAL_DOMAIN:
>> +   args->value = robj->initial_domain;
>> +   break;
>> +   case RADEON_GEM_OP_SET_INITIAL_DOMAIN:
>> +   robj->initial_domain = args->value &
>> (RADEON_GEM_DOMAIN_VRAM |
>> +
>> RADEON_GEM_DOMAIN_GTT |
>> +
>> RADEON_GEM_DOMAIN_CPU);
>> +   break;
>> +   default:
>> +   r = -EINVAL;
>> +   }
>> +
>> +   radeon_bo_unreserve(robj);
>> +out:
>> +   drm_gem_object_unreference_unlocked(gobj);
>> +   return r;
>> +}
>> +
>>   int radeon_mode_dumb_create(struct drm_file *file_priv,
>> struct drm_device *dev,
>> struct drm_mode_create_dumb *args)
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index baff98b..0b631eb 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -814,5 +814,6 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
>> DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING,
>> radeon_gem_get_tiling_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> 

[Bug 25676] Radeon hangs in RADEONWaitForIdleCP in bubble3d screensaver

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

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

--- Comment #2 from smoki  ---

 Don't know for OP (seems like it was use here obsolete XAA) but for me not
anymore, hava the same 5960 chip here and it works OK tested with current stack
kernel 3.14-rc4, xorg 1.15 and git mesa 10.2.

-- 
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/20140226/6686684a/attachment.html>

[Bug 27221] Big 3D performance regression and broken textures on R200

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

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

--- Comment #11 from smoki  ---
 Render correctly here and i tested two year ago performance with different
drivers and was OKish for KMS:

http://www.phoronix.com/forums/showthread.php?68319-Radeon-Gallium3D-A-Half-Decade-Behind-Catalyst=248042#post248042

 And it is practicaly the same with current git mesa 10.2 :).

-- 
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/20140226/cb6b5d2c/attachment.html>

Info: mapping multiple BARs. Your kernel is fine.

[Peter Zijlstra]

On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
> 
> What about -rc4 without tip?

The driver causing this is new and lives in -tip.

Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
> 
> What about -rc4 without tip?

I don't think so because

commit b9e1ab6d4c0582cad97699285a6b3cf992251b00
Author: Stephane Eranian 
Date:   Tue Feb 11 16:20:12 2014 +0100

perf/x86/uncore: add SNB/IVB/HSW client uncore memory controller support

in -tip introduces that snb_uncore_imc_init_box() thing which causes the
ioremap conflict.

Btw, see my last email on this thread for more details about what I'm
seeing here.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[Intel-gfx] Request for feedback : New Panel-fitter property for connectors

[Ville Syrjälä]

On Wed, Feb 26, 2014 at 01:32:44PM +, Goel, Akash wrote:
> To expose the panel fitter for arbitrary use by User-space, we will expose 
> the manual scaling ratio & Input/Src size info to User, apart from the 
> available scaling modes like Full screen, Centered, Aspect. 
> Please suggest that how shall we extend the current interface to incorporate 
> these extra info, considering the options we have .
> DRM_MODE_PROP_ENUM
> DRM_MODE_PROP_RANGE
> DRM_MODE_PROP_BITMASK
> DRM_MODE_PROP_BLOB

Either we should have two range properties (eg. crtc_width and crtc_height),
or we could define a new property type that has both in the same value.
Not sure if it's worth adding another type for this. Although we might
be able to use such a type to reduce the number of properties a bit for
planes and such (src and dst coordinages). The issue is that it
limits the range a bit. Not a real issue for this case, but for plane
src coordiantes we'd end up limit ourselves to 16.16 again, which may be
a bit short sighted.

And please, no scaling ratio property. Just explicit input and output
sizes are better IMO. The output size should really be part of the mode
as borders, but I'm not sure we want to be redefining the mode
structure. I have no problem with the idea, but maybe other people are
more reluctant. The alternative is to define the border through
properties as well.

We'd also need to figure out how to make this stuff cooperate decently
with the way we deal with panel fixed modes currently. IMO ideally if
the user specified the pfit stuff explicitly, we should really treat
the display mode the user passed in as the adjusted_mode, and not just
blindly overwrite it. This would also make it much easier to use
cloning when one of the cloned displays has a fixed mode. Currently
the user has no idea that the mode he passes in isn't what gets
programmed into the timing generator, so other displays may not be able
handle the mode even though it seemed perfectly valid from the user's
perspective. I guess we could just add a new mode type flag to indicate
the native mode of the display, but only in case where the display has
a fixed mode (ie. it won't accept any input timings). Then userspace
would know that if it wants to do cloning, it should check if any of
the displays has a fixed mode, and use that for the timings.

> 
> Best Regards
> Akash
> 
> -Original Message-
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk] 
> Sent: Thursday, February 20, 2014 1:41 PM
> To: Ville Syrj?l?
> Cc: Goel, Akash; intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter property for 
> connectors
> 
> On Wed, Feb 19, 2014 at 01:02:57PM +0200, Ville Syrj?l? wrote:
> > On Wed, Feb 19, 2014 at 09:33:11AM +, Goel, Akash wrote:
> > > Thanks for your inputs.
> > > 
> > > Actually for our use cases, the 'scaling_mode' property currently being 
> > > used for 'lvds' & 'dp', cannot be used as it is.
> > > 
> > > For our use cases, we need to provide a fine level control to User, so as 
> > > to be able to choose the LetterBox/Pillar-box modes & also the Manual 
> > > mode with horizontal & vertical scaling ratios.
> 
> You can extend the current interface to add the extra modes (letter, 
> pillarbox, and later the manual toggle).
> 
> > > Please provide suggestions, that how we can extend/reuse the 
> > > 'scaling_mode' property here. 
> > 
> > My plan is to somehow expose the panel fitter input and output sizes 
> > explicitly at some point. The output size could be expose by adding 
> > borders to the display mode structure (or some border properties if we 
> > don't want to change the user visible mode struct). And the input size 
> > could also be done via properties.
> 
> Agreed, this is how we have talked about exposing the panel fitter for 
> arbitrary use by userspace (such as overscan compensation).
> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre

-- 
Ville Syrj?l?
Intel OTC

[GIT PULL]: drm: DisplayPort AUX framework for v3.15-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:

  Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/dp-aux-for-3.15-rc1

for you to fetch changes up to 88759686c702f1fbbb8e737e6231b64a9880db73:

  drm/dp: Allow registering AUX channels as I2C busses (2014-02-26 17:21:34 
+0100)

Thanks,
Thierry


drm: DisplayPort AUX framework for v3.15-rc1

This series of patches implements a small framework that abstracts away
some of the functionality that the DisplayPort AUX channel provides. It
comes with a set of generic helpers that use the driver implementations
to reduce code duplication.


Thierry Reding (4):
  drm/dp: Add AUX channel infrastructure
  drm/dp: Add drm_dp_dpcd_read_link_status()
  drm/dp: Add DisplayPort link helpers
  drm/dp: Allow registering AUX channels as I2C busses

 drivers/gpu/drm/drm_dp_helper.c | 395 
 include/drm/drm_dp_helper.h | 111 +++
 2 files changed, 506 insertions(+)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140226/97ede420/attachment.pgp>

[Bug 75361] freeze in Mass Effect 3 (wine)

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

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

--- Comment #11 from wdr  ---
I'm use gentoo x11 overlay for git mesa:
[ebuild   R   #] media-libs/mesa-::x11  USE="debug egl gallium gbm gles2
llvm llvm-shared-libs nptl -bindist -classic -gles1 -opencl -openmax -openvg
-osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -vdpau -wayland -xa
-xvmc" VIDEO_CARDS="radeon radeonsi (-freedreno) -i915 -i965 -ilo -intel
-nouveau -r100 -r200 -r300 -r600 -vmware" 0 kB

./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib
--disable-silent-rules --disable-dependency-tracking --enable-dri --enable-glx
--enable-shared-glapi --enable-texture-float --enable-debug --enable-egl
--enable-gbm --disable-gles1 --enable-gles2 --enable-glx-tls --disable-osmesa
--enable-asm --enable-llvm-shared-libs --with-dri-drivers=
--with-gallium-drivers=,swrast,radeonsi,r300,r600 PYTHON2=/usr/bin/python2.7
--with-egl-platforms=x11,drm --enable-gallium-llvm --disable-openvg
--disable-gallium-egl --disable-omx --disable-r600-llvm-compiler
--disable-vdpau --disable-xa --disable-xvmc

[ebuild   R   *] sys-devel/llvm-:0/  USE="debug libffi static-analyzer
xml -clang -doc -gold -multitarget -ncurses -ocaml -python {-test} -udis86"
PYTHON_TARGETS="python2_7 -pypy2_0 -python2_6" VIDEO_CARDS="radeon" 0 kB

/var/tmp/portage/sys-devel/llvm-/work/llvm-/configure --prefix=/usr
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib --disable-timestamps
--enable-keep-symbols --enable-shared --with-optimize-option=
--disable-optimized --enable-assertions --enable-expensive-checks
--disable-terminfo --enable-libffi ac_cv_prog_XML2CONFIG=
--enable-targets=host,cpp,r600 --enable-bindings=none


If i do not kill the freezing process, it freeze forever. Cpu usage ~10%.
i am use latest mesa git and latest llvm from svn (26 february)

-- 
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/20140226/1b21cd1a/attachment.html>

[Bug 75361] freeze in Mass Effect 3 (wine)

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

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

--- Comment #12 from wdr  ---
Created attachment 94775
  --> https://bugs.freedesktop.org/attachment.cgi?id=94775=edit
gdb backtrace

-- 
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/20140226/c7aeae65/attachment.html>

[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi

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

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

Jarno Lepp?nen  changed:

   What|Removed |Added

   Assignee|zhigang.gong at gmail.com  |dri-devel at 
lists.freedesktop
   ||.org
 CC||jarno.leppanen at iki.fi
Product|xorg|Mesa
Version|unspecified |10.0
  Component|Driver/glamor   |Drivers/Gallium/radeonsi

-- 
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/20140226/cdb5c53f/attachment.html>

[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves

[Marek Olšák]

On Mon, Feb 24, 2014 at 5:20 PM, Christian K?nig
 wrote:
> Am 24.02.2014 16:20, schrieb Marek Ol??k:
>
>> From: Marek Ol??k 
>>
>> The statistics are:
>> - VRAM usage in bytes
>> - GTT usage in bytes
>> - number of bytes moved by TTM
>>
>> The last one is actually a counter, so you need to sample it before and
>> after
>> command submission and take the difference.
>>
>> This is useful for finding performance bottlenecks. Userspace queries are
>> also added.
>>
>> Signed-off-by: Marek Ol??k 
>> ---
>>   drivers/gpu/drm/radeon/radeon.h|  5 +
>>   drivers/gpu/drm/radeon/radeon_device.c |  1 +
>>   drivers/gpu/drm/radeon/radeon_kms.c| 15 ++
>>   drivers/gpu/drm/radeon/radeon_object.c | 38
>> +-
>>   drivers/gpu/drm/radeon/radeon_object.h |  2 +-
>>   drivers/gpu/drm/radeon/radeon_ttm.c| 10 -
>>   include/uapi/drm/radeon_drm.h  |  3 +++
>>   7 files changed, 71 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 3f10782..d37a57a 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -2307,6 +2307,11 @@ struct radeon_device {
>> /* virtual memory */
>> struct radeon_vm_managervm_manager;
>> struct mutexgpu_clock_mutex;
>> +   /* memory stats */
>> +   struct mutexmemory_stats_mutex;
>> +   uint64_tvram_usage;
>> +   uint64_tgtt_usage;
>> +   uint64_tnum_bytes_moved;
>
>
> As far as I can see you could make those tree values atomic64_t instead and
> avoid the mutex.

I'm afraid I cannot use atomic64_t. It doesn't work on x86 32-bit.
This seems to be a no-op:

u64 size = (u64)bo->num_pages << PAGE_SHIFT;
atomic64_add(size, >num_bytes_moved);

Marek

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

[Marek Olšák]

From: Marek Ol??k 

When passing buffers between processes, the receiving process needs to know
the original buffer domain, so that it doesn't accidentally move the buffer.

Signed-off-by: Marek Ol??k 
---
 drivers/gpu/drm/radeon/radeon.h|  3 +++
 drivers/gpu/drm/radeon/radeon_drv.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_gem.c| 36 ++
 drivers/gpu/drm/radeon/radeon_kms.c|  1 +
 drivers/gpu/drm/radeon/radeon_object.c |  3 +++
 include/uapi/drm/radeon_drm.h  | 12 
 6 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a415f8e..3f10782 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -454,6 +454,7 @@ struct radeon_bo {
/* Protected by gem.mutex */
struct list_headlist;
/* Protected by tbo.reserved */
+   u32 initial_domain;
u32 placements[3];
struct ttm_placementplacement;
struct ttm_buffer_objecttbo;
@@ -2114,6 +2115,8 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
void *data,
  struct drm_file *filp);
 int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
+int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
 int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp);
 int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 84a1bbb7..4392b7c 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -79,9 +79,10 @@
  *   2.35.0 - Add CIK macrotile mode array query
  *   2.36.0 - Fix CIK DCE tiling setup
  *   2.37.0 - allow GS ring setup on r6xx/r7xx
+ *   2.38.0 - RADEON_GEM_OP (GET_INITIAL_DOMAIN, SET_INITIAL_DOMAIN)
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   37
+#define KMS_DRIVER_MINOR   38
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index b96c819..9863ca7 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -533,6 +533,42 @@ out:
return r;
 }

+int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp)
+{
+   struct drm_radeon_gem_op *args = data;
+   struct drm_gem_object *gobj;
+   struct radeon_bo *robj;
+   int r;
+
+   gobj = drm_gem_object_lookup(dev, filp, args->handle);
+   if (gobj == NULL) {
+   return -ENOENT;
+   }
+   robj = gem_to_radeon_bo(gobj);
+   r = radeon_bo_reserve(robj, false);
+   if (unlikely(r))
+   goto out;
+
+   switch (args->op) {
+   case RADEON_GEM_OP_GET_INITIAL_DOMAIN:
+   args->value = robj->initial_domain;
+   break;
+   case RADEON_GEM_OP_SET_INITIAL_DOMAIN:
+   robj->initial_domain = args->value & (RADEON_GEM_DOMAIN_VRAM |
+ RADEON_GEM_DOMAIN_GTT |
+ RADEON_GEM_DOMAIN_CPU);
+   break;
+   default:
+   r = -EINVAL;
+   }
+
+   radeon_bo_unreserve(robj);
+out:
+   drm_gem_object_unreference_unlocked(gobj);
+   return r;
+}
+
 int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index baff98b..0b631eb 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -814,5 +814,6 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_OP, radeon_gem_op_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 08595cf..dd12bb4 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ 

[PATCH 6/6] drm/radeon: limit how much memory TTM can move per IB according to VRAM usage

[Marek Olšák]

From: Marek Ol??k 

Signed-off-by: Marek Ol??k 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_cs.c |  2 +-
 drivers/gpu/drm/radeon/radeon_object.c | 87 +++---
 drivers/gpu/drm/radeon/radeon_object.h |  3 +-
 3 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 779fa02..9aface7 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -172,7 +172,7 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)

radeon_cs_buckets_get_list(, >validated);

-   return radeon_bo_list_validate(>ticket, >validated, p->ring);
+   return radeon_bo_list_validate(p->rdev, >ticket, >validated, 
p->ring);
 }

 static int radeon_cs_get_ring(struct radeon_cs_parser *p, u32 ring, s32 
priority)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 19042ae..1ab6d5c 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -368,29 +368,104 @@ void radeon_bo_fini(struct radeon_device *rdev)
arch_phys_wc_del(rdev->mc.vram_mtrr);
 }

-int radeon_bo_list_validate(struct ww_acquire_ctx *ticket,
+/* Returns how many bytes TTM can move per IB.
+ */
+static u64 radeon_bo_get_threshold_for_moves(struct radeon_device *rdev)
+{
+   u64 real_vram_size = rdev->mc.real_vram_size;
+   u64 vram_usage = >vram_usage;
+
+   /* This function is based on the current VRAM usage.
+*
+* - If all of VRAM is free, allow relocating the number of bytes that
+*   is equal to 1/4 of the size of VRAM for this IB.
+
+* - If more than one half of VRAM is occupied, only allow relocating
+*   1 MB of data for this IB.
+*
+* - From 0 to one half of used VRAM, the threshold decreases
+*   linearly.
+* __
+* 1/4 of -|\   |
+* VRAM| \  |
+* |  \ |
+* |   \|
+* |\   |
+* | \  |
+* |  \ |
+* |   \|1 MB
+* ||
+*VRAM 0 % 100 %
+* usedused
+*
+* Note: It's a threshold, not a limit. The threshold must be crossed
+* for buffer relocations to stop, so any buffer of an arbitrary size
+* can be moved as long as the threshold isn't crossed before
+* the relocation takes place. We don't want to disable buffer
+* relocations completely.
+*
+* The idea is that buffers should be placed in VRAM at creation time
+* and TTM should only do a minimum number of relocations during
+* command submission. In practice, you need to submit at least
+* a dozen IBs to move all buffers to VRAM if they are in GTT.
+*
+* Also, things can get pretty crazy under memory pressure and actual
+* VRAM usage can change a lot, so playing safe even at 50% does
+* consistently increase performance.
+*/
+
+   u64 half_vram = real_vram_size >> 1;
+   u64 half_free_vram = vram_usage >= half_vram ? 0 : half_vram - 
vram_usage;
+   u64 bytes_moved_threshold = half_free_vram >> 1;
+   return max(bytes_moved_threshold, 1024*1024ull);
+}
+
+int radeon_bo_list_validate(struct radeon_device *rdev,
+   struct ww_acquire_ctx *ticket,
struct list_head *head, int ring)
 {
struct radeon_bo_list *lobj;
struct radeon_bo *bo;
-   u32 domain;
int r;
+   u64 bytes_moved = 0, initial_bytes_moved;
+   u64 bytes_moved_threshold = radeon_bo_get_threshold_for_moves(rdev);

r = ttm_eu_reserve_buffers(ticket, head);
if (unlikely(r != 0)) {
return r;
}
+
list_for_each_entry(lobj, head, tv.head) {
bo = lobj->bo;
if (!bo->pin_count) {
-   domain = lobj->domain;
-   
+   u32 domain = lobj->domain;
+   u32 current_domain =
+   radeon_mem_type_to_domain(bo->tbo.mem.mem_type);
+
+   /* Check if this buffer will be moved and don't move it
+* if we have moved too many buffers for this IB 
already.
+*
+* Note that this allows moving at least one buffer of
+* any size, because it doesn't take the current "bo"
+* into account. We don't want to disallow buffer moves
+* completely.
+*/
+   if (current_domain != 

[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves

[Marek Olšák]

From: Marek Ol??k 

The statistics are:
- VRAM usage in bytes
- GTT usage in bytes
- number of bytes moved by TTM

The last one is actually a counter, so you need to sample it before and after
command submission and take the difference.

This is useful for finding performance bottlenecks. Userspace queries are
also added.

Signed-off-by: Marek Ol??k 
---
 drivers/gpu/drm/radeon/radeon.h|  5 +
 drivers/gpu/drm/radeon/radeon_device.c |  1 +
 drivers/gpu/drm/radeon/radeon_kms.c| 15 ++
 drivers/gpu/drm/radeon/radeon_object.c | 38 +-
 drivers/gpu/drm/radeon/radeon_object.h |  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c| 10 -
 include/uapi/drm/radeon_drm.h  |  3 +++
 7 files changed, 71 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3f10782..d37a57a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2307,6 +2307,11 @@ struct radeon_device {
/* virtual memory */
struct radeon_vm_managervm_manager;
struct mutexgpu_clock_mutex;
+   /* memory stats */
+   struct mutexmemory_stats_mutex;
+   uint64_tvram_usage;
+   uint64_tgtt_usage;
+   uint64_tnum_bytes_moved;
/* ACPI interface */
struct radeon_atif  atif;
struct radeon_atcs  atcs;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index b012cbb..6564af7 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1184,6 +1184,7 @@ int radeon_device_init(struct radeon_device *rdev,
mutex_init(>gem.mutex);
mutex_init(>pm.mutex);
mutex_init(>gpu_clock_mutex);
+   mutex_init(>memory_stats_mutex);
mutex_init(>srbm_mutex);
init_rwsem(>pm.mclk_lock);
init_rwsem(>exclusive_lock);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 0b631eb..ddc8c74 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -486,6 +486,21 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
case RADEON_INFO_VCE_FB_VERSION:
*value = rdev->vce.fb_version;
break;
+   case RADEON_INFO_NUM_BYTES_MOVED:
+   value = (uint32_t*)
+   value_size = sizeof(uint64_t);
+   value64 = rdev->num_bytes_moved;
+   break;
+   case RADEON_INFO_VRAM_USAGE:
+   value = (uint32_t*)
+   value_size = sizeof(uint64_t);
+   value64 = rdev->vram_usage;
+   break;
+   case RADEON_INFO_GTT_USAGE:
+   value = (uint32_t*)
+   value_size = sizeof(uint64_t);
+   value64 = rdev->gtt_usage;
+   break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index dd12bb4..d676ee2 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -56,11 +56,38 @@ static void radeon_bo_clear_va(struct radeon_bo *bo)
}
 }

+static void radeon_update_memory_usage(struct radeon_bo *bo,
+  unsigned mem_type, int sign)
+{
+   struct radeon_device *rdev = bo->rdev;
+   u64 size = (u64)bo->tbo.num_pages << PAGE_SHIFT;
+
+   mutex_lock(>memory_stats_mutex);
+   switch (mem_type) {
+   case TTM_PL_TT:
+   if (sign > 0)
+   rdev->gtt_usage += size;
+   else
+   rdev->gtt_usage -= size;
+   break;
+   case TTM_PL_VRAM:
+   if (sign > 0)
+   rdev->vram_usage += size;
+   else
+   rdev->vram_usage -= size;
+   break;
+   }
+   mutex_unlock(>memory_stats_mutex);
+}
+
 static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
 {
struct radeon_bo *bo;

bo = container_of(tbo, struct radeon_bo, tbo);
+
+   radeon_update_memory_usage(bo, bo->tbo.mem.mem_type, -1);
+
mutex_lock(>rdev->gem.mutex);
list_del_init(>list);
mutex_unlock(>rdev->gem.mutex);
@@ -567,14 +594,23 @@ int radeon_bo_check_tiling(struct radeon_bo *bo, bool 
has_moved,
 }

 void radeon_bo_move_notify(struct ttm_buffer_object *bo,
-  struct ttm_mem_reg *mem)
+  struct ttm_mem_reg *new_mem)
 {
struct radeon_bo *rbo;
+
if (!radeon_ttm_bo_is_radeon_bo(bo))
return;
+
rbo = container_of(bo, struct 

[PATCH 3/6] drm/radeon: deduplicate code in radeon_gem_busy_ioctl

[Marek Olšák]

From: Marek Ol??k 

Signed-off-by: Marek Ol??k 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 9863ca7..d09650c 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -344,18 +344,7 @@ int radeon_gem_busy_ioctl(struct drm_device *dev, void 
*data,
}
robj = gem_to_radeon_bo(gobj);
r = radeon_bo_wait(robj, _placement, true);
-   switch (cur_placement) {
-   case TTM_PL_VRAM:
-   args->domain = RADEON_GEM_DOMAIN_VRAM;
-   break;
-   case TTM_PL_TT:
-   args->domain = RADEON_GEM_DOMAIN_GTT;
-   break;
-   case TTM_PL_SYSTEM:
-   args->domain = RADEON_GEM_DOMAIN_CPU;
-   default:
-   break;
-   }
+   args->domain = radeon_mem_type_to_domain(cur_placement);
drm_gem_object_unreference_unlocked(gobj);
r = radeon_gem_handle_lockup(rdev, r);
return r;
-- 
1.8.3.2

[PATCH 5/6] drm/radeon: validate relocations in the order determined by userspace

[Marek Olšák]

From: Marek Ol??k 

Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to
a number from 0 to 15. The higher the number, the higher the priority,
which means a buffer with a higher number will be validated sooner.

The old behavior is preserved: Buffers used for write are prioritized over
read-only buffers if the userspace doesn't set the number.

v2: add buffers to buckets directly, then concatenate them

Signed-off-by: Marek Ol??k 
---
 drivers/gpu/drm/radeon/radeon.h|  2 +-
 drivers/gpu/drm/radeon/radeon_cs.c | 68 --
 drivers/gpu/drm/radeon/radeon_object.c | 10 -
 drivers/gpu/drm/radeon/radeon_object.h |  2 -
 4 files changed, 66 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d37a57a..f7a3174 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -481,7 +481,7 @@ struct radeon_bo_list {
struct ttm_validate_buffer tv;
struct radeon_bo*bo;
uint64_tgpu_offset;
-   boolwritten;
+   unsignedpriority;
unsigneddomain;
unsignedalt_domain;
u32 tiling_flags;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index d49a3f7..779fa02 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -31,10 +31,57 @@
 #include "radeon.h"
 #include "radeon_trace.h"

+#define RADEON_CS_MAX_PRIORITY 33u
+#define RADEON_CS_MAX_BUCKET   (RADEON_CS_MAX_PRIORITY / 2u)
+#define RADEON_CS_NUM_BUCKETS  (RADEON_CS_MAX_BUCKET + 1u)
+
+/* This is based on the bucket sort with O(n) time complexity.
+ * Relocations are sorted from the highest to the lowest priority as
+ * they are added.
+ *
+ * Odd numbers are added at the head of a bucket and even numbers are
+ * added at the tail, therefore all buckets are always sorted. */
+struct radeon_cs_buckets {
+   struct list_head bucket[RADEON_CS_NUM_BUCKETS];
+};
+
+static void radeon_cs_buckets_init(struct radeon_cs_buckets *b)
+{
+   unsigned i;
+
+   for (i = 0; i < RADEON_CS_NUM_BUCKETS; i++)
+   INIT_LIST_HEAD(>bucket[i]);
+}
+
+static void radeon_cs_buckets_add(struct radeon_cs_buckets *b,
+ struct radeon_bo_list *reloc)
+{
+   unsigned priority = reloc->priority;
+   unsigned i = min(priority / 2u, RADEON_CS_MAX_BUCKET);
+
+   if (priority % 2 == 1) {
+   list_add(>tv.head, >bucket[i]);
+   } else {
+   list_add_tail(>tv.head, >bucket[i]);
+   }
+}
+
+static void radeon_cs_buckets_get_list(struct radeon_cs_buckets *b,
+  struct list_head *out_list)
+{
+   unsigned i;
+
+   /* Connect the sorted buckets in the output list. */
+   for (i = 0; i < RADEON_CS_NUM_BUCKETS; i++) {
+   list_splice(>bucket[i], out_list);
+   }
+}
+
 static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
 {
struct drm_device *ddev = p->rdev->ddev;
struct radeon_cs_chunk *chunk;
+   struct radeon_cs_buckets buckets;
unsigned i, j;
bool duplicate;

@@ -53,6 +100,9 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)
if (p->relocs == NULL) {
return -ENOMEM;
}
+
+   radeon_cs_buckets_init();
+
for (i = 0; i < p->nrelocs; i++) {
struct drm_radeon_cs_reloc *r;

@@ -80,7 +130,15 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)
p->relocs_ptr[i] = >relocs[i];
p->relocs[i].robj = gem_to_radeon_bo(p->relocs[i].gobj);
p->relocs[i].lobj.bo = p->relocs[i].robj;
-   p->relocs[i].lobj.written = !!r->write_domain;
+
+   /* The userspace buffer priorities are from 0 to 15. A higher
+* number means the buffer is more important.
+* Also, the buffers used for write have a higher priority than
+* the buffers used for read only, which doubles the range
+* to 0 to 31. Numbers 32 and 33 are reserved for the kernel
+* driver.
+*/
+   p->relocs[i].lobj.priority = (r->flags & 0xf) * 2 + 
!!r->write_domain;

/* the first reloc of an UVD job is the msg and that must be in
   VRAM, also but everything into VRAM on AGP cards to avoid
@@ -94,6 +152,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)
p->relocs[i].lobj.alt_domain =
RADEON_GEM_DOMAIN_VRAM;

+   /* prioritize this over any other relocation */
+   p->relocs[i].lobj.priority = 32;
} else {

[PATCH 4/6] drm/radeon: add buffers to the LRU list from smallest to largest

[Marek Olšák]

From: Marek Ol??k 

Signed-off-by: Marek Ol??k 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index f28a8d8..d49a3f7 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -24,6 +24,7 @@
  * Authors:
  *Jerome Glisse 
  */
+#include 
 #include 
 #include 
 #include "radeon_reg.h"
@@ -290,6 +291,16 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
return 0;
 }

+static int cmp_size_smaller_first(void *priv, struct list_head *a,
+ struct list_head *b)
+{
+   struct radeon_bo_list *la = list_entry(a, struct radeon_bo_list, 
tv.head);
+   struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list, 
tv.head);
+
+   /* Sort A before B if A is smaller. */
+   return (int)la->bo->tbo.num_pages - (int)lb->bo->tbo.num_pages;
+}
+
 /**
  * cs_parser_fini() - clean parser states
  * @parser:parser structure holding parsing context.
@@ -303,6 +314,18 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error, bo
unsigned i;

if (!error) {
+   /* Sort the buffer list from the smallest to largest buffer,
+* which affects the order of buffers in the LRU list.
+* This assures that the smallest buffers are added first
+* to the LRU list, so they are likely to be later evicted
+* first, instead of large buffers whose eviction is more
+* expensive.
+*
+* This slightly lowers the number of bytes moved by TTM
+* per frame under memory pressure.
+*/
+   list_sort(NULL, >validated, cmp_size_smaller_first);
+
ttm_eu_fence_buffer_objects(>ticket,
>validated,
parser->ib.fence);
-- 
1.8.3.2

[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves

[Christian König]

Am 26.02.2014 18:56, schrieb Marek Ol??k:
> On Mon, Feb 24, 2014 at 5:20 PM, Christian K?nig
>  wrote:
>> Am 24.02.2014 16:20, schrieb Marek Ol??k:
>>
>>> From: Marek Ol??k 
>>>
>>> The statistics are:
>>> - VRAM usage in bytes
>>> - GTT usage in bytes
>>> - number of bytes moved by TTM
>>>
>>> The last one is actually a counter, so you need to sample it before and
>>> after
>>> command submission and take the difference.
>>>
>>> This is useful for finding performance bottlenecks. Userspace queries are
>>> also added.
>>>
>>> Signed-off-by: Marek Ol??k 
>>> ---
>>>drivers/gpu/drm/radeon/radeon.h|  5 +
>>>drivers/gpu/drm/radeon/radeon_device.c |  1 +
>>>drivers/gpu/drm/radeon/radeon_kms.c| 15 ++
>>>drivers/gpu/drm/radeon/radeon_object.c | 38
>>> +-
>>>drivers/gpu/drm/radeon/radeon_object.h |  2 +-
>>>drivers/gpu/drm/radeon/radeon_ttm.c| 10 -
>>>include/uapi/drm/radeon_drm.h  |  3 +++
>>>7 files changed, 71 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>>> b/drivers/gpu/drm/radeon/radeon.h
>>> index 3f10782..d37a57a 100644
>>> --- a/drivers/gpu/drm/radeon/radeon.h
>>> +++ b/drivers/gpu/drm/radeon/radeon.h
>>> @@ -2307,6 +2307,11 @@ struct radeon_device {
>>>  /* virtual memory */
>>>  struct radeon_vm_managervm_manager;
>>>  struct mutexgpu_clock_mutex;
>>> +   /* memory stats */
>>> +   struct mutexmemory_stats_mutex;
>>> +   uint64_tvram_usage;
>>> +   uint64_tgtt_usage;
>>> +   uint64_tnum_bytes_moved;
>>
>> As far as I can see you could make those tree values atomic64_t instead and
>> avoid the mutex.
> I'm afraid I cannot use atomic64_t. It doesn't work on x86 32-bit.
> This seems to be a no-op:
>
> u64 size = (u64)bo->num_pages << PAGE_SHIFT;
> atomic64_add(size, >num_bytes_moved);

Are you sure about this? Haven't tested x86 32-bit in a long time, but 
we use atomic64 all around the place and they usually work perfectly.

Christian.

> Marek

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

--- Comment #66 from Pali Roh?r  ---
@Tom Stellard: Will you prepare new patch for testing? And when you include
this fix into mesa?

-- 
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/20140226/2c763a0f/attachment.html>

[Bug 15701] glMultiDrawElements() yelds strange results in a display list.

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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/20140226/a2aa11d7/attachment.html>

[Bug 27702] [KMS] rv280 segfaults in texdown becnhmark

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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/20140226/9c6629d9/attachment.html>

[Bug 25676] Radeon hangs in RADEONWaitForIdleCP in bubble3d screensaver

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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/20140226/9c1fbb24/attachment.html>

[Intel-gfx] [PATCH 1/5] drm: Use correct spinlock flavor in drm_vblank_get()

[Jesse Barnes]

On Fri, 21 Feb 2014 21:03:31 +0200
ville.syrjala at linux.intel.com wrote:

> From: Peter Hurley 
> 
> The irq flags state is already established by the outer
> spin_lock_irqsave(); re-disabling irqs is redundant.
> 
> Signed-off-by: Peter Hurley 
> ---
>  drivers/gpu/drm/drm_irq.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c2676b5..baa12e7 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -882,13 +882,13 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, int crtc)
>   */
>  int drm_vblank_get(struct drm_device *dev, int crtc)
>  {
> - unsigned long irqflags, irqflags2;
> + unsigned long irqflags;
>   int ret = 0;
>  
>   spin_lock_irqsave(>vbl_lock, irqflags);
>   /* Going from 0->1 means we have to enable interrupts again */
>   if (atomic_add_return(1, >vblank[crtc].refcount) == 1) {
> - spin_lock_irqsave(>vblank_time_lock, irqflags2);
> + spin_lock(>vblank_time_lock);
>   if (!dev->vblank[crtc].enabled) {
>   /* Enable vblank irqs under vblank_time_lock protection.
>* All vblank count & timestamp updates are held off
> @@ -906,7 +906,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
>   drm_update_vblank_count(dev, crtc);
>   }
>   }
> - spin_unlock_irqrestore(>vblank_time_lock, irqflags2);
> + spin_unlock(>vblank_time_lock);
>   } else {
>   if (!dev->vblank[crtc].enabled) {
>   atomic_dec(>vblank[crtc].refcount);

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center

[Intel-gfx] [PATCH 2/5] drm: Make the vblank disable timer per-crtc

[Jesse Barnes]

On Fri, 21 Feb 2014 21:03:32 +0200
ville.syrjala at linux.intel.com wrote:

> From: Ville Syrj?l? 
> 
> Currently there's one per-device vblank disable timer, and it gets
> reset wheneven the vblank refcount for any crtc drops to zero. That
> means that one crtc could accidentally be keeping the vblank interrupts
> for other crtcs enabled even if there are no users for them. Make the
> disable timer per-crtc to avoid this issue.
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/drm_irq.c | 40 +---
>  include/drm/drmP.h|  4 +++-
>  2 files changed, 24 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index baa12e7..3211158 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -167,33 +167,34 @@ static void vblank_disable_and_save(struct drm_device 
> *dev, int crtc)
>  
>  static void vblank_disable_fn(unsigned long arg)
>  {
> - struct drm_device *dev = (struct drm_device *)arg;
> + struct drm_vblank_crtc *vblank = (void *)arg;
> + struct drm_device *dev = vblank->dev;
>   unsigned long irqflags;
> - int i;
> + int crtc = vblank->crtc;
>  
>   if (!dev->vblank_disable_allowed)
>   return;
>  
> - for (i = 0; i < dev->num_crtcs; i++) {
> - spin_lock_irqsave(>vbl_lock, irqflags);
> - if (atomic_read(>vblank[i].refcount) == 0 &&
> - dev->vblank[i].enabled) {
> - DRM_DEBUG("disabling vblank on crtc %d\n", i);
> - vblank_disable_and_save(dev, i);
> - }
> - spin_unlock_irqrestore(>vbl_lock, irqflags);
> + spin_lock_irqsave(>vbl_lock, irqflags);
> + if (atomic_read(>refcount) == 0 && vblank->enabled) {
> + DRM_DEBUG("disabling vblank on crtc %d\n", crtc);
> + vblank_disable_and_save(dev, crtc);
>   }
> + spin_unlock_irqrestore(>vbl_lock, irqflags);
>  }
>  
>  void drm_vblank_cleanup(struct drm_device *dev)
>  {
> + int crtc;
> +
>   /* Bail if the driver didn't call drm_vblank_init() */
>   if (dev->num_crtcs == 0)
>   return;
>  
> - del_timer_sync(>vblank_disable_timer);
> -
> - vblank_disable_fn((unsigned long)dev);
> + for (crtc = 0; crtc < dev->num_crtcs; crtc++) {
> + del_timer_sync(>vblank[crtc].disable_timer);
> + vblank_disable_fn((unsigned long)>vblank[crtc]);
> + }
>  
>   kfree(dev->vblank);
>  
> @@ -205,8 +206,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
>  {
>   int i, ret = -ENOMEM;
>  
> - setup_timer(>vblank_disable_timer, vblank_disable_fn,
> - (unsigned long)dev);
>   spin_lock_init(>vbl_lock);
>   spin_lock_init(>vblank_time_lock);
>  
> @@ -216,8 +215,13 @@ int drm_vblank_init(struct drm_device *dev, int 
> num_crtcs)
>   if (!dev->vblank)
>   goto err;
>  
> - for (i = 0; i < num_crtcs; i++)
> + for (i = 0; i < num_crtcs; i++) {
> + dev->vblank[i].dev = dev;
> + dev->vblank[i].crtc = i;
>   init_waitqueue_head(>vblank[i].queue);
> + setup_timer(>vblank[i].disable_timer, vblank_disable_fn,
> + (unsigned long)>vblank[i]);
> + }
>  
>   DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
>  
> @@ -934,7 +938,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
>   /* Last user schedules interrupt disable */
>   if (atomic_dec_and_test(>vblank[crtc].refcount) &&
>   (drm_vblank_offdelay > 0))
> - mod_timer(>vblank_disable_timer,
> + mod_timer(>vblank[crtc].disable_timer,
> jiffies + ((drm_vblank_offdelay * HZ)/1000));
>  }
>  EXPORT_SYMBOL(drm_vblank_put);
> @@ -943,8 +947,6 @@ EXPORT_SYMBOL(drm_vblank_put);
>   * drm_vblank_off - disable vblank events on a CRTC
>   * @dev: DRM device
>   * @crtc: CRTC in question
> - *
> - * Caller must hold event lock.
>   */
>  void drm_vblank_off(struct drm_device *dev, int crtc)
>  {
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 04a7f31..f974da9 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1077,14 +1077,17 @@ struct drm_pending_vblank_event {
>  };
>  
>  struct drm_vblank_crtc {
> + struct drm_device *dev; /* pointer to the drm_device */
>   wait_queue_head_t queue;/**< VBLANK wait queue */
>   struct timeval time[DRM_VBLANKTIME_RBSIZE]; /**< timestamp of 
> current count */
> + struct timer_list disable_timer;/* delayed disable 
> timer */
>   atomic_t count; /**< number of VBLANK interrupts */
>   atomic_t refcount;  /* number of users of vblank 
> interruptsper crtc */
>   u32 last;   /* protected by dev->vbl_lock, used */
>   /* for wraparound 

[Intel-gfx] [PATCH 3/5] drm: Allow the driver to reject vblank requests only when it really has the vblank interrupts disabled

[Jesse Barnes]

On Fri, 21 Feb 2014 21:03:33 +0200
ville.syrjala at linux.intel.com wrote:

> From: Ville Syrj?l? 
> 
> Allow the driver to specify whether all new vblank requests after
> drm_vblank_off() should be rejected. And add a counterpart called
> drm_vblank_on() which will again allow vblank requests to come in.
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/armada/armada_crtc.c |  2 +-
>  drivers/gpu/drm/drm_irq.c| 29 -
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  2 +-
>  drivers/gpu/drm/gma500/gma_display.c |  2 +-
>  drivers/gpu/drm/i915/intel_display.c |  6 +++---
>  drivers/gpu/drm/tegra/dc.c   |  2 +-
>  include/drm/drmP.h   |  4 +++-
>  7 files changed, 38 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index d8e3982..74317b2 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -257,7 +257,7 @@ static void armada_drm_vblank_off(struct armada_crtc 
> *dcrtc)
>* Tell the DRM core that vblank IRQs aren't going to happen for
>* a while.  This cleans up any pending vblank events for us.
>*/
> - drm_vblank_off(dev, dcrtc->num);
> + drm_vblank_off(dev, dcrtc->num, false);
>  
>   /* Handle any pending flip event. */
>   spin_lock_irq(>event_lock);
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3211158..6e5d820 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -890,6 +890,12 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
>   int ret = 0;
>  
>   spin_lock_irqsave(>vbl_lock, irqflags);
> +
> + if (dev->vblank[crtc].reject) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
>   /* Going from 0->1 means we have to enable interrupts again */
>   if (atomic_add_return(1, >vblank[crtc].refcount) == 1) {
>   spin_lock(>vblank_time_lock);
> @@ -917,6 +923,8 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
>   ret = -EINVAL;
>   }
>   }
> +
> + out:
>   spin_unlock_irqrestore(>vbl_lock, irqflags);
>  
>   return ret;
> @@ -947,8 +955,9 @@ EXPORT_SYMBOL(drm_vblank_put);
>   * drm_vblank_off - disable vblank events on a CRTC
>   * @dev: DRM device
>   * @crtc: CRTC in question
> + * @reject: reject drm_vblank_get() until drm_vblank_on() has been called?
>   */
> -void drm_vblank_off(struct drm_device *dev, int crtc)
> +void drm_vblank_off(struct drm_device *dev, int crtc, bool reject)
>  {
>   struct drm_pending_vblank_event *e, *t;
>   struct timeval now;
> @@ -956,6 +965,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
>   unsigned int seq;
>  
>   spin_lock_irqsave(>vbl_lock, irqflags);
> + dev->vblank[crtc].reject = reject;
>   vblank_disable_and_save(dev, crtc);
>   wake_up(>vblank[crtc].queue);
>  
> @@ -979,6 +989,22 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
>  }
>  EXPORT_SYMBOL(drm_vblank_off);
>  
> +
> +/**
> + * drm_vblank_on - enable vblank events on a CRTC
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + */
> +void drm_vblank_on(struct drm_device *dev, int crtc)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>vbl_lock, irqflags);
> + dev->vblank[crtc].reject = false;
> + spin_unlock_irqrestore(>vbl_lock, irqflags);
> +}
> +EXPORT_SYMBOL(drm_vblank_on);
> +
>  /**
>   * drm_vblank_pre_modeset - account for vblanks across mode sets
>   * @dev: DRM device
> @@ -1224,6 +1250,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>   DRM_WAIT_ON(ret, dev->vblank[crtc].queue, 3 * HZ,
>   (((drm_vblank_count(dev, crtc) -
>  vblwait->request.sequence) <= (1 << 23)) ||
> +  dev->vblank[crtc].reject ||
>!dev->irq_enabled));
>  
>   if (ret != -EINTR) {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index ebc0150..e2d6b9d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -68,7 +68,7 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
> mode)
>   /* wait for the completion of page flip. */
>   wait_event(exynos_crtc->pending_flip_queue,
>   atomic_read(_crtc->pending_flip) == 0);
> - drm_vblank_off(crtc->dev, exynos_crtc->pipe);
> + drm_vblank_off(crtc->dev, exynos_crtc->pipe, false);
>   }
>  
>   exynos_drm_fn_encoder(crtc, , exynos_drm_encoder_crtc_dpms);
> diff --git a/drivers/gpu/drm/gma500/gma_display.c 
> b/drivers/gpu/drm/gma500/gma_display.c
> index 386de2c..ff18220 100644
> --- a/drivers/gpu/drm/gma500/gma_display.c
> +++ b/drivers/gpu/drm/gma500/gma_display.c
> @@ -281,7 +281,7 @@ void 

[Intel-gfx] [PATCH 4/5] drm: Allow reenabling of vblank interrupts even if refcount>0

[Jesse Barnes]

On Fri, 21 Feb 2014 21:03:34 +0200
ville.syrjala at linux.intel.com wrote:

> From: Ville Syrj?l? 
> 
> If someone holds a vblank reference across the modeset, and after/during
> the modeset someone tries to grab a vblank reference, the current code
> won't re-enable the vblank interrupts. That's not good, so instead allow
> the driver to choose whether drm_vblank_get() should always enable the
> interrupts regardless of the refcount.
> 
> Combined with the drm_vblank_off/drm_vblank_on reject mechanism, this
> can also be used to allow drivers to use vblank interrupts during
> modeset, whether or not someone is currently holding a vblank reference.
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/drm_irq.c | 3 ++-
>  include/drm/drmP.h| 6 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 6e5d820..d613b6f 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -897,7 +897,8 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
>   }
>  
>   /* Going from 0->1 means we have to enable interrupts again */
> - if (atomic_add_return(1, >vblank[crtc].refcount) == 1) {
> + if (atomic_add_return(1, >vblank[crtc].refcount) == 1 ||
> + dev->vblank_always_enable_on_get) {
>   spin_lock(>vblank_time_lock);
>   if (!dev->vblank[crtc].enabled) {
>   /* Enable vblank irqs under vblank_time_lock protection.
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index ee40483..3eca0ee 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1156,6 +1156,12 @@ struct drm_device {
>*/
>   bool vblank_disable_allowed;
>  
> + /*
> +  * Should a non-rejected drm_vblank_get() always enable the
> +  * vblank interrupt regardless of the current refcount?
> +  */
> + bool vblank_always_enable_on_get;
> +
>   /* array of size num_crtcs */
>   struct drm_vblank_crtc *vblank;
>  

This seems like the sort of thing it would be good to have a test
for... I'm surprised we haven't hit it yet.  But in looking at the code
I don't see where we'd re-enable things properly in this situation, so
I guess it's a real bug.

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center

[Intel-gfx] [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races

[Jesse Barnes]

On Tue, 25 Feb 2014 11:58:26 +0900
Michel D?nzer  wrote:

> On Mon, 2014-02-24 at 14:11 +0200, Ville Syrj?l? wrote:
> > On Mon, Feb 24, 2014 at 12:48:55PM +0900, Michel D?nzer wrote:
> > > On Fre, 2014-02-21 at 21:03 +0200, ville.syrjala at linux.intel.com wrote:
> > > > 
> > > > We can kill of the drm_vblank_{pre,post}_modeset() calls since those are
> > > > there simply to make drm_vblank_get() fail during a modeset.
> > > 
> > > Actually, their original purpose was to keep the DRM vblank counter
> > > consistent across modesets, assuming the modeset resets the hardware
> > > vblank counter.
> > 
> > I see. Well, actually I really don't. The code is too funky for me to
> > tell what it actually ends up doing. The obvious way would be to
> > resample the hardware counter at drm_vblank_post_modeset(), which the
> > code certainly doesn't do. But maybe it did something sensible in the
> > past.
> 
> When the pre/post-modeset hooks were originally added, it worked like
> this: the pre-modeset hook enabled the vblank interrupt, which updated
> the DRM vblank counter from the driver/HW counter. The post-modeset hook
> disabled the vblank interrupt again, which recorded the post-modeset
> driver/HW counter value.
> 
> But the vblank code has changed a lot since then, not sure it still
> works like that.

Yeah it's changed a bit.  I think Rob added the latest bits there.
They were originally in place to support both UMS and KMS drivers,
which is as ugly as it sounds.

As long as nothing breaks (vblank vs dpms, vblank vs modeset, vblank vs
high precision timestamps, vblank vs refcount) I think your code is ok.

Cc'ing Mario for another opinion too.  This makes me nervous but it
seems ok.

I think you should update the docbook (with examples) as well so other
driver writers will know how to use this stuff.

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH] drm/fb-helper: Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par()

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par() to
make sure extra planes get disabled whenever fbcon takes over.

Otherwise the code in drm_fb_helper_set_par() was already doing the
exact same thing as drm_fb_helper_restore_fbdev_mode(), so this doesn't
change the behaviour in any other way.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_fb_helper.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d99df15..ca100d6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -809,8 +809,6 @@ int drm_fb_helper_set_par(struct fb_info *info)
struct drm_fb_helper *fb_helper = info->par;
struct drm_device *dev = fb_helper->dev;
struct fb_var_screeninfo *var = >var;
-   int ret;
-   int i;

if (var->pixclock != 0) {
DRM_ERROR("PIXEL CLOCK SET\n");
@@ -818,13 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
}

drm_modeset_lock_all(dev);
-   for (i = 0; i < fb_helper->crtc_count; i++) {
-   ret = 
drm_mode_set_config_internal(_helper->crtc_info[i].mode_set);
-   if (ret) {
-   drm_modeset_unlock_all(dev);
-   return ret;
-   }
-   }
+   drm_fb_helper_restore_fbdev_mode(fb_helper);
drm_modeset_unlock_all(dev);

if (fb_helper->delayed_hotplug) {
-- 
1.8.3.2

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

[Guennadi Liakhovetski]

Hi Russell

(I suspect this my email will be rejected by ALKML too like other my 
recent emails, but at least other MLs will pick it up and individual CCs 
too, so, if replying, maybe it would be good to keep my entire reply, all 
the more that it's going to be very short)

On Thu, 2 Jan 2014, Russell King wrote:

> Subsystems such as ALSA, DRM and others require a single card-level
> device structure to represent a subsystem.  However, firmware tends to
> describe the individual devices and the connections between them.
> 
> Therefore, we need a way to gather up the individual component devices
> together, and indicate when we have all the component devices.
> 
> We do this in DT by providing a "superdevice" node which specifies
> the components, eg:
> 
>   imx-drm {
>   compatible = "fsl,drm";
>   crtcs = <>;
>   connectors = <>;
>   };

It is a pity linux-media wasn't CC'ed and apparently V4L developers didn't 
notice this and other related patches in a "clean up" series, and now this 
patch is already in the mainline. But at least I'd like to ask whether the 
bindings, defined in 
Documentation/devicetree/bindings/media/video-interfaces.txt and 
implemented in drivers/media/v4l2-core/v4l2-of.c have been considered for 
this job, and - if so - why have they been found unsuitable? Wouldn't it 
have been better to use and - if needed - extend them to cover any 
deficiencies? Even though the implementation is currently located under 
drivers/media/v4l2-code/ it's pretty generic and should be easily 
transferable to a more generic location.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[RFCv4 09/14] drm: convert plane to properties/state

[Sean Paul]

On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark  wrote:
> Break the mutable state of a plane out into a separate structure
> and use atomic properties mechanism to set plane attributes.  This
> makes it easier to have some helpers for plane->set_property()
> and for checking for invalid params.  The idea is that individual
> drivers can wrap the state struct in their own struct which adds
> driver specific parameters, for easy build-up of state across
> multiple set_property() calls and for easy atomic commit or roll-
> back.
>
> The same should be done for CRTC, encoder, and connector, but this
> patch only includes the first part (plane).


Hi Rob,
I've been tracking down a crash that came up on my exynos board when I
applied this patch. I hope you can hold my hand a little bit and give
some guidance.



> +static int
> +drm_atomic_helper_commit_plane_state(struct drm_plane *plane,
> +   struct drm_plane_state *pstate)
> +{
> +   struct drm_framebuffer *old_fb = NULL, *fb = NULL;
> +   int ret = 0;
> +
> +   fb = pstate->fb;
> +
> +   if (pstate->crtc && fb) {
> +   ret = plane->funcs->update_plane(plane, pstate->crtc, 
> pstate->fb,
> +   pstate->crtc_x, pstate->crtc_y, pstate->crtc_w, 
> pstate->crtc_h,
> +   pstate->src_x,  pstate->src_y,  pstate->src_w,  
> pstate->src_h);
> +   if (!ret) {
> +   /* on success, update state and fb refcnting: */
> +   /* NOTE: if we ensure no driver sets plane->state->fb 
> = NULL
> +* on disable, we can move this up a level and not 
> duplicate
> +* nearly the same thing for both update_plane and 
> disable_plane
> +* cases..  I leave it like this for now to be 
> paranoid due to
> +* the slightly different ordering in the two cases 
> in the
> +* original code.
> +*/
> +   old_fb = plane->state->fb;

I think this is slightly different than what we had before in
setplane. In the previous code, we had:

ret = plane->funcs->update_plane(plane, crtc, fb,
  plane_req->crtc_x,
plane_req->crtc_y,
  plane_req->crtc_w,
plane_req->crtc_h,
  plane_req->src_x,
plane_req->src_y,
  plane_req->src_w,
plane_req->src_h);
if (!ret) {
old_fb = plane->fb;
fb = NULL;
plane->crtc = crtc;
plane->fb = fb;
}

In this case, we'd unreference old_fb which is the previous plane->fb.
AFAICT, update_plane did not set plane->fb to fb, so it would, in
fact, be the old plane.

In the new code, drm_mode_setplane calls drm_mode_plane_set_obj_prop
on fb_id, which will update plane->state->fb. Then we come in here and
unreference it as old_fb. I _believe_ we're taking one more reference
than we need in this case.

What I'm seeing in exynos is that when we setplane to an fb, we leave
it with refcount == 1. If we disable that plane, we'll free the fb.
Unfortunately, this leaves the fb in the fbs list and the next time we
try to iterate that list Bad Things Happen.

Does this make any sense?

Sean

> +   swap_plane_state(plane, pstate->state);
> +   fb = NULL;
> +   }
> +   } else {
> +   old_fb = plane->state->fb;
> +   plane->funcs->disable_plane(plane);
> +   swap_plane_state(plane, pstate->state);
> +   }
> +
> +
> +   if (fb)
> +   drm_framebuffer_unreference(fb);
> +   if (old_fb)
> +   drm_framebuffer_unreference(old_fb);
> +
> +   return ret;
> +}
>



> +int drm_plane_set_property(struct drm_plane *plane,
> +   struct drm_plane_state *state,
> +   struct drm_property *property,
> +   uint64_t value, void *blob_data)
> +{
> +   struct drm_device *dev = plane->dev;
> +   struct drm_mode_config *config = >mode_config;
> +
> +   drm_object_property_set_value(>base,
> +   >propvals, property, value, blob_data);
> +
> +   if (property == config->prop_fb_id) {
> +   state->new_fb = true;
> +   state->fb = drm_framebuffer_lookup(dev, value);
> +   } else if (property == config->prop_crtc_id) {
> +   struct drm_mode_object *obj = drm_property_get_obj(property, 
> value);
> +   struct drm_crtc *crtc = obj ? obj_to_crtc(obj) : NULL;
> +   /* take the lock of the incoming crtc as well, moving
> +* plane between crtcs is synchronized on both incoming
> +* and outgoing crtc.
> +*/
> +   if (crtc) {
> +   int ret = drm_modeset_lock(>mutex, 
> state->state);
> + 

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

[Russell King - ARM Linux]

On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> Hi Russell
> 
> (I suspect this my email will be rejected by ALKML too like other my 
> recent emails, but at least other MLs will pick it up and individual CCs 
> too, so, if replying, maybe it would be good to keep my entire reply, all 
> the more that it's going to be very short)
> 
> On Thu, 2 Jan 2014, Russell King wrote:
> 
> > Subsystems such as ALSA, DRM and others require a single card-level
> > device structure to represent a subsystem.  However, firmware tends to
> > describe the individual devices and the connections between them.
> > 
> > Therefore, we need a way to gather up the individual component devices
> > together, and indicate when we have all the component devices.
> > 
> > We do this in DT by providing a "superdevice" node which specifies
> > the components, eg:
> > 
> > imx-drm {
> > compatible = "fsl,drm";
> > crtcs = <>;
> > connectors = <>;
> > };
> 
> It is a pity linux-media wasn't CC'ed and apparently V4L developers didn't 
> notice this and other related patches in a "clean up" series, and now this 
> patch is already in the mainline. But at least I'd like to ask whether the 
> bindings, defined in 
> Documentation/devicetree/bindings/media/video-interfaces.txt and 
> implemented in drivers/media/v4l2-core/v4l2-of.c have been considered for 
> this job, and - if so - why have they been found unsuitable? Wouldn't it 
> have been better to use and - if needed - extend them to cover any 
> deficiencies? Even though the implementation is currently located under 
> drivers/media/v4l2-code/ it's pretty generic and should be easily 
> transferable to a more generic location.

The component helpers have nothing to do with DT apart from solving
the problem of how to deal with subsystems which expect a single device,
but we have a group of devices and their individual drivers to cope with.
Subsystems like DRM and ALSA.

It is completely agnostic to whether you're using platform data, DT or
even ACPI - this code could *not* care less.  None of that comes anywhere
near what this patch does.  It merely provides a way to collect up
individual devices from co-operating drivers, and control their binding
such that a subsystem like DRM or ALSA can be presented with a "card"
level view of the hardware rather than a multi-device medusa with all
the buggy, racy, crap fsckage that people come up to make that kind of
thing work.

Now, as for the binding above, first, what does "eg" mean... and
secondly, how would a binding which refers to crtcs and connectors
have anything to do with ALSA?  Clearly this isn't an example of a
binding for an ALSA use, which was talked about in the very first
line of the above commit commentry.  So it's quite clear that what is
given there is an example of how it /could/ be used.

I suppose I could have instead turned imx-drm into a completely unusable
mess by not coming up with some kind of binding, and instead submitted
a whole pile of completely untested code.  Alternatively, I could've
used the OF binding as you're suggesting, but that would mean radically
changing the /existing/ bindings for the IPU as a whole - something
which others are better suited at as they have a /much/ better
understanding of the complexities of this hardware than I.

So, what I have done is implemented - for a driver in staging which is
still subject to ongoing development and non-stable DT bindings -
something which allows forward progress with a *minimum* of disruption
to the existing DT bindings for everyone, while still allowing forward
progress.

Better bindings for imx-drm are currently being worked on.  Philipp
Zabel of Pengutronix is currently looking at it, and has posted many
RFC patches on this very subject, including moving the V4L2 OF helpers
to a more suitable location.  OF people have been involved in that
discussion over the preceding weeks, and there's a working implementation
of imx-drm using these helpers from v4l2.

I'm finding people who are working in the same area and trying to get
everyone talking to each other so that we /do/ end up with a set of
bindings for the display stuff which are suitable for everyone.  Tomi
from TI has already expressed his input to this ongoing discussion.

You're welcome to get involved in those discussions too.

I hope this makes it clear, and clears up the confusion.

Thanks.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

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

--- Comment #13 from Tom Stellard  ---
(In reply to comment #12)
> I tried your patch with the newest SVN version of LLVM but got a different
> error (http://shadowice.org/~flocke/linux/misc/ADVGame_crash_backtrace.log).
> 
> Can I safely apply your patch to LLVM 3.4 to find out if the error comes
> from the SVN version?

Can you post the output of R600_DEBUG=ps,vs with the patch applied?

-- 
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/20140226/457572b6/attachment.html>

[RFCv4 09/14] drm: convert plane to properties/state

[Rob Clark]

On Wed, Feb 26, 2014 at 4:30 PM, Sean Paul  wrote:
> On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark  wrote:
>> Break the mutable state of a plane out into a separate structure
>> and use atomic properties mechanism to set plane attributes.  This
>> makes it easier to have some helpers for plane->set_property()
>> and for checking for invalid params.  The idea is that individual
>> drivers can wrap the state struct in their own struct which adds
>> driver specific parameters, for easy build-up of state across
>> multiple set_property() calls and for easy atomic commit or roll-
>> back.
>>
>> The same should be done for CRTC, encoder, and connector, but this
>> patch only includes the first part (plane).
>
>
> Hi Rob,
> I've been tracking down a crash that came up on my exynos board when I
> applied this patch. I hope you can hold my hand a little bit and give
> some guidance.
>
> 
>
>> +static int
>> +drm_atomic_helper_commit_plane_state(struct drm_plane *plane,
>> +   struct drm_plane_state *pstate)
>> +{
>> +   struct drm_framebuffer *old_fb = NULL, *fb = NULL;
>> +   int ret = 0;
>> +
>> +   fb = pstate->fb;
>> +
>> +   if (pstate->crtc && fb) {
>> +   ret = plane->funcs->update_plane(plane, pstate->crtc, 
>> pstate->fb,
>> +   pstate->crtc_x, pstate->crtc_y, pstate->crtc_w, 
>> pstate->crtc_h,
>> +   pstate->src_x,  pstate->src_y,  pstate->src_w,  
>> pstate->src_h);
>> +   if (!ret) {
>> +   /* on success, update state and fb refcnting: */
>> +   /* NOTE: if we ensure no driver sets 
>> plane->state->fb = NULL
>> +* on disable, we can move this up a level and not 
>> duplicate
>> +* nearly the same thing for both update_plane and 
>> disable_plane
>> +* cases..  I leave it like this for now to be 
>> paranoid due to
>> +* the slightly different ordering in the two cases 
>> in the
>> +* original code.
>> +*/
>> +   old_fb = plane->state->fb;
>
> I think this is slightly different than what we had before in
> setplane. In the previous code, we had:
>
> ret = plane->funcs->update_plane(plane, crtc, fb,
>   plane_req->crtc_x,
> plane_req->crtc_y,
>   plane_req->crtc_w,
> plane_req->crtc_h,
>   plane_req->src_x,
> plane_req->src_y,
>   plane_req->src_w,
> plane_req->src_h);
> if (!ret) {
> old_fb = plane->fb;
> fb = NULL;
> plane->crtc = crtc;
> plane->fb = fb;
> }
>
> In this case, we'd unreference old_fb which is the previous plane->fb.
> AFAICT, update_plane did not set plane->fb to fb, so it would, in
> fact, be the old plane.

to be honest, I need to dig up that branch again and remember (and
rebase it while I'm at it)..

I don't think the driver should be changing state->fb (ie. the state
object should in theory, once constructed, be a sort of constant
thing).  So until swap_plane_state() plane->state->fb is *supposed* to
be the old fb.

For crtc, as there were so many places in code accessing crtc->fb (and
it was pretty intertwined in the crtc helpers), the way I left it as:
crtc->state->fb is what is requested by userspace, and crtc->fb is
what is currently used (which is updated to the new cstate->fb in the
course of modeset).

I don't remember if I left it the same way for plane (which isn't
referenced in nearly as many places, and which doesn't have a big
chunk of modeset helper to care about).

> In the new code, drm_mode_setplane calls drm_mode_plane_set_obj_prop
> on fb_id, which will update plane->state->fb. Then we come in here and
> unreference it as old_fb. I _believe_ we're taking one more reference
> than we need in this case.

well, it should be updating 'pstate', what will become the new
plane->state..  But not the current plane->state.

BR,
-R

> What I'm seeing in exynos is that when we setplane to an fb, we leave
> it with refcount == 1. If we disable that plane, we'll free the fb.
> Unfortunately, this leaves the fb in the fbs list and the next time we
> try to iterate that list Bad Things Happen.
>
> Does this make any sense?
>
> Sean
>
>> +   swap_plane_state(plane, pstate->state);
>> +   fb = NULL;
>> +   }
>> +   } else {
>> +   old_fb = plane->state->fb;
>> +   plane->funcs->disable_plane(plane);
>> +   swap_plane_state(plane, pstate->state);
>> +   }
>> +
>> +
>> +   if (fb)
>> +   drm_framebuffer_unreference(fb);
>> +   if (old_fb)
>> +   drm_framebuffer_unreference(old_fb);
>> +
>> +   return ret;
>> +}
>>
>
> 
>
>> +int 

[PATCH] drm/radeon: free uvd ring on unload

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

From: Jerome Glisse 

Need to free the uvd ring. Also reshuffle gart tear down to
happen after uvd tear down.

Signed-off-by: J?r?me Glisse 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_uvd.c | 2 ++
 drivers/gpu/drm/radeon/rv770.c  | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 5623e75..8a2c010 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5475,9 +5475,9 @@ void evergreen_fini(struct radeon_device *rdev)
radeon_wb_fini(rdev);
radeon_ib_pool_fini(rdev);
radeon_irq_kms_fini(rdev);
-   evergreen_pcie_gart_fini(rdev);
uvd_v1_0_fini(rdev);
radeon_uvd_fini(rdev);
+   evergreen_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
radeon_gem_fini(rdev);
radeon_fence_driver_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 6781fee..3e6804b 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -171,6 +171,8 @@ void radeon_uvd_fini(struct radeon_device *rdev)

radeon_bo_unref(>uvd.vcpu_bo);

+   radeon_ring_fini(rdev, >ring[R600_RING_TYPE_UVD_INDEX]);
+
release_firmware(rdev->uvd_fw);
 }

diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 6c772e5..4e37a42 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1955,9 +1955,9 @@ void rv770_fini(struct radeon_device *rdev)
radeon_wb_fini(rdev);
radeon_ib_pool_fini(rdev);
radeon_irq_kms_fini(rdev);
-   rv770_pcie_gart_fini(rdev);
uvd_v1_0_fini(rdev);
radeon_uvd_fini(rdev);
+   rv770_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
radeon_gem_fini(rdev);
radeon_fence_driver_fini(rdev);
-- 
1.8.3.1

Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

Hi,

On Tue, Feb 25, 2014 at 11:10 PM, Borislav Petkov  wrote:
> On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
>
>> I am on tip.git at cfbf8d4 Linux 3.14-rc4.
>> and I don't see the problem (using Ubuntu Saucy).
>
> Also IVB, model 58?
>
Yes.

>> Given what you commented out, it seems like you're saying
>> something goes wrong with pci_get_device().
>
> Probably. I'll add some debug printk's tomorrow to shed some more light
> on the matter.
>
>> Am I missing some pm callbacks?
>
> Dunno. What do you mean by "pm callbacks" exactly? I don't know that
> code so I have to ask.
>
power management callbacks.

>> The uncore IMC is not used internally.
>
> By IMC I'm assuming this PIC dev:
>
> #define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
>
> ?
>
Yes. Needs to point to the DRAM controller.

> And "internally" means by BIOS or something behind the curtains like
> SMM...?
>
I meant by the kernel.

[PATCH] a crash in mga_driver_irq_uninstall

[Mikulas Patocka]

Hi

I'm getting a reproducible crash in kernel MGA DRM driver.

The crash happens in the following way:

drm_release is called
drm_release calls drm_master_put(_priv->master);
drm_master_put drops a reference and calls drm_master_destroy
drm_master_destroy calls drm_rmmap_locked to unmap the card's mmio space
drm_release continues to execute
drm_release calls drm_lastclose
drm_lastclose calls drm_irq_uninstall
drm_irq_uninstall calls dev->driver->irq_uninstall (mga_driver_irq_uninstall)
mga_driver_irq_uninstall performs MGA_WRITE(MGA_IEN, 0), it crashes 
because the mmio range was unmapped 

The result are these two crashes - one in mga_driver_irq_uninstall and the 
other in mga_driver_irq_handler:

[44272.019284] BUG: unable to handle kernel paging request at e4831e1c
[44272.021000] IP: [] mga_driver_irq_uninstall+0x18/0x28 [mga]
[44272.021000] *pde = 1e7ba067 *pte = 
[44272.021000] Oops: 0002 [#1]
[44272.021000] Modules linked in: mga drm hid_generic usbhid hid ipv6 
cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_ondemand 
cpufreq_userspace plip spadfs hpfs nls_cp852 msdos fat matroxfb_base 
matroxfb_g450 matroxfb_accel cfbfillrect cfbimgblt cfbcopyarea 
matroxfb_DAC1064 g450_pll matroxfb_misc floppy dm_crypt snd_usb_audio 
snd_usbmidi_lib snd_hwdep snd_seq_midi snd_seq_midi_event snd_rawmidi 
snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer snd soundcore 
powernow_k6 pcspkr evdev ehci_pci via686a i2c_viapro e1000 i2c_core 
uhci_hcd ehci_hcd via_agp usbcore usb_common parport_pc agpgart parport 
dm_mod ext4 crc16
jbd2 mbcache sata_promise unix
[44272.021000] CPU: 0 PID: 3140 Comm: Xorg Not tainted 3.13.5 #5
[44272.021000] Hardware name: System Manufacturer Product Name/VA-503A, 
BIOS 4.51 PG 08/02/00
[44272.021000] task: c043ce80 ti: de662000 task.ti: de662000
[44272.021000] EIP: 0060:[] EFLAGS: 00213286 CPU: 0
[44272.021000] EIP is at mga_driver_irq_uninstall+0x18/0x28 [mga]
[44272.021000] EAX: de87fc00 EBX: de87fc00 ECX: e483 EDX: 
[44272.021000] ESI: 0001 EDI: 0001 EBP: 00203202 ESP: de663e58
[44272.021000]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[44272.021000] CR0: 8005003b CR2: e4831e1c CR3: 1e666000 CR4: 0090
[44272.021000] Stack:
[44272.021000]  e47d17ae  e47f0064 e47e6ca2 e47f0079 000f 
0187fc00 c0096e40
[44272.021000]  de87fc00 0001 de87fc00 e481a277 0001 e481ee1f 
e481eaa7 e481ee1d
[44272.021000]  de7a6880 00150012 e47d6b2d 00017915 e47d6b2d df401d00 
c0096e40 de87fc00
[44272.021000] Call Trace:
[44272.021000]  [] ? drm_irq_uninstall+0xae/0x180 [drm]
[44272.021000]  [] ? mga_do_cleanup_dma+0x237/0x300 [mga]
[44272.021000]  [] ? drm_ht_remove+0x2d/0x40 [drm]
[44272.021000]  [] ? drm_ht_remove+0x2d/0x40 [drm]
[44272.021000]  [] ? drm_lastclose+0x3e/0x180 [drm]
[44272.021000]  [] ? drm_release+0x37b/0x520 [drm]
[44272.021000]  [] ? __fput+0x72/0x1c0
[44272.021000]  [] ? task_work_run+0x79/0xa0
[44272.021000]  [] ? do_exit+0x18f/0x740
[44272.021000]  [] ? vfs_writev+0x2c/0x60
[44272.021000]  [] ? SyS_writev+0x4a/0xc0
[44272.021000]  [] ? do_group_exit+0x26/0x60
[44272.021000]  [] ? SyS_exit_group+0x11/0x20
[44272.021000]  [] ? syscall_call+0x7/0xb
[44272.021000] Code: 1e 00 00 b0 00 5b c3 8d b6 00 00 00 00 8d bf 00 00 00 
00 8b 90 d8 00 00 00 85 d2 74 1b 8b 92 dc 00 00 00 8b 4a 10 ba 00 00 00 00 
<89> 91 1c 1e 00 00 c6 80 80 00 00 00 00 c3 00 00 ba 00 f9 81 e4
[44272.021000] EIP: [] mga_driver_irq_uninstall+0x18/0x28 [mga] 
SS:ESP 0068:de663e58
[44272.021000] CR2: e4831e1c
[44272.021000] ---[ end trace 68cd6cc5ef884eb2 ]---
[44272.021000] Fixing recursive fault but reboot is needed!
[44272.651150] BUG: unable to handle kernel paging request at e4831e14
[44272.654217] IP: [] mga_driver_irq_handler+0x14/0xe0 [mga]
[44272.654217] *pde = 1e7ba067 *pte = 
[44272.654217] Oops:  [#2]
[44272.654217] Modules linked in: mga drm hid_generic usbhid hid ipv6 
cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_ondemand 
cpufreq_userspace plip spadfs hpfs nls_cp852 msdos fat matroxfb_base 
matroxfb_g450 matroxfb_accel cfbfillrect cfbimgblt cfbcopyarea 
matroxfb_DAC1064 g450_pll matroxfb_misc floppy dm_crypt snd_usb_audio 
snd_usbmidi_lib snd_hwdep snd_seq_midi snd_seq_midi_event snd_rawmidi 
snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer snd soundcore 
powernow_k6 pcspkr evdev ehci_pci via686a i2c_viapro e1000 i2c_core 
uhci_hcd ehci_hcd via_agp usbcore usb_common parport_pc agpgart parport 
dm_mod ext4 crc16
jbd2 mbcache sata_promise unix
[44272.654217] CPU: 0 PID: 0 Comm: swapper Tainted: G  D  3.13.5 
#5
[44272.654217] Hardware name: System Manufacturer Product Name/VA-503A, 
BIOS 4.51 PG 08/02/00
[44272.654217] task: c132f500 ti: df406000 task.ti: c1324000
[44272.654217] EIP: 0060:[] EFLAGS: 00210082 CPU: 0
[44272.654217] EIP is at mga_driver_irq_handler+0x14/0xe0 [mga]
[44272.654217] EAX: de87fc00 EBX: df640a00 ECX: e0860803 EDX: e483
[44272.654217] ESI: 0080 EDI: 

Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

Hi,

Ok, so I am getting the same error message as you.
I checked my syslog now.

I have my uncore_imc addr=0xfed1 (after masking)

And I also have pnp 00:01 overlapping the imc range completely.

What pnp device does  it really represent? the DRAM controller?

So I think my laptop behaves like yours.

On Wed, Feb 26, 2014 at 10:29 AM, Borislav Petkov  wrote:
> On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
>> > Also IVB, model 58?
>> >
>> Yes.
>
> Right, so it must be chipset-specific.
>
>> > Dunno. What do you mean by "pm callbacks" exactly? I don't know that
>> > code so I have to ask.
>> >
>> power management callbacks.
>
> Ok, just as I thought. But why would they be relevant if this happens
> very early during boot?
>
>> > #define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
>> Yes. Needs to point to the DRAM controller.
>
> It seems I have it :-)
>
> $ lspci -xxx -s 00.0
> 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller 
> (rev 09)
> 00: 86 80 54 01 06 00 90 20 09 00 00 06 00 00 00 00
>   ^
>
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 fa 21
> 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
> 40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00
> 50: 11 02 00 00 11 00 00 00 07 00 90 df 01 00 00 db
> 60: 05 00 00 f8 00 00 00 00 01 80 d1 fe 00 00 00 00
> 70: 00 00 00 fe 01 00 00 00 00 0c 00 fe 7f 00 00 00
> 80: 10 11 11 11 11 11 11 00 1a 00 00 00 00 00 00 00
> 90: 01 00 00 fe 01 00 00 00 01 00 50 1e 02 00 00 00
> a0: 01 00 00 00 02 00 00 00 01 00 60 1e 02 00 00 00
> b0: 01 00 a0 db 01 00 80 db 01 00 00 db 01 00 a0 df
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 09 00 0c 01 9b 61 00 e2 d0 00 e8 76 00 00 00 00
> f0: 00 00 00 01 00 00 00 00 c8 0f 09 00 00 00 00 00
>
> Anyway, here's some more debugging output and some more staring:
>
> So we're correctly getting 0x154 and then snb_uncore_imc_init_box()
> tries to ioremap 0xfed1 but this fails the resource map check with:
>
> [0.485356] resource map sanity check conflict: 0xfed1 0xfed15fff 
> 0xfed1 0xfed13fff pnp 00:01
>
> and the pnp 00:01 device already partially occupies that range (from
> /proc/iomem):
>
>   fed1-fed13fff : pnp 00:01
>
> Oh, and snb_uncore_imc_init_box() gets that address from
> SNB_UNCORE_PCI_IMC_BAR_OFFSET and SNB_UNCORE_PCI_IMC_BAR_OFFSET+4 and
> they start at offset 0x48 in the PCI config space above, i.e.
>
> 40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00
> ^^^
>
> which is 0x00fed10001 (the 0x1 bit disappears after addr &= ~(PAGE_SIZE - 
> 1);)
>
> So I'm guessing it is time to talk to platform guys and ask them why
> they're putting SNB_UNCORE_PCI_IMC_BAR_OFFSET{,+4} in an overlapping
> range with pnp 00:01.
>
> [0.484023] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [0.484108] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at 
> [8800cac3-8800cec2]
> [0.484971] DBG: will get device: 0x8086:154
> [0.485054] DBG: Got device, bus: 0x0
> [0.485254] DBG: ioremapping addr: 0xfed1
> [0.485356] resource map sanity check conflict: 0xfed1 0xfed15fff 
> 0xfed1 0xfed13fff pnp 00:01
> [0.485460] [ cut here ]
> [0.485544] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 
> __ioremap_caller+0x372/0x380()
> [0.485643] Info: mapping multiple BARs. Your kernel is fine.
> [0.485709] Modules linked in:
> [0.485935] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #6
> [0.486019] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 
> 11/13/2012
> [0.486117]  00ab 880213d01ad8 81611339 
> 0006
> [0.486411]  880213d01b28 880213d01b18 8104e9cc 
> 880213d01b08
> [0.488308]  c9c58000 fed1 fed1 
> 6000
> [0.488595] Call Trace:
> [0.488671]  [] dump_stack+0x4f/0x7c
> [0.488754]  [] warn_slowpath_common+0x8c/0xc0
> [0.488877]  [] warn_slowpath_fmt+0x46/0x50
> [0.488966]  [] __ioremap_caller+0x372/0x380
> [0.489052]  [] ? snb_uncore_imc_init_box+0x76/0xa0
> [0.489137]  [] ioremap_nocache+0x17/0x20
> [0.489221]  [] snb_uncore_imc_init_box+0x76/0xa0
> [0.489307]  [] uncore_pci_probe+0xe5/0x1e0
> [0.489391]  [] local_pci_probe+0x4e/0xa0
> [0.489474]  [] ? get_device+0x19/0x20
> [0.489558]  [] pci_device_probe+0xe1/0x130
> [0.489642]  [] driver_probe_device+0x7b/0x240
> [0.489726]  [] __driver_attach+0xab/0xb0
> [0.489834]  [] ? driver_probe_device+0x240/0x240
> [0.489920]  [] bus_for_each_dev+0x5e/0x90
> [0.490003]  [] driver_attach+0x1e/0x20
> [0.490086]  [] bus_add_driver+0x117/0x230
> [0.490170]  [] driver_register+0x64/0xf0
> [0.490251]  [] 

Info: mapping multiple BARs. Your kernel is fine.

[Rafael J. Wysocki]

On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> This started happening this morning after booting -rc4+tip, let's
> add *everybody* to CC :-)

What about -rc4 without tip?

> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
> other goodies on the stack.
> 
> ...
> [0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at 
> [8800cac3-8800cec2]
> [0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff 
> 0xfed1 0xfed13fff pnp 00:01
> [0.490079] [ cut here ]
> [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 
> __ioremap_caller+0x372/0x380()
> [0.490306] Info: mapping multiple BARs. Your kernel is fine.
> [0.490371] Modules linked in:
> [0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1
> [0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 
> 11/13/2012
> [0.490742]  00ab 880213d01ad8 816112e3 
> 0006
> [0.491032]  880213d01b28 880213d01b18 8104e9bc 
> 880213d01b08
> [0.491343]  c9c58000 fed1 fed1 
> 6000
> [0.491631] Call Trace:
> [0.493337]  [] dump_stack+0x4f/0x7c
> [0.493420]  [] warn_slowpath_common+0x8c/0xc0
> [0.493503]  [] warn_slowpath_fmt+0x46/0x50
> [0.493588]  [] __ioremap_caller+0x372/0x380
> [0.493674]  [] ? snb_uncore_imc_init_box+0x62/0x90
> [0.493761]  [] ioremap_nocache+0x17/0x20
> [0.493846]  [] snb_uncore_imc_init_box+0x62/0x90
> [0.493933]  [] uncore_pci_probe+0xe5/0x1e0
> [0.494020]  [] local_pci_probe+0x4e/0xa0
> [0.494104]  [] ? get_device+0x19/0x20
> [0.494213]  [] pci_device_probe+0xe1/0x130
> [0.494300]  [] driver_probe_device+0x7b/0x240
> [0.494385]  [] __driver_attach+0xab/0xb0
> [0.494469]  [] ? driver_probe_device+0x240/0x240
> [0.494551]  [] bus_for_each_dev+0x5e/0x90
> [0.494634]  [] driver_attach+0x1e/0x20
> [0.494718]  [] bus_add_driver+0x117/0x230
> [0.494802]  [] driver_register+0x64/0xf0
> [0.494884]  [] __pci_register_driver+0x64/0x70
> [0.494972]  [] ? uncore_types_init+0x19c/0x19c
> [0.495056]  [] intel_uncore_init+0x177/0x41c
> [0.495155]  [] ? uncore_types_init+0x19c/0x19c
> [0.495242]  [] do_one_initcall+0x4e/0x170
> [0.495326]  [] ? parse_args+0x60/0x360
> [0.495411]  [] kernel_init_freeable+0x106/0x19a
> [0.495497]  [] ? do_early_param+0x86/0x86
> [0.495582]  [] ? rest_init+0xd0/0xd0
> [0.495666]  [] kernel_init+0xe/0xf0
> [0.495749]  [] ret_from_fork+0x7c/0xb0
> [0.495831]  [] ? rest_init+0xd0/0xd0
> [0.495921] ---[ end trace 428f365c054d9a01 ]---
> [0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 
> Joules, 3 fixed counters 163840 ms ovfl timer
> [0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes)
> [0.498833] audit: initializing netlink subsys (disabled)
> [0.499024] audit: type=2000 audit(1393259866.477:1): initialized
> ...
> 
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH 0/6] Radeon memory management improvements

[Jerome Glisse]

On Mon, Feb 24, 2014 at 08:39:07PM +0100, Marek Ol??k wrote:
> On Mon, Feb 24, 2014 at 5:40 PM, Christian K?nig
>  wrote:
> > Am 24.02.2014 16:20, schrieb Marek Ol??k:
> >> 1) Add virtual memory support for VRAM. Our GPUs support virtual memory,
> >> which not only solves fragmentation issues, but it also allows each buffer
> >> to be partially in VRAM and partially in GTT, which becomes more important
> >> with large buffers like 100 MB. Moving whole buffers back and forth between
> >> VRAM and GTT is inefficient if you can do it at page granularity. Also, due
> >> to fragmentation, we can never really use all of VRAM, but only about
> >> 90-95%.
> >
> >
> > Yeah, I'm also thinking about this for quite some time now. The basic
> > problem is that while our GPUs support VM they don't support faulting pages
> > in and continuing (at least nobody got that working reliable so far). E.g.
> > when you hit a page fault you can't relocate the page and then continue.
> >
> > Support for partially resident textures on newer hardware currently works by
> > splitting the buffer up into smaller buffers in userspace and then actively
> > checking in the shader if we hit a buffer that's not currently in memory,
> > but that's not really applicable in the general use case (to much shader
> > overhead).
> 
> I was thinking of splitting buffers into smaller chunks and treating
> them like independent TTM buffers, i.e. one radeon_bo would contain an
> array of TTM buffers which would be validated independently of each
> other. The chunks would only be mapped together to make them look like
> one buffer. This would be hidden from userspace and there would only
> be one GEM handle for the whole buffer, so that DRI2 sharing works.

This is a bad idea you will waste a lot of memory for all the ttm objects.
I think you should just decouple that from ttm. TTM placement would be a
hint ie if ttm placement is VRAM than radeon code should try to put as
much as possible of it in VRAM.

radeon would manage chunk of VRAM with lightweight structure. Of course if
such thing is also usefull for nvidia then it would make sense to do that
in ttm.

For the scanout buffer this can be done when the buffer is bound to display
at which point a flag is set thus we would be backward compatible with old
userspace.

Cheers,
J?r?me

> 
> >
> >
> >> 2) Add support for uncached GTT. I think it should improve performance for
> >> dGPUs under memory pressure, but some testing needs to be done to confirm
> >> that. Uncached GTT doesn't seem to work for me on Evergreen, but it's said
> >> to be working on some later chips.
> >
> >
> > Did you try to make the whole GTT uncached or just evicted BOs? Making the
> > whole GTT uncached probably won't work out of the box, but avoiding setting
> > the "SNOOPED" flag on those pages might get us better performance while
> > swapping them into VRAM again.
> 
> I made the whole GTT uncached.
> 
> Marek
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel