[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #138 from Alex Deucher  ---
(In reply to comment #136)
> Alright, I have tested Uber Mode and it doesn't improve performance, at
> least not visibly. That's not the biggest problem. Uber Mode makes the card
> very unstable. I'm getting random geometry corruption and hangs with it. If
> I test a game, it usually doesn't survive 2 minutes of playing. The only
> other difference I see is that the maximum shader clock changed from 8
> to 85000 (KHz?). Anyway, the clocks seem too low. I think this card should
> be able to reach 1 GHz. It's also pretty cold - it only has 50 ?C.

8 is 800Mhz.  The driver stores clocks in 10khz units.

-- 
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/20140731/7f921c8c/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #137 from Alex Deucher  ---
You might try the patches I posted on bug 74250.

-- 
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/20140731/7297c449/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #136 from Marek Ol??k  ---
Alright, I have tested Uber Mode and it doesn't improve performance, at least
not visibly. That's not the biggest problem. Uber Mode makes the card very
unstable. I'm getting random geometry corruption and hangs with it. If I test a
game, it usually doesn't survive 2 minutes of playing. The only other
difference I see is that the maximum shader clock changed from 8 to 85000
(KHz?). Anyway, the clocks seem too low. I think this card should be able to
reach 1 GHz. It's also pretty cold - it only has 50 ?C.

-- 
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/20140731/29b864a0/attachment.html>

[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed

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

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

--- Comment #5 from Alex Deucher  ---
Created attachment 103773
  --> https://bugs.freedesktop.org/attachment.cgi?id=103773=edit
patch 2/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/20140731/bbff7b43/attachment-0001.html>

[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed

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

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

--- Comment #4 from Alex Deucher  ---
Created attachment 103772
  --> https://bugs.freedesktop.org/attachment.cgi?id=103772=edit
patch 1/2

Please try the attached patches.

-- 
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/20140731/079cab32/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #22 from Aaron B  ---
Just had a horrible chance I dropped the ball on ,it killed the server and
outputs couldn't even be reached on my card. I restarted LightDM to only have
it fail and lose the log of the crash, but Steam was failing to start any games
also, even starting steam took a few tries. I'm trying to reproduce. The only
error I got out of I screwed up the log files was "Active IB in BO." or
something of that nature, and it was printed in the tty2 terminal when lightdm
died. That's all I could scroung out of it, but I'm trying to reproduce now,
that error could provide all the information needed if I could have gotten the
logs from it.

-- 
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/20140731/48195d22/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #75 from agapito  ---
Well, still not fixed in 3.16 rc7 :(  

I was using steam (wine) and the bug reappears. Grey garbage in my screen and a
hard lock up. I had to reboot pressing reset button.

-- 
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/20140731/04579844/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #135 from Luzipher  ---
(In reply to comment #134)
> (In reply to comment #133)
> > (In reply to comment #131)
> > > DPM seems to be working here.
> > 
> > I guess you have a unmodified reference design card ?
> 
> I guess so. It doesn't look fancy like cards you can buy. It's just a big
> black brick with an ugly sticker on it saying "HAWAII XT". :)

Well, yes, mine looks quite fancy, with 3 fans and stuff. I bought it for the
better cooling solution (no idea why the reference design must be loud and not
very efficient).
Thing is, it also has a different BIOS, because it doesn't have "Uber"-Mode, as
that mode should be default on my card. AFAIK "Uber"-Mode on reference designs
squeezes out more performance but is way louder. It should be activatable by a
small switch on the card.
In contrast my "Sapphire Radeon R9 290X Tri-X OC" switches beteen normal BIOS
and UEFI mode with that switch (I'm using the normal one as my rig is from the
ancient times before UEFI).

Maybe it'd be interesting if you tried to switch to "Uber"-Mode and see if
anything chages (does dpm still work or does the "Uber"-Mode BIOS also use a
ASIC_ProfilingInfo v3.1 table ?).

-- 
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/20140731/d4f6d12e/attachment.html>

[PATCH 2/2] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffers

[Marek Olšák]

Reviewed-by: Marek Ol??k 

Marek

On Thu, Jul 31, 2014 at 11:43 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> Signed-off-by: Michel D?nzer 
> ---
>  src/gallium/drivers/radeon/r600_buffer_common.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index 154c33d..d747cbc 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -110,14 +110,21 @@ bool r600_init_resource(struct r600_common_screen 
> *rscreen,
> enum radeon_bo_flag flags = 0;
>
> switch (res->b.b.usage) {
> -   case PIPE_USAGE_DYNAMIC:
> -   case PIPE_USAGE_STREAM:
> -   flags = RADEON_FLAG_GTT_WC;
> -   /* fall through */
> case PIPE_USAGE_STAGING:
> /* Transfers are likely to occur more often with these 
> resources. */
> res->domains = RADEON_DOMAIN_GTT;
> break;
> +   case PIPE_USAGE_STREAM:
> +   case PIPE_USAGE_DYNAMIC:
> +   /* Older kernels didn't always flush the HDP cache before
> +* CS execution
> +*/
> +   if (rscreen->info.drm_minor < 40) {
> +   res->domains = RADEON_DOMAIN_GTT;
> +   flags = RADEON_FLAG_GTT_WC;
> +   break;
> +   }
> +   /* fall through */
> case PIPE_USAGE_DEFAULT:
> case PIPE_USAGE_IMMUTABLE:
> default:
> --
> 2.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] r600g/radeonsi: Reduce or even drop special treatment of persistent mappings

[Marek Olšák]

Reviewed-by: Marek Ol??k 

Marek

On Thu, Jul 31, 2014 at 11:43 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> Signed-off-by: Michel D?nzer 
> ---
>  src/gallium/drivers/radeon/r600_buffer_common.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index 4e6b897..154c33d 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -127,13 +127,17 @@ bool r600_init_resource(struct r600_common_screen 
> *rscreen,
> break;
> }
>
> -   /* Use GTT for all persistent mappings, because they are
> -* always cached and coherent. */
> -   if (res->b.b.target == PIPE_BUFFER &&
> +   /* Use GTT for all persistent mappings with older kernels, because 
> they
> +* didn't always flush the HDP cache before CS execution.
> +*
> +* Write-combined CPU mappings are fine, the kernel ensures all CPU
> +* writes finish before the GPU executes a command stream.
> +*/
> +   if (rscreen->info.drm_minor < 40 &&
> +   res->b.b.target == PIPE_BUFFER &&
> res->b.b.flags & (PIPE_RESOURCE_FLAG_MAP_PERSISTENT |
>   PIPE_RESOURCE_FLAG_MAP_COHERENT)) {
> res->domains = RADEON_DOMAIN_GTT;
> -   flags = 0;
> }
>
> /* Tiled textures are unmappable. Always put them in VRAM. */
> --
> 2.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 0/8] Upstreaming the Android build and misc fixes

[Emil Velikov]

Strange, I've explicitly made sure that it's rebased on top of libdrm/master.
I will give it another try in a moment.

FWIW, for Intel at least a mmap/mmap64 would be needed due to the bionic
shortage of their original implementation.

As mentioned earlier, I'm seeking for a few acked/reviewed-by and the rest of
the fixes will follow in due time. Can I consider this acked-by ?

Thanks for having a look
-Emil

On 31/07/14 16:33, Gore, Tim wrote:
> Ok, I still had to manually apply some of patch 3/8 as it was corrupted
> And would not apply, but after this I was able to build within one of 
> My android trees. I have not tested the resulting libraries yet, but the
> Overall build process seems ok.
> 
>   Tim
> 
>> -Original Message-
>> From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>> Sent: Tuesday, July 29, 2014 6:27 PM
>> To: dri-devel at lists.freedesktop.org
>> Cc: Gore, Tim
>> Subject: [PATCHv2 0/8] Upstreaming the Android build and misc fixes
>>
>> Changes since the orignal posting:
>>  - Rebased on top of master.
>>  - Used _H_FILES for header lists (_HEADERS is a no-go with autotools)
>>  - Install the freedreno headers to {include_dir}/freedreno, similar to the
>> automake builds.
>>  - Correctly include $(hw)/Android.mk
>>
>> The series is also available at the fixes+android-v2 branch in
>> https://github.com/evelikov/libdrm.
>>
>> -Emil
> 

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #134 from Marek Ol??k  ---
(In reply to comment #133)
> (In reply to comment #131)
> > DPM seems to be working here.
> 
> I guess you have a unmodified reference design card ?

I guess so. It doesn't look fancy like cards you can buy. It's just a big black
brick with an ugly sticker on it saying "HAWAII XT". :)

-- 
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/20140731/68453eb6/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #21 from Aaron B  ---
I'm getting the glitch a lot more, but trying to remember what sets it off
most:

1. Youtube. Often, but not as often as #2.

2. Clicking on an element that brings up another element onto the page,
basically over it with a higher z-index, like I said facebook does this a LOT.

3. Adding elements to the page at all can also trigger this bug. Like loading
ANY comments, from disqus to yahoo, they all have triggered it.

4. Slideshows where the objects slide against each other, like in PCWorld
slideshows, just had a crash there.

All of these have in common is moving pixels, but also adding pixels to the
screen. Is there special code for that, those dirty rectangles being glitchy or
something? I have, well, only bare minimal knowledge of how these drivers work
from looking at lots of Git commits, but I bet that is a pretty good clue to
people who know what they're looking at with what could be wrong. :)

-- 
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/20140731/0cc5fcc5/attachment.html>

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

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

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

--- Comment #18 from Maciej  ---
This is very odd... I tried using Firefox instead of Chrome for a day and there
was no hang, then I switched to Chrome and five minutes later I had to hard
reboot. Shit happens with stable, beta and unstable channels (no custom tweaks
to Chrome, all default).

-- 
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/20140731/1dd18b9c/attachment.html>

[PATCH 2/2] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffers

[Michel Dänzer]

On 31.07.2014 18:52, Christian K?nig wrote:
> Am 31.07.2014 um 11:43 schrieb Michel D?nzer:
>> From: Michel D?nzer 
>>
>> Signed-off-by: Michel D?nzer 
> 
> At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are
> used by VDPAU to read back to data to a CPU buffer and that's really
> slow from VRAM.

>From src/gallium/docs/source/screen.rst:

* ``PIPE_USAGE_DEFAULT``: Optimized for fast GPU access.
* ``PIPE_USAGE_IMMUTABLE``: Optimized for fast GPU access and the resource is
  not expected to be mapped or changed (even by the GPU) after the first upload.
* ``PIPE_USAGE_DYNAMIC``: Expect frequent write-only CPU access. What is
  uploaded is expected to be used at least several times by the GPU.
* ``PIPE_USAGE_STREAM``: Expect frequent write-only CPU access. What is
  uploaded is expected to be used only once by the GPU.
* ``PIPE_USAGE_STAGING``: Optimized for fast CPU access.

That reads to me like only PIPE_USAGE_STAGING is expected to provide fast
CPU reads.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH 2/2] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffers

[Michel Dänzer]

From: Michel D?nzer 

Signed-off-by: Michel D?nzer 
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 154c33d..d747cbc 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -110,14 +110,21 @@ bool r600_init_resource(struct r600_common_screen 
*rscreen,
enum radeon_bo_flag flags = 0;

switch (res->b.b.usage) {
-   case PIPE_USAGE_DYNAMIC:
-   case PIPE_USAGE_STREAM:
-   flags = RADEON_FLAG_GTT_WC;
-   /* fall through */
case PIPE_USAGE_STAGING:
/* Transfers are likely to occur more often with these 
resources. */
res->domains = RADEON_DOMAIN_GTT;
break;
+   case PIPE_USAGE_STREAM:
+   case PIPE_USAGE_DYNAMIC:
+   /* Older kernels didn't always flush the HDP cache before
+* CS execution
+*/
+   if (rscreen->info.drm_minor < 40) {
+   res->domains = RADEON_DOMAIN_GTT;
+   flags = RADEON_FLAG_GTT_WC;
+   break;
+   }
+   /* fall through */
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_IMMUTABLE:
default:
-- 
2.0.1

[PATCH 1/2] r600g/radeonsi: Reduce or even drop special treatment of persistent mappings

[Michel Dänzer]

From: Michel D?nzer 

Signed-off-by: Michel D?nzer 
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 4e6b897..154c33d 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -127,13 +127,17 @@ bool r600_init_resource(struct r600_common_screen 
*rscreen,
break;
}

-   /* Use GTT for all persistent mappings, because they are
-* always cached and coherent. */
-   if (res->b.b.target == PIPE_BUFFER &&
+   /* Use GTT for all persistent mappings with older kernels, because they
+* didn't always flush the HDP cache before CS execution.
+*
+* Write-combined CPU mappings are fine, the kernel ensures all CPU
+* writes finish before the GPU executes a command stream.
+*/
+   if (rscreen->info.drm_minor < 40 &&
+   res->b.b.target == PIPE_BUFFER &&
res->b.b.flags & (PIPE_RESOURCE_FLAG_MAP_PERSISTENT |
  PIPE_RESOURCE_FLAG_MAP_COHERENT)) {
res->domains = RADEON_DOMAIN_GTT;
-   flags = 0;
}

/* Tiled textures are unmappable. Always put them in VRAM. */
-- 
2.0.1

[PATCH 2/2] drm/radeon: Always flush the HDP cache before submitting a CS to the GPU

[Michel Dänzer]

From: Michel D?nzer 

This ensures the GPU sees all previous CPU writes to VRAM, which makes it
safe:

* For userspace to stream data from CPU to GPU via VRAM instead of GTT
* For IBs to be stored in VRAM instead of GTT
* For ring buffers to be stored in VRAM instead of GTT, if the HPD flush
  is performed via MMIO

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/cik.c |  4 
 drivers/gpu/drm/radeon/r100.c| 20 +++-
 drivers/gpu/drm/radeon/radeon.h  |  1 +
 drivers/gpu/drm/radeon/radeon_asic.c |  6 --
 drivers/gpu/drm/radeon/radeon_asic.h |  3 ++-
 drivers/gpu/drm/radeon/radeon_drv.c  |  4 +++-
 drivers/gpu/drm/radeon/radeon_ring.c | 10 ++
 7 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 67194a5..a5dfe58 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3666,8 +3666,6 @@ void cik_fence_gfx_ring_emit(struct radeon_device *rdev,
radeon_ring_write(ring, (upper_32_bits(addr) & 0x) | DATA_SEL(1) | 
INT_SEL(2));
radeon_ring_write(ring, fence->seq);
radeon_ring_write(ring, 0);
-   /* HDP flush */
-   cik_hdp_flush_cp_ring_emit(rdev, fence->ring);
 }

 /**
@@ -3696,8 +3694,6 @@ void cik_fence_compute_ring_emit(struct radeon_device 
*rdev,
radeon_ring_write(ring, upper_32_bits(addr));
radeon_ring_write(ring, fence->seq);
radeon_ring_write(ring, 0);
-   /* HDP flush */
-   cik_hdp_flush_cp_ring_emit(rdev, fence->ring);
 }

 bool cik_semaphore_ring_emit(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9241b89..e1bed43 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -837,11 +837,7 @@ void r100_fence_ring_emit(struct radeon_device *rdev,
/* Wait until IDLE & CLEAN */
radeon_ring_write(ring, PACKET0(RADEON_WAIT_UNTIL, 0));
radeon_ring_write(ring, RADEON_WAIT_2D_IDLECLEAN | 
RADEON_WAIT_3D_IDLECLEAN);
-   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
-   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
-   RADEON_HDP_READ_BUFFER_INVALIDATE);
-   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
-   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
+   r100_ring_hdp_flush(rdev, ring);
/* Emit fence sequence & fire IRQ */
radeon_ring_write(ring, 
PACKET0(rdev->fence_drv[fence->ring].scratch_reg, 0));
radeon_ring_write(ring, fence->seq);
@@ -1060,6 +1056,20 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
(void)RREG32(RADEON_CP_RB_WPTR);
 }

+/**
+ * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
+ * rdev: radeon device structure
+ * ring: ring buffer struct for emitting packets
+ */
+void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring *ring)
+{
+   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
+   RADEON_HDP_READ_BUFFER_INVALIDATE);
+   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
+}
+
 static void r100_cp_load_microcode(struct radeon_device *rdev)
 {
const __be32 *fw_data;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 4a76e13..bc970b6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1748,6 +1748,7 @@ struct radeon_asic_ring {
/* command emmit functions */
void (*ib_execute)(struct radeon_device *rdev, struct radeon_ib *ib);
void (*emit_fence)(struct radeon_device *rdev, struct radeon_fence 
*fence);
+   void (*hdp_flush)(struct radeon_device *rdev, struct radeon_ring *ring);
bool (*emit_semaphore)(struct radeon_device *rdev, struct radeon_ring 
*cp,
   struct radeon_semaphore *semaphore, bool 
emit_wait);
void (*vm_flush)(struct radeon_device *rdev, int ridx, struct radeon_vm 
*vm);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index ba8caa7..1cb9330 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -185,6 +185,7 @@ static struct radeon_asic_ring r100_gfx_ring = {
.get_rptr = _gfx_get_rptr,
.get_wptr = _gfx_get_wptr,
.set_wptr = _gfx_set_wptr,
+   .hdp_flush = _ring_hdp_flush,
 };

 static struct radeon_asic r100_asic = {
@@ -331,6 +332,7 @@ static struct radeon_asic_ring r300_gfx_ring = {
.get_rptr = _gfx_get_rptr,
.get_wptr = _gfx_get_wptr,
.set_wptr = _gfx_set_wptr,
+   .hdp_flush = _ring_hdp_flush,
 };

 static struct radeon_asic r300_asic = {
@@ -1987,7 +1989,7 @@ static struct radeon_asic ci_asic = {

[PATCH 1/2] drm/radeon: s/ioctl_wait_idle/mmio_hpd_flush/

[Michel Dänzer]

From: Michel D?nzer 

And clean up the function comment a little.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/r600.c| 13 +--
 drivers/gpu/drm/radeon/radeon.h  |  9 ++--
 drivers/gpu/drm/radeon/radeon_asic.c | 44 ++--
 drivers/gpu/drm/radeon/radeon_asic.h |  2 +-
 drivers/gpu/drm/radeon/radeon_gem.c  |  6 ++---
 5 files changed, 34 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index c17ff5d..76e1616 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -4088,16 +4088,15 @@ int r600_debugfs_mc_info_init(struct radeon_device 
*rdev)
 }

 /**
- * r600_ioctl_wait_idle - flush host path cache on wait idle ioctl
+ * r600_mmio_hdp_flush - flush Host Data Path cache via MMIO
  * rdev: radeon device structure
- * bo: buffer object struct which userspace is waiting for idle
  *
- * Some R6XX/R7XX doesn't seems to take into account HDP flush performed
- * through ring buffer, this leads to corruption in rendering, see
- * http://bugzilla.kernel.org/show_bug.cgi?id=15186 to avoid this we
- * directly perform HDP flush by writing register through MMIO.
+ * Some R6XX/R7XX don't seem to take into account HDP flushes performed
+ * through the ring buffer. This leads to corruption in rendering, see
+ * http://bugzilla.kernel.org/show_bug.cgi?id=15186 . To avoid this, we
+ * directly perform the HDP flush by writing the register through MMIO.
  */
-void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo)
+void r600_mmio_hdp_flush(struct radeon_device *rdev)
 {
/* r7xx hw bug.  write to HDP_DEBUG1 followed by fb read
 * rather than write to HDP_REG_COHERENCY_FLUSH_CNTL.
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 6695b62..4a76e13 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1771,13 +1771,8 @@ struct radeon_asic {
int (*suspend)(struct radeon_device *rdev);
void (*vga_set_state)(struct radeon_device *rdev, bool state);
int (*asic_reset)(struct radeon_device *rdev);
-   /* ioctl hw specific callback. Some hw might want to perform special
-* operation on specific ioctl. For instance on wait idle some hw
-* might want to perform and HDP flush through MMIO as it seems that
-* some R6XX/R7XX hw doesn't take HDP flush into account if programmed
-* through ring.
-*/
-   void (*ioctl_wait_idle)(struct radeon_device *rdev, struct radeon_bo 
*bo);
+   /* Flush the HDP cache via MMIO */
+   void (*mmio_hdp_flush)(struct radeon_device *rdev);
/* check if 3D engine is idle */
bool (*gui_idle)(struct radeon_device *rdev);
/* wait for mc_idle */
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 34b9aa9..ba8caa7 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -194,7 +194,7 @@ static struct radeon_asic r100_asic = {
.resume = _resume,
.vga_set_state = _vga_set_state,
.asic_reset = _asic_reset,
-   .ioctl_wait_idle = NULL,
+   .mmio_hdp_flush = NULL,
.gui_idle = _gui_idle,
.mc_wait_for_idle = _mc_wait_for_idle,
.gart = {
@@ -260,7 +260,7 @@ static struct radeon_asic r200_asic = {
.resume = _resume,
.vga_set_state = _vga_set_state,
.asic_reset = _asic_reset,
-   .ioctl_wait_idle = NULL,
+   .mmio_hdp_flush = NULL,
.gui_idle = _gui_idle,
.mc_wait_for_idle = _mc_wait_for_idle,
.gart = {
@@ -340,7 +340,7 @@ static struct radeon_asic r300_asic = {
.resume = _resume,
.vga_set_state = _vga_set_state,
.asic_reset = _asic_reset,
-   .ioctl_wait_idle = NULL,
+   .mmio_hdp_flush = NULL,
.gui_idle = _gui_idle,
.mc_wait_for_idle = _mc_wait_for_idle,
.gart = {
@@ -406,7 +406,7 @@ static struct radeon_asic r300_asic_pcie = {
.resume = _resume,
.vga_set_state = _vga_set_state,
.asic_reset = _asic_reset,
-   .ioctl_wait_idle = NULL,
+   .mmio_hdp_flush = NULL,
.gui_idle = _gui_idle,
.mc_wait_for_idle = _mc_wait_for_idle,
.gart = {
@@ -472,7 +472,7 @@ static struct radeon_asic r420_asic = {
.resume = _resume,
.vga_set_state = _vga_set_state,
.asic_reset = _asic_reset,
-   .ioctl_wait_idle = NULL,
+   .mmio_hdp_flush = NULL,
.gui_idle = _gui_idle,
.mc_wait_for_idle = _mc_wait_for_idle,
.gart = {
@@ -538,7 +538,7 @@ static struct radeon_asic rs400_asic = {
.resume = _resume,
.vga_set_state = _vga_set_state,
.asic_reset = _asic_reset,
-   .ioctl_wait_idle = NULL,
+   .mmio_hdp_flush = NULL,
.gui_idle = _gui_idle,
.mc_wait_for_idle = _mc_wait_for_idle,
 

[PATCH 0/2] radeon: Allow streaming data from CPU to GPU via VRAM

[Michel Dänzer]

On my Kaveri system, streaming data from CPU to GPU via VRAM is faster
than via GTT both with the integrated GPU and with discrete GPUs.

The following kernel patches make this safe by always flushing the HDP
cache before submitting a command stream to the GPU, and bump the radeon
DRM minor version.

The following Mesa patches check for the bumped radeon DRM minor version,
and if it's satisfied, they prefer CPU -> GPU streaming via VRAM and
relax the restrictions for persistent mappings.

[PATCH 1/2] drm/radeon: s/ioctl_wait_idle/mmio_hpd_flush/
[PATCH 2/2] drm/radeon: Always flush the HDP cache before submitting
[PATCH 1/2] r600g/radeonsi: Reduce or even drop special treatment of
[PATCH 2/2] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming

[PATCH 2/2] drm/radeon/dpm: handle voltage info fetching on hawaii

[Alex Deucher]

Some hawaii cards use a different method to fetch the
voltage info from the vbios.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/ci_dpm.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 584090a..022561e 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -940,7 +940,18 @@ static void ci_get_leakage_voltages(struct radeon_device 
*rdev)
pi->vddc_leakage.count = 0;
pi->vddci_leakage.count = 0;

-   if (radeon_atom_get_leakage_id_from_vbios(rdev, _id) == 0) {
+   if (rdev->pm.dpm.platform_caps & ATOM_PP_PLATFORM_CAP_EVV) {
+   for (i = 0; i < CISLANDS_MAX_LEAKAGE_COUNT; i++) {
+   virtual_voltage_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
+   if (radeon_atom_get_voltage_evv(rdev, 
virtual_voltage_id, ) != 0)
+   continue;
+   if (vddc != 0 && vddc != virtual_voltage_id) {
+   
pi->vddc_leakage.actual_voltage[pi->vddc_leakage.count] = vddc;
+   
pi->vddc_leakage.leakage_id[pi->vddc_leakage.count] = virtual_voltage_id;
+   pi->vddc_leakage.count++;
+   }
+   }
+   } else if (radeon_atom_get_leakage_id_from_vbios(rdev, _id) == 
0) {
for (i = 0; i < CISLANDS_MAX_LEAKAGE_COUNT; i++) {
virtual_voltage_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
if 
(radeon_atom_get_leakage_vddc_based_on_leakage_params(rdev, , ,
-- 
1.8.3.1

[PATCH 1/2] drm/radeon/atom: add new voltage fetch function for hawaii

[Alex Deucher]

Some hawaii boards use a different method for fetching the
voltage information from the vbios.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h  |  3 +++
 drivers/gpu/drm/radeon/radeon_atombios.c | 35 
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 85d9bca3..142cad6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -305,6 +305,9 @@ int 
radeon_atom_get_leakage_vddc_based_on_leakage_params(struct radeon_device *r
 u16 *vddc, u16 *vddci,
 u16 virtual_voltage_id,
 u16 vbios_voltage_id);
+int radeon_atom_get_voltage_evv(struct radeon_device *rdev,
+   u16 virtual_voltage_id,
+   u16 *voltage);
 int radeon_atom_round_to_true_voltage(struct radeon_device *rdev,
  u8 voltage_type,
  u16 nominal_voltage,
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 2bbf016..92b2d8d 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -3236,6 +3236,41 @@ int 
radeon_atom_get_leakage_vddc_based_on_leakage_params(struct radeon_device *r
return 0;
 }

+union get_voltage_info {
+   struct  _GET_VOLTAGE_INFO_INPUT_PARAMETER_V1_2 in;
+   struct  _GET_EVV_VOLTAGE_INFO_OUTPUT_PARAMETER_V1_2 evv_out;
+};
+
+int radeon_atom_get_voltage_evv(struct radeon_device *rdev,
+   u16 virtual_voltage_id,
+   u16 *voltage)
+{
+   int index = GetIndexIntoMasterTable(COMMAND, GetVoltageInfo);
+   u32 entry_id;
+   u32 count = rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.count;
+   union get_voltage_info args;
+
+   for (entry_id = 0; entry_id < count; entry_id++) {
+   if 
(rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.entries[entry_id].v ==
+   virtual_voltage_id)
+   break;
+   }
+
+   if (entry_id >= count)
+   return -EINVAL;
+
+   args.in.ucVoltageType = VOLTAGE_TYPE_VDDC;
+   args.in.ucVoltageMode = ATOM_GET_VOLTAGE_EVV_VOLTAGE;
+   args.in.ulSCLKFreq =
+   
cpu_to_le32(rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.entries[entry_id].clk);
+
+   atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*));
+
+   *voltage = le16_to_cpu(args.evv_out.usVoltageLevel);
+
+   return 0;
+}
+
 int radeon_atom_get_voltage_gpio_settings(struct radeon_device *rdev,
  u16 voltage_level, u8 voltage_type,
  u32 *gpio_value, u32 *gpio_mask)
-- 
1.8.3.1

[Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function

[Michel Dänzer]

On 31.07.2014 16:54, Daniel Vetter wrote:
> On Thu, Jul 31, 2014 at 3:14 AM, Michel D?nzer  wrote:
>> I think it would be better to refactor drm_wait_vblank() than to
>> reinvent it.
> 
> That's the ioctl implementation which spends most of its time decoding
> ioctl structures. If we take that out then there's about half a line
> which would be shared (since a lot of the stuff in there is ums gunk
> that we don't want to carry over to a kms-only internal interface). So
> imo that doesn't make sense.

I'm referring to the core logic of waiting for a number of vblank
periods or until the vblank period with a given sequence number, dealing
with wraparound etc. The issues you guys were discussing for a new
function were ironed out there long ago.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH 00/17] Convert TTM to the new fence interface. v2

[Maarten Lankhorst]

op 31-07-14 17:30, Maarten Lankhorst schreef:
> This series applies on top of the driver-core-next branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
>
> Before converting ttm to the new fence interface I had to fix some
> drivers to require a reservation before poking with fence_obj.
> After flipping the switch RCU becomes available instead, and
> the extra reservations can be dropped again. 
>
> I've done at least basic testing on all the drivers I've converted
> at some point, but more testing is definitely welcomed!
>
> Changes since v1:
> - Almost all radeon changes, radeon reworked their page flip code which
>   made things easier for me.
> - Added a delayed work for radeon that checks gpu lockups.
> - Reworked the radeon fence implementation to remove deadlocks,
>   and end up slightly cleaner.
>
Oops, managed to screw up sending patches. There are 19 patches in this series, 
starting with

[PATCH 01/19] fence: add debugging lines to fence_is_signaled for the callback

Sorry for the noise.

~Maarten

[PATCH 19/19] drm/ttm: use rcu in core ttm

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo.c |   76 +++---
 1 file changed, 13 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9d36cffad3b7..d119ae4419d4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -466,66 +466,6 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
  ((HZ / 100) < 1) ? 1 : HZ / 100);
 }

-static int ttm_bo_unreserve_and_wait(struct ttm_buffer_object *bo,
-bool interruptible)
-{
-   struct ttm_bo_global *glob = bo->glob;
-   struct reservation_object_list *fobj;
-   struct fence *excl = NULL;
-   struct fence **shared = NULL;
-   u32 shared_count = 0, i;
-   int ret = 0;
-
-   fobj = reservation_object_get_list(bo->resv);
-   if (fobj && fobj->shared_count) {
-   shared = kmalloc(sizeof(*shared) * fobj->shared_count,
-GFP_KERNEL);
-
-   if (!shared) {
-   ret = -ENOMEM;
-   __ttm_bo_unreserve(bo);
-   spin_unlock(>lru_lock);
-   return ret;
-   }
-
-   for (i = 0; i < fobj->shared_count; ++i) {
-   if (!fence_is_signaled(fobj->shared[i])) {
-   fence_get(fobj->shared[i]);
-   shared[shared_count++] = fobj->shared[i];
-   }
-   }
-   if (!shared_count) {
-   kfree(shared);
-   shared = NULL;
-   }
-   }
-
-   excl = reservation_object_get_excl(bo->resv);
-   if (excl && !fence_is_signaled(excl))
-   fence_get(excl);
-   else
-   excl = NULL;
-
-   __ttm_bo_unreserve(bo);
-   spin_unlock(>lru_lock);
-
-   if (excl) {
-   ret = fence_wait(excl, interruptible);
-   fence_put(excl);
-   }
-
-   if (shared_count > 0) {
-   for (i = 0; i < shared_count; ++i) {
-   if (!ret)
-   ret = fence_wait(shared[i], interruptible);
-   fence_put(shared[i]);
-   }
-   kfree(shared);
-   }
-
-   return ret;
-}
-
 /**
  * function ttm_bo_cleanup_refs_and_unlock
  * If bo idle, remove from delayed- and lru lists, and unref.
@@ -549,9 +489,19 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
ret = ttm_bo_wait(bo, false, false, true);

if (ret && !no_wait_gpu) {
-   ret = ttm_bo_unreserve_and_wait(bo, interruptible);
-   if (ret)
-   return ret;
+   long lret;
+   ww_mutex_unlock(>resv->lock);
+   spin_unlock(>lru_lock);
+
+   lret = reservation_object_wait_timeout_rcu(bo->resv,
+  true,
+  interruptible,
+  30 * HZ);
+
+   if (lret < 0)
+   return lret;
+   else if (lret == 0)
+   return -EBUSY;

spin_lock(>lru_lock);
ret = __ttm_bo_reserve(bo, false, true, false, NULL);

[PATCH 18/19] drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index f0a689ba9685..a43930162eb6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -567,13 +567,16 @@ static int vmw_user_dmabuf_synccpu_grab(struct 
vmw_user_dma_buffer *user_bo,
int ret;

if (flags & drm_vmw_synccpu_allow_cs) {
-   ret = ttm_bo_reserve(bo, true, !!(flags & 
drm_vmw_synccpu_dontblock), false, 0);
-   if (!ret) {
-   ret = ttm_bo_wait(bo, false, true,
- !!(flags & 
drm_vmw_synccpu_dontblock));
-   ttm_bo_unreserve(bo);
-   }
-   return ret;
+   long lret;
+   if (flags & drm_vmw_synccpu_dontblock)
+   return reservation_object_test_signaled_rcu(bo->resv, 
true) ? 0 : -EBUSY;
+
+   lret = reservation_object_wait_timeout_rcu(bo->resv, true, 
true, MAX_SCHEDULE_TIMEOUT);
+   if (!lret)
+   return -EBUSY;
+   else if (lret < 0)
+   return lret;
+   return 0;
}

ret = ttm_bo_synccpu_write_grab

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon_gem.c |   19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index d09650c1d720..7ba883843668 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -107,9 +107,12 @@ static int radeon_gem_set_domain(struct drm_gem_object 
*gobj,
}
if (domain == RADEON_GEM_DOMAIN_CPU) {
/* Asking for cpu access wait for object idle */
-   r = radeon_bo_wait(robj, NULL, false);
-   if (r) {
-   printk(KERN_ERR "Failed to wait for object !\n");
+   r = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, 
true, 30 * HZ);
+   if (!r)
+   r = -EBUSY;
+
+   if (r < 0 && r != -EINTR) {
+   printk(KERN_ERR "Failed to wait for object: %i\n", r);
return r;
}
}
@@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, 
void *data,
struct drm_radeon_gem_wait_idle *args = data;
struct drm_gem_object *gobj;
struct radeon_bo *robj;
-   int r;
+   int r = 0;
+   long ret;

gobj = drm_gem_object_lookup(dev, filp, args->handle);
if (gobj == NULL) {
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
-   r = radeon_bo_wait(robj, NULL, false);
+   ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 
30 * HZ);
+   if (ret == 0)
+   r = -EBUSY;
+   else if (ret < 0)
+   r = ret;
+
/* callback hw specific functions if any */
if (rdev->asic->ioctl_wait_idle)
robj->rdev->asic->ioctl_wait_idle(rdev, robj);

[PATCH 16/19] drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep

[Maarten Lankhorst]

With the conversion to the reservation api this should be safe.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c |   28 
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 0a1fee7eb211..b24a6fe6c601 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -863,33 +863,29 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void 
*data,
struct drm_gem_object *gem;
struct nouveau_bo *nvbo;
bool no_wait = !!(req->flags & NOUVEAU_GEM_CPU_PREP_NOWAIT);
+   bool write = !!(req->flags & NOUVEAU_GEM_CPU_PREP_WRITE);
int ret;
-   struct nouveau_fence *fence = NULL;

gem = drm_gem_object_lookup(dev, file_priv, req->handle);
if (!gem)
return -ENOENT;
nvbo = nouveau_gem_object(gem);

-   ret = ttm_bo_reserve(>bo, true, false, false, 0);
-   if (!ret) {
-   ret = ttm_bo_wait(>bo, true, true, true);
-   if (!no_wait && ret) {
-   struct fence *excl;
-
-   excl = reservation_object_get_excl(nvbo->bo.resv);
-   fence = nouveau_fence_ref((struct nouveau_fence *)excl);
-   }
+   if (no_wait)
+   ret = reservation_object_test_signaled_rcu(nvbo->bo.resv, 
write) ? 0 : -EBUSY;
+   else {
+   long lret;

-   ttm_bo_unreserve(>bo);
+   lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, 
write, true, 30 * HZ);
+   if (!lret)
+   ret = -EBUSY;
+   else if (lret > 0)
+   ret = 0;
+   else
+   ret = lret;
}
drm_gem_object_unreference_unlocked(gem);

-   if (fence) {
-   ret = nouveau_fence_wait(fence, true, no_wait);
-   nouveau_fence_unref();
-   }
-
return ret;
 }

[PATCH 15/19] drm/ttm: flip the switch, and convert to dma_fence

[Maarten Lankhorst]

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |   48 +---
 drivers/gpu/drm/nouveau/nouveau_fence.c  |   24 +---
 drivers/gpu/drm/nouveau/nouveau_fence.h  |2 
 drivers/gpu/drm/nouveau/nouveau_gem.c|   16 ++-
 drivers/gpu/drm/qxl/qxl_debugfs.c|6 +
 drivers/gpu/drm/qxl/qxl_drv.h|2 
 drivers/gpu/drm/qxl/qxl_kms.c|1 
 drivers/gpu/drm/qxl/qxl_object.h |4 -
 drivers/gpu/drm/qxl/qxl_release.c|3 -
 drivers/gpu/drm/qxl/qxl_ttm.c|  104 --
 drivers/gpu/drm/radeon/radeon_cs.c   |   10 +-
 drivers/gpu/drm/radeon/radeon_display.c  |3 -
 drivers/gpu/drm/radeon/radeon_object.c   |4 -
 drivers/gpu/drm/radeon/radeon_ttm.c  |   34 --
 drivers/gpu/drm/radeon/radeon_uvd.c  |8 +
 drivers/gpu/drm/radeon/radeon_vm.c   |   14 ++
 drivers/gpu/drm/ttm/ttm_bo.c |  171 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c|   23 +---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c   |   10 --
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c   |   40 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   14 +-
 include/drm/ttm/ttm_bo_api.h |2 
 include/drm/ttm/ttm_bo_driver.h  |   26 -
 include/drm/ttm/ttm_execbuf_util.h   |   10 +-
 24 files changed, 193 insertions(+), 386 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 6e71d3dc2d87..3d8a8e18caea 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -92,13 +92,13 @@ nv10_bo_get_tile_region(struct drm_device *dev, int i)

 static void
 nv10_bo_put_tile_region(struct drm_device *dev, struct nouveau_drm_tile *tile,
-   struct nouveau_fence *fence)
+   struct fence *fence)
 {
struct nouveau_drm *drm = nouveau_drm(dev);

if (tile) {
spin_lock(>tile.lock);
-   tile->fence = nouveau_fence_ref(fence);
+   tile->fence = nouveau_fence_ref((struct nouveau_fence *)fence);
tile->used = false;
spin_unlock(>tile.lock);
}
@@ -965,7 +965,8 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict, bool intr,
if (ret == 0) {
ret = nouveau_fence_new(chan, false, );
if (ret == 0) {
-   ret = ttm_bo_move_accel_cleanup(bo, fence,
+   ret = ttm_bo_move_accel_cleanup(bo,
+   >base,
evict,
no_wait_gpu,
new_mem);
@@ -1151,8 +1152,9 @@ nouveau_bo_vm_cleanup(struct ttm_buffer_object *bo,
 {
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct drm_device *dev = drm->dev;
+   struct fence *fence = reservation_object_get_excl(bo->resv);

-   nv10_bo_put_tile_region(dev, *old_tile, bo->sync_obj);
+   nv10_bo_put_tile_region(dev, *old_tile, fence);
*old_tile = new_tile;
 }

@@ -1423,47 +1425,14 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
ttm_pool_unpopulate(ttm);
 }

-static void
-nouveau_bo_fence_unref(void **sync_obj)
-{
-   nouveau_fence_unref((struct nouveau_fence **)sync_obj);
-}
-
 void
 nouveau_bo_fence(struct nouveau_bo *nvbo, struct nouveau_fence *fence)
 {
struct reservation_object *resv = nvbo->bo.resv;

-   nouveau_bo_fence_unref(>bo.sync_obj);
-   nvbo->bo.sync_obj = nouveau_fence_ref(fence);
-
reservation_object_add_excl_fence(resv, >base);
 }

-static void *
-nouveau_bo_fence_ref(void *sync_obj)
-{
-   return nouveau_fence_ref(sync_obj);
-}
-
-static bool
-nouveau_bo_fence_signalled(void *sync_obj)
-{
-   return nouveau_fence_done(sync_obj);
-}
-
-static int
-nouveau_bo_fence_wait(void *sync_obj, bool lazy, bool intr)
-{
-   return nouveau_fence_wait(sync_obj, lazy, intr);
-}
-
-static int
-nouveau_bo_fence_flush(void *sync_obj)
-{
-   return 0;
-}
-
 struct ttm_bo_driver nouveau_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
@@ -1474,11 +1443,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
.move_notify = nouveau_bo_move_ntfy,
.move = nouveau_bo_move,
.verify_access = nouveau_bo_verify_access,
-   .sync_obj_signaled = nouveau_bo_fence_signalled,
-   .sync_obj_wait = nouveau_bo_fence_wait,
-   .sync_obj_flush = nouveau_bo_fence_flush,
-   .sync_obj_unref = nouveau_bo_fence_unref,
-   .sync_obj_ref = nouveau_bo_fence_ref,
.fault_reserve_notify = _ttm_fault_reserve_notify,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_free = _ttm_io_mem_free,
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 

[PATCH 14/19] drm/vmwgfx: rework to new fence interface

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |2 
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c|  299 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.h|   29 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 -
 4 files changed, 200 insertions(+), 139 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 214fcfd13cb2..0ceaddc8e4f7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -2389,7 +2389,7 @@ vmw_execbuf_copy_fence_user(struct vmw_private *dev_priv,
BUG_ON(fence == NULL);

fence_rep.handle = fence_handle;
-   fence_rep.seqno = fence->seqno;
+   fence_rep.seqno = fence->base.seqno;
vmw_update_seqno(dev_priv, _priv->fifo);
fence_rep.passed_seqno = dev_priv->last_read_seqno;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 05b9eea8e875..77f416b7552c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -46,6 +46,7 @@ struct vmw_fence_manager {
bool goal_irq_on; /* Protected by @goal_irq_mutex */
bool seqno_valid; /* Protected by @lock, and may not be set to true
 without the @goal_irq_mutex held. */
+   unsigned ctx;
 };

 struct vmw_user_fence {
@@ -80,6 +81,12 @@ struct vmw_event_fence_action {
uint32_t *tv_usec;
 };

+static struct vmw_fence_manager *
+fman_from_fence(struct vmw_fence_obj *fence)
+{
+   return container_of(fence->base.lock, struct vmw_fence_manager, lock);
+}
+
 /**
  * Note on fencing subsystem usage of irqs:
  * Typically the vmw_fences_update function is called
@@ -102,25 +109,130 @@ struct vmw_event_fence_action {
  * objects with actions attached to them.
  */

-static void vmw_fence_obj_destroy_locked(struct kref *kref)
+static void vmw_fence_obj_destroy(struct fence *f)
 {
struct vmw_fence_obj *fence =
-   container_of(kref, struct vmw_fence_obj, kref);
+   container_of(f, struct vmw_fence_obj, base);

-   struct vmw_fence_manager *fman = fence->fman;
-   unsigned int num_fences;
+   struct vmw_fence_manager *fman = fman_from_fence(fence);
+   unsigned long irq_flags;

+   spin_lock_irqsave(>lock, irq_flags);
list_del_init(>head);
-   num_fences = --fman->num_fence_objects;
-   spin_unlock_irq(>lock);
-   if (fence->destroy)
-   fence->destroy(fence);
-   else
-   kfree(fence);
+   --fman->num_fence_objects;
+   spin_unlock_irqrestore(>lock, irq_flags);
+   fence->destroy(fence);
+}

-   spin_lock_irq(>lock);
+static const char *vmw_fence_get_driver_name(struct fence *f)
+{
+   return "vmwgfx";
+}
+
+static const char *vmw_fence_get_timeline_name(struct fence *f)
+{
+   return "svga";
+}
+
+static bool vmw_fence_enable_signaling(struct fence *f)
+{
+   struct vmw_fence_obj *fence =
+   container_of(f, struct vmw_fence_obj, base);
+
+   struct vmw_fence_manager *fman = fman_from_fence(fence);
+
+   __le32 __iomem *fifo_mem = fman->dev_priv->mmio_virt;
+   u32 seqno = ioread32(fifo_mem + SVGA_FIFO_FENCE);
+   if (seqno - fence->base.seqno < VMW_FENCE_WRAP)
+   return false;
+
+   vmw_fifo_ping_host(fman->dev_priv, SVGA_SYNC_GENERIC);
+
+   return true;
+}
+
+struct vmwgfx_wait_cb {
+   struct fence_cb base;
+   struct task_struct *task;
+};
+
+static void
+vmwgfx_wait_cb(struct fence *fence, struct fence_cb *cb)
+{
+   struct vmwgfx_wait_cb *wait =
+   container_of(cb, struct vmwgfx_wait_cb, base);
+
+   wake_up_process(wait->task);
 }

+static void __vmw_fences_update(struct vmw_fence_manager *fman);
+
+static long vmw_fence_wait(struct fence *f, bool intr, signed long timeout)
+{
+   struct vmw_fence_obj *fence =
+   container_of(f, struct vmw_fence_obj, base);
+
+   struct vmw_fence_manager *fman = fman_from_fence(fence);
+   struct vmw_private *dev_priv = fman->dev_priv;
+   struct vmwgfx_wait_cb cb;
+   long ret = timeout;
+   unsigned long irq_flags;
+
+   if (likely(vmw_fence_obj_signaled(fence)))
+   return timeout;
+
+   vmw_fifo_ping_host(dev_priv, SVGA_SYNC_GENERIC);
+   vmw_seqno_waiter_add(dev_priv);
+
+   spin_lock_irqsave(f->lock, irq_flags);
+
+   if (intr && signal_pending(current)) {
+   ret = -ERESTARTSYS;
+   goto out;
+   }
+
+   cb.base.func = vmwgfx_wait_cb;
+   cb.task = current;
+   list_add(, >cb_list);
+
+   while (ret > 0) {
+   __vmw_fences_update(fman);
+   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
+   break;
+
+   if (intr)
+   

[PATCH 13/19] drm/vmwgfx: get rid of different types of fence_flags entirely

[Maarten Lankhorst]

Only one type was ever used. This is needed to simplify the fence
support in the next commit.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c  |5 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |   14 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c   |   50 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.h   |8 +
 5 files changed, 26 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 4a36bb1dc525..f15718cc631d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -792,15 +792,12 @@ static int vmw_sync_obj_flush(void *sync_obj)

 static bool vmw_sync_obj_signaled(void *sync_obj)
 {
-   return  vmw_fence_obj_signaled((struct vmw_fence_obj *) sync_obj,
-  DRM_VMW_FENCE_FLAG_EXEC);
-
+   return vmw_fence_obj_signaled((struct vmw_fence_obj *) sync_obj);
 }

 static int vmw_sync_obj_wait(void *sync_obj, bool lazy, bool interruptible)
 {
return vmw_fence_obj_wait((struct vmw_fence_obj *) sync_obj,
- DRM_VMW_FENCE_FLAG_EXEC,
  lazy, interruptible,
  VMW_FENCE_WAIT_TIMEOUT);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index c1811750cc8d..0b1e4b0c919e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -342,7 +342,6 @@ struct vmw_sw_context{
uint32_t *cmd_bounce;
uint32_t cmd_bounce_size;
struct list_head resource_list;
-   uint32_t fence_flags;
struct ttm_buffer_object *cur_query_bo;
struct list_head res_relocations;
uint32_t *buf_start;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index b19b2b980cb4..214fcfd13cb2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -350,8 +350,6 @@ static int vmw_bo_to_validate_list(struct vmw_sw_context 
*sw_context,
vval_buf->validate_as_mob = validate_as_mob;
}

-   sw_context->fence_flags |= DRM_VMW_FENCE_FLAG_EXEC;
-
if (p_val_node)
*p_val_node = val_node;

@@ -2337,13 +2335,9 @@ int vmw_execbuf_fence_commands(struct drm_file 
*file_priv,

if (p_handle != NULL)
ret = vmw_user_fence_create(file_priv, dev_priv->fman,
-   sequence,
-   DRM_VMW_FENCE_FLAG_EXEC,
-   p_fence, p_handle);
+   sequence, p_fence, p_handle);
else
-   ret = vmw_fence_create(dev_priv->fman, sequence,
-  DRM_VMW_FENCE_FLAG_EXEC,
-  p_fence);
+   ret = vmw_fence_create(dev_priv->fman, sequence, p_fence);

if (unlikely(ret != 0 && !synced)) {
(void) vmw_fallback_wait(dev_priv, false, false,
@@ -2416,8 +2410,7 @@ vmw_execbuf_copy_fence_user(struct vmw_private *dev_priv,
ttm_ref_object_base_unref(vmw_fp->tfile,
  fence_handle, TTM_REF_USAGE);
DRM_ERROR("Fence copy error. Syncing.\n");
-   (void) vmw_fence_obj_wait(fence, fence->signal_mask,
- false, false,
+   (void) vmw_fence_obj_wait(fence, false, false,
  VMW_FENCE_WAIT_TIMEOUT);
}
 }
@@ -2469,7 +2462,6 @@ int vmw_execbuf_process(struct drm_file *file_priv,
sw_context->fp = vmw_fpriv(file_priv);
sw_context->cur_reloc = 0;
sw_context->cur_val_buf = 0;
-   sw_context->fence_flags = 0;
INIT_LIST_HEAD(_context->resource_list);
sw_context->cur_query_bo = dev_priv->pinned_bo;
sw_context->last_query_ctx = NULL;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 436b013b4231..05b9eea8e875 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -207,9 +207,7 @@ void vmw_fence_manager_takedown(struct vmw_fence_manager 
*fman)
 }

 static int vmw_fence_obj_init(struct vmw_fence_manager *fman,
- struct vmw_fence_obj *fence,
- u32 seqno,
- uint32_t mask,
+ struct vmw_fence_obj *fence, u32 seqno,
  void (*destroy) (struct vmw_fence_obj *fence))
 {
unsigned long irq_flags;
@@ -220,7 +218,6 @@ static int vmw_fence_obj_init(struct vmw_fence_manager 
*fman,
INIT_LIST_HEAD(>seq_passed_actions);
fence->fman = fman;

[PATCH 12/19] drm/qxl: rework to new fence interface

[Maarten Lankhorst]

Final driver! \o/

This is not a proper dma_fence because the hardware may never signal
anything, so don't use dma-buf with qxl, ever.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/qxl/Makefile  |2 
 drivers/gpu/drm/qxl/qxl_cmd.c |5 -
 drivers/gpu/drm/qxl/qxl_debugfs.c |   12 ++-
 drivers/gpu/drm/qxl/qxl_drv.h |   22 ++---
 drivers/gpu/drm/qxl/qxl_fence.c   |   87 ---
 drivers/gpu/drm/qxl/qxl_kms.c |2 
 drivers/gpu/drm/qxl/qxl_object.c  |2 
 drivers/gpu/drm/qxl/qxl_release.c |  166 -
 drivers/gpu/drm/qxl/qxl_ttm.c |   97 --
 9 files changed, 220 insertions(+), 175 deletions(-)
 delete mode 100644 drivers/gpu/drm/qxl/qxl_fence.c

diff --git a/drivers/gpu/drm/qxl/Makefile b/drivers/gpu/drm/qxl/Makefile
index ea046ba691d2..ac0d74852e11 100644
--- a/drivers/gpu/drm/qxl/Makefile
+++ b/drivers/gpu/drm/qxl/Makefile
@@ -4,6 +4,6 @@

 ccflags-y := -Iinclude/drm

-qxl-y := qxl_drv.o qxl_kms.o qxl_display.o qxl_ttm.o qxl_fb.o qxl_object.o 
qxl_gem.o qxl_cmd.o qxl_image.o qxl_draw.o qxl_debugfs.o qxl_irq.o qxl_dumb.o 
qxl_ioctl.o qxl_fence.o qxl_release.o
+qxl-y := qxl_drv.o qxl_kms.o qxl_display.o qxl_ttm.o qxl_fb.o qxl_object.o 
qxl_gem.o qxl_cmd.o qxl_image.o qxl_draw.o qxl_debugfs.o qxl_irq.o qxl_dumb.o 
qxl_ioctl.o qxl_release.o

 obj-$(CONFIG_DRM_QXL)+= qxl.o
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 45fad7b45486..97823644d347 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -620,11 +620,6 @@ static int qxl_reap_surf(struct qxl_device *qdev, struct 
qxl_bo *surf, bool stal
if (ret == -EBUSY)
return -EBUSY;

-   if (surf->fence.num_active_releases > 0 && stall == false) {
-   qxl_bo_unreserve(surf);
-   return -EBUSY;
-   }
-
if (stall)
mutex_unlock(>surf_evict_mutex);

diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c 
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index c3c2bbdc6674..0d144e0646d6 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -57,11 +57,21 @@ qxl_debugfs_buffers_info(struct seq_file *m, void *data)
struct qxl_device *qdev = node->minor->dev->dev_private;
struct qxl_bo *bo;

+   spin_lock(>release_lock);
list_for_each_entry(bo, >gem.objects, list) {
+   struct reservation_object_list *fobj;
+   int rel;
+
+   rcu_read_lock();
+   fobj = rcu_dereference(bo->tbo.resv->fence);
+   rel = fobj ? fobj->shared_count : 0;
+   rcu_read_unlock();
+
seq_printf(m, "size %ld, pc %d, sync obj %p, num releases %d\n",
   (unsigned long)bo->gem_base.size, bo->pin_count,
-  bo->tbo.sync_obj, bo->fence.num_active_releases);
+  bo->tbo.sync_obj, rel);
}
+   spin_unlock(>release_lock);
return 0;
 }

diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 36ed40ba773f..d547cbdebeb4 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -31,6 +31,7 @@
  * Definitions taken from spice-protocol, plus kernel driver specific bits.
  */

+#include 
 #include 
 #include 
 #include 
@@ -95,13 +96,6 @@ enum {
QXL_INTERRUPT_IO_CMD |\
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG)

-struct qxl_fence {
-   struct qxl_device *qdev;
-   uint32_t num_active_releases;
-   uint32_t *release_ids;
-   struct radix_tree_root tree;
-};
-
 struct qxl_bo {
/* Protected by gem.mutex */
struct list_headlist;
@@ -113,13 +107,13 @@ struct qxl_bo {
unsignedpin_count;
void*kptr;
int type;
+
/* Constant after initialization */
struct drm_gem_object   gem_base;
bool is_primary; /* is this now a primary surface */
bool hw_surf_alloc;
struct qxl_surface surf;
uint32_t surface_id;
-   struct qxl_fence fence; /* per bo fence  - list of releases */
struct qxl_release *surf_create;
 };
 #define gem_to_qxl_bo(gobj) container_of((gobj), struct qxl_bo, gem_base)
@@ -191,6 +185,8 @@ enum {
  * spice-protocol/qxl_dev.h */
 #define QXL_MAX_RES 96
 struct qxl_release {
+   struct fence base;
+
int id;
int type;
uint32_t release_offset;
@@ -284,7 +280,11 @@ struct qxl_device {
uint8_t slot_gen_bits;
uint64_tva_slot_mask;

+   /* XXX: when rcu becomes available, release_lock can be killed */
+   spinlock_t  release_lock;
+   spinlock_t  fence_lock;
struct idr  release_idr;
+   uint32_trelease_seqno;
spinlock_t release_idr_lock;
struct mutexasync_io_mutex;

[PATCH 11/19] drm/radeon: use common fence implementation for fences, v2

[Maarten Lankhorst]

Changes since v1:
- Kill the sw interrupt dance, add and use
  radeon_irq_kms_sw_irq_get_delayed instead.
- Change custom wait function, lockdep complained about it.
  Holding exclusive_lock in the wait function might cause deadlocks.
  Instead do all the processing in .enable_signaling, and wait
  on the global fence_queue to pick up gpu resets.
- Process all fences in radeon_gpu_reset after reset to close a race
  with the trylock in enable_signaling.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon.h |   18 +-
 drivers/gpu/drm/radeon/radeon_device.c  |   22 ++-
 drivers/gpu/drm/radeon/radeon_fence.c   |  263 +++
 drivers/gpu/drm/radeon/radeon_irq_kms.c |   43 +
 4 files changed, 293 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b01d88fc10cb..599bb28e4104 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -116,9 +117,6 @@ extern int radeon_deep_color;
 #define RADEONFB_CONN_LIMIT4
 #define RADEON_BIOS_NUM_SCRATCH8

-/* fence seq are set to this number when signaled */
-#define RADEON_FENCE_SIGNALED_SEQ  0LL
-
 /* internal ring indices */
 /* r1xx+ has gfx CP ring */
 #define RADEON_RING_TYPE_GFX_INDEX 0
@@ -352,12 +350,15 @@ struct radeon_fence_driver {
 };

 struct radeon_fence {
+   struct fence base;
+
struct radeon_device*rdev;
-   struct kref kref;
/* protected by radeon_fence.lock */
uint64_tseq;
/* RB, DMA, etc. */
unsignedring;
+
+   wait_queue_t fence_wake;
 };

 int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
@@ -769,6 +770,7 @@ struct radeon_irq {
 int radeon_irq_kms_init(struct radeon_device *rdev);
 void radeon_irq_kms_fini(struct radeon_device *rdev);
 void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev, int ring);
+void radeon_irq_kms_sw_irq_get_delayed(struct radeon_device *rdev, int ring);
 void radeon_irq_kms_sw_irq_put(struct radeon_device *rdev, int ring);
 void radeon_irq_kms_pflip_irq_get(struct radeon_device *rdev, int crtc);
 void radeon_irq_kms_pflip_irq_put(struct radeon_device *rdev, int crtc);
@@ -2276,6 +2278,7 @@ struct radeon_device {
struct radeon_mman  mman;
struct radeon_fence_driver  fence_drv[RADEON_NUM_RINGS];
wait_queue_head_t   fence_queue;
+   unsignedfence_context;
struct mutexring_lock;
struct radeon_ring  ring[RADEON_NUM_RINGS];
boolib_pool_ready;
@@ -2314,6 +2317,8 @@ struct radeon_device {
struct work_struct hotplug_work;
struct work_struct audio_work;
struct work_struct reset_work;
+   struct work_struct delayed_irq_work;
+
int num_crtc; /* number of crtcs */
struct mutex dc_hw_i2c_mutex; /* display controller hw i2c mutex */
bool has_uvd;
@@ -2366,11 +2371,6 @@ u32 cik_mm_rdoorbell(struct radeon_device *rdev, u32 
index);
 void cik_mm_wdoorbell(struct radeon_device *rdev, u32 index, u32 v);

 /*
- * Cast helper
- */
-#define to_radeon_fence(p) ((struct radeon_fence *)(p))
-
-/*
  * Registers read & write functions.
  */
 #define RREG8(reg) readb((rdev->rmmio) + (reg))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 21efd32d07ee..dbf3a8bc91d2 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1213,6 +1213,7 @@ int radeon_device_init(struct radeon_device *rdev,
for (i = 0; i < RADEON_NUM_RINGS; i++) {
rdev->ring[i].idx = i;
}
+   rdev->fence_context = fence_context_alloc(RADEON_NUM_RINGS);

DRM_INFO("initializing kernel modesetting (%s 0x%04X:0x%04X 
0x%04X:0x%04X).\n",
radeon_family_name[rdev->family], pdev->vendor, pdev->device,
@@ -1622,15 +1623,13 @@ int radeon_gpu_reset(struct radeon_device *rdev)

bool saved = false;

-   int i, r;
+   int i, r = 0;
int resched;

down_write(>exclusive_lock);

-   if (!rdev->needs_reset) {
-   up_write(>exclusive_lock);
-   return 0;
-   }
+   if (!rdev->needs_reset)
+   goto out;

rdev->needs_reset = false;

@@ -1697,7 +1696,18 @@ retry:
dev_info(rdev->dev, "GPU reset failed\n");
}

-   up_write(>exclusive_lock);
+out:
+   /*
+* force all waiters to recheck, some may have been
+* added while the exclusive_lock was unavailable
+*/
+   downgrade_write(>exclusive_lock);
+   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+  

[PATCH 10/19] drm/radeon: add timeout argument to radeon_fence_wait_seq

[Maarten Lankhorst]

This makes it possible to wait for a specific amount of time,
rather than wait until infinity.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_fence.c |   50 -
 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index c055acc3a271..f79e0b34582b 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -318,22 +318,25 @@ static bool radeon_fence_any_seq_signaled(struct 
radeon_device *rdev, u64 *seq)
 }

 /**
- * radeon_fence_wait_seq - wait for a specific sequence numbers
+ * radeon_fence_wait_seq_timeout - wait for a specific sequence numbers
  *
  * @rdev: radeon device pointer
  * @target_seq: sequence number(s) we want to wait for
  * @intr: use interruptable sleep
+ * @timeout: maximum time to wait, or MAX_SCHEDULE_TIMEOUT for infinite wait
  *
  * Wait for the requested sequence number(s) to be written by any ring
  * (all asics).  Sequnce number array is indexed by ring id.
  * @intr selects whether to use interruptable (true) or non-interruptable
  * (false) sleep when waiting for the sequence number.  Helper function
  * for radeon_fence_wait_*().
- * Returns 0 if the sequence number has passed, error for all other cases.
+ * Returns remaining time if the sequence number has passed, 0 when
+ * the wait timeout, or an error for all other cases.
  * -EDEADLK is returned when a GPU lockup has been detected.
  */
-static int radeon_fence_wait_seq(struct radeon_device *rdev, u64 *target_seq,
-bool intr)
+static long radeon_fence_wait_seq_timeout(struct radeon_device *rdev,
+ u64 *target_seq, bool intr,
+ long timeout)
 {
uint64_t last_seq[RADEON_NUM_RINGS];
bool signaled;
@@ -355,11 +358,11 @@ static int radeon_fence_wait_seq(struct radeon_device 
*rdev, u64 *target_seq,
if (intr) {
r = wait_event_interruptible_timeout(rdev->fence_queue, 
(
(signaled = radeon_fence_any_seq_signaled(rdev, 
target_seq))
-|| rdev->needs_reset), MAX_SCHEDULE_TIMEOUT);
+|| rdev->needs_reset), timeout);
} else {
r = wait_event_timeout(rdev->fence_queue, (
(signaled = radeon_fence_any_seq_signaled(rdev, 
target_seq))
-|| rdev->needs_reset), MAX_SCHEDULE_TIMEOUT);
+|| rdev->needs_reset), timeout);
}

for (i = 0; i < RADEON_NUM_RINGS; ++i) {
@@ -370,20 +373,22 @@ static int radeon_fence_wait_seq(struct radeon_device 
*rdev, u64 *target_seq,
trace_radeon_fence_wait_end(rdev->ddev, i, 
target_seq[i]);
}

-   if (r < 0)
+   if (r <= 0)
return r;

if (rdev->needs_reset)
return -EDEADLK;
+
+   timeout = r;
}
-   return 0;
+   return timeout;
 }

 /**
  * radeon_fence_wait - wait for a fence to signal
  *
  * @fence: radeon fence object
- * @intr: use interruptable sleep
+ * @intr: use interruptible sleep
  *
  * Wait for the requested fence to signal (all asics).
  * @intr selects whether to use interruptable (true) or non-interruptable
@@ -393,7 +398,7 @@ static int radeon_fence_wait_seq(struct radeon_device 
*rdev, u64 *target_seq,
 int radeon_fence_wait(struct radeon_fence *fence, bool intr)
 {
uint64_t seq[RADEON_NUM_RINGS] = {};
-   int r;
+   long r;

if (fence == NULL) {
WARN(1, "Querying an invalid fence : %p !\n", fence);
@@ -404,9 +409,10 @@ int radeon_fence_wait(struct radeon_fence *fence, bool 
intr)
if (seq[fence->ring] == RADEON_FENCE_SIGNALED_SEQ)
return 0;

-   r = radeon_fence_wait_seq(fence->rdev, seq, intr);
-   if (r)
+   r = radeon_fence_wait_seq_timeout(fence->rdev, seq, intr, 
MAX_SCHEDULE_TIMEOUT);
+   if (r < 0) {
return r;
+   }

fence->seq = RADEON_FENCE_SIGNALED_SEQ;
return 0;
@@ -431,7 +437,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev,
 {
uint64_t seq[RADEON_NUM_RINGS];
unsigned i, num_rings = 0;
-   int r;
+   long r;

for (i = 0; i < RADEON_NUM_RINGS; ++i) {
seq[i] = 0;
@@ -452,8 +458,8 @@ int radeon_fence_wait_any(struct radeon_device *rdev,
if (num_rings == 0)
return -ENOENT;

-   r = radeon_fence_wait_seq(rdev, seq, intr);
-   if (r) {
+   r = radeon_fence_wait_seq_timeout(rdev, seq, intr, 
MAX_SCHEDULE_TIMEOUT);
+   if (r < 0) {
return r;
}
return 0;
@@ -472,6 

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
V1 had a nasty bug breaking gpu lockup recovery. The fix is not
allowing radeon_fence_driver_check_lockup to take exclusive_lock,
and kill it during lockup recovery instead.
---
 drivers/gpu/drm/radeon/radeon.h|3 +
 drivers/gpu/drm/radeon/radeon_device.c |5 +
 drivers/gpu/drm/radeon/radeon_fence.c  |  124 ++--
 drivers/gpu/drm/radeon/radeon_ring.c   |1 
 4 files changed, 77 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 60c47f829122..b01d88fc10cb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -347,6 +347,8 @@ struct radeon_fence_driver {
uint64_tsync_seq[RADEON_NUM_RINGS];
atomic64_t  last_seq;
boolinitialized;
+   struct delayed_work fence_check_work;
+   struct radeon_device*rdev;
 };

 struct radeon_fence {
@@ -360,6 +362,7 @@ struct radeon_fence {

 int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
 int radeon_fence_driver_init(struct radeon_device *rdev);
+void radeon_fence_cancel_delayed_check(struct radeon_device *rdev, int ring);
 void radeon_fence_driver_fini(struct radeon_device *rdev);
 void radeon_fence_driver_force_completion(struct radeon_device *rdev);
 int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence **fence, 
int ring);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 697add2cd4e3..21efd32d07ee 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1637,6 +1637,11 @@ int radeon_gpu_reset(struct radeon_device *rdev)
radeon_save_bios_scratch_regs(rdev);
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(>mman.bdev);
+
+   /* kill all the hangcheck tests too */
+   for (i = 0; i < RADEON_NUM_RINGS; ++i)
+   radeon_fence_cancel_delayed_check(rdev, i);
+
radeon_pm_suspend(rdev);
radeon_suspend(rdev);

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 913787085dfa..c055acc3a271 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -125,16 +125,7 @@ int radeon_fence_emit(struct radeon_device *rdev,
return 0;
 }

-/**
- * radeon_fence_process - process a fence
- *
- * @rdev: radeon_device pointer
- * @ring: ring index the fence is associated with
- *
- * Checks the current fence value and wakes the fence queue
- * if the sequence number has increased (all asics).
- */
-void radeon_fence_process(struct radeon_device *rdev, int ring)
+static bool __radeon_fence_process(struct radeon_device *rdev, int ring)
 {
uint64_t seq, last_seq, last_emitted;
unsigned count_loop = 0;
@@ -190,7 +181,51 @@ void radeon_fence_process(struct radeon_device *rdev, int 
ring)
}
} while (atomic64_xchg(>fence_drv[ring].last_seq, seq) > seq);

-   if (wake)
+   if (seq < last_emitted)
+   mod_delayed_work(system_power_efficient_wq,
+>fence_drv[ring].fence_check_work,
+RADEON_FENCE_JIFFIES_TIMEOUT);
+
+   return wake;
+}
+
+static void radeon_fence_driver_check_lockup(struct work_struct *work)
+{
+   struct radeon_fence_driver *fence_drv;
+   struct radeon_device *rdev;
+   unsigned long iring;
+
+   fence_drv = container_of(work, struct radeon_fence_driver, 
fence_check_work.work);
+   rdev = fence_drv->rdev;
+   iring = fence_drv - >fence_drv[0];
+
+   if (__radeon_fence_process(rdev, iring))
+   wake_up_all(>fence_queue);
+   else if (radeon_ring_is_lockup(rdev, iring, >ring[iring])) {
+   /* good news we believe it's a lockup */
+   dev_warn(rdev->dev, "GPU lockup (current fence id "
+"0x%016llx last fence id 0x%016llx on ring %ld)\n",
+(uint64_t)atomic64_read(_drv->last_seq),
+fence_drv->sync_seq[iring], iring);
+
+   /* remember that we need an reset */
+   rdev->needs_reset = true;
+   wake_up_all(>fence_queue);
+   }
+}
+
+/**
+ * radeon_fence_process - process a fence
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the fence is associated with
+ *
+ * Checks the current fence value and wakes the fence queue
+ * if the sequence number has increased (all asics).
+ */
+void radeon_fence_process(struct radeon_device *rdev, int ring)
+{
+   if (__radeon_fence_process(rdev, ring))
wake_up_all(>fence_queue);
 }

@@ -302,9 +337,10 @@ static int radeon_fence_wait_seq(struct radeon_device 
*rdev, u64 *target_seq,
 {
uint64_t last_seq[RADEON_NUM_RINGS];
bool signaled;
-  

[PATCH 08/19] drm/nouveau: rework to new fence interface

[Maarten Lankhorst]

From: Maarten Lankhorst 

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/core/core/event.c |4 
 drivers/gpu/drm/nouveau/nouveau_bo.c  |6 
 drivers/gpu/drm/nouveau/nouveau_display.c |4 
 drivers/gpu/drm/nouveau/nouveau_fence.c   |  435 -
 drivers/gpu/drm/nouveau/nouveau_fence.h   |   20 +
 drivers/gpu/drm/nouveau/nouveau_gem.c |   17 -
 drivers/gpu/drm/nouveau/nv04_fence.c  |4 
 drivers/gpu/drm/nouveau/nv10_fence.c  |4 
 drivers/gpu/drm/nouveau/nv17_fence.c  |2 
 drivers/gpu/drm/nouveau/nv50_fence.c  |2 
 drivers/gpu/drm/nouveau/nv84_fence.c  |   11 -
 11 files changed, 330 insertions(+), 179 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index ae81d3b5d8b7..5ddc28ec7660 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -139,14 +139,14 @@ nouveau_event_ref(struct nouveau_eventh *handler, struct 
nouveau_eventh **ref)
 void
 nouveau_event_trigger(struct nouveau_event *event, u32 types, int index)
 {
-   struct nouveau_eventh *handler;
+   struct nouveau_eventh *handler, *next;
unsigned long flags;

if (WARN_ON(index >= event->index_nr))
return;

spin_lock_irqsave(>list_lock, flags);
-   list_for_each_entry(handler, >list[index], head) {
+   list_for_each_entry_safe(handler, next, >list[index], head) {
if (!test_bit(NVKM_EVENT_ENABLE, >flags))
continue;
if (!(handler->types & types))
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 2cf5b0572f66..6e71d3dc2d87 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -959,7 +959,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict, bool intr,
}

mutex_lock_nested(>cli->mutex, SINGLE_DEPTH_NESTING);
-   ret = nouveau_fence_sync(bo->sync_obj, chan);
+   ret = nouveau_fence_sync(nouveau_bo(bo), chan);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, >mem, new_mem);
if (ret == 0) {
@@ -1432,10 +1432,12 @@ nouveau_bo_fence_unref(void **sync_obj)
 void
 nouveau_bo_fence(struct nouveau_bo *nvbo, struct nouveau_fence *fence)
 {
-   lockdep_assert_held(>bo.resv->lock.base);
+   struct reservation_object *resv = nvbo->bo.resv;

nouveau_bo_fence_unref(>bo.sync_obj);
nvbo->bo.sync_obj = nouveau_fence_ref(fence);
+
+   reservation_object_add_excl_fence(resv, >base);
 }

 static void *
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 7928f8f07334..2c4798750b20 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -660,7 +660,7 @@ nouveau_page_flip_emit(struct nouveau_channel *chan,
spin_unlock_irqrestore(>event_lock, flags);

/* Synchronize with the old framebuffer */
-   ret = nouveau_fence_sync(old_bo->bo.sync_obj, chan);
+   ret = nouveau_fence_sync(old_bo, chan);
if (ret)
goto fail;

@@ -721,7 +721,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
goto fail_unpin;

/* synchronise rendering channel with the kernel's channel */
-   ret = nouveau_fence_sync(new_bo->bo.sync_obj, chan);
+   ret = nouveau_fence_sync(new_bo, chan);
if (ret) {
ttm_bo_unreserve(_bo->bo);
goto fail_unpin;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index ab5ea3b0d666..d24f8ce4341a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -32,91 +32,139 @@
 #include "nouveau_drm.h"
 #include "nouveau_dma.h"
 #include "nouveau_fence.h"
+#include 

 #include 

-struct fence_work {
-   struct work_struct base;
-   struct list_head head;
-   void (*func)(void *);
-   void *data;
-};
+static const struct fence_ops nouveau_fence_ops_uevent;
+static const struct fence_ops nouveau_fence_ops_legacy;

 static void
 nouveau_fence_signal(struct nouveau_fence *fence)
 {
-   struct fence_work *work, *temp;
+   fence_signal_locked(>base);
+   list_del(>head);
+
+   if (fence->base.ops == _fence_ops_uevent &&
+   fence->event.head.next) {
+   struct nouveau_event *event;

-   list_for_each_entry_safe(work, temp, >work, head) {
-   schedule_work(>base);
-   list_del(>head);
+   list_del(>event.head);
+   fence->event.head.next = NULL;
+
+   event = container_of(fence->base.lock, typeof(*event), 
list_lock);
+   nouveau_event_put(>event);
}

-   fence->channel = NULL;
-   

[PATCH 07/19] drm/ttm: kill fence_lock

[Maarten Lankhorst]

No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   25 +++---
 drivers/gpu/drm/nouveau/nouveau_display.c |6 --
 drivers/gpu/drm/nouveau/nouveau_gem.c |   16 +-
 drivers/gpu/drm/qxl/qxl_cmd.c |2 -
 drivers/gpu/drm/qxl/qxl_fence.c   |4 --
 drivers/gpu/drm/qxl/qxl_object.h  |2 -
 drivers/gpu/drm/qxl/qxl_release.c |2 -
 drivers/gpu/drm/radeon/radeon_display.c   |9 ++-
 drivers/gpu/drm/radeon/radeon_object.c|2 -
 drivers/gpu/drm/ttm/ttm_bo.c  |   75 +++--
 drivers/gpu/drm/ttm/ttm_bo_util.c |5 --
 drivers/gpu/drm/ttm/ttm_bo_vm.c   |3 -
 drivers/gpu/drm/ttm/ttm_execbuf_util.c|2 -
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c|4 --
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |   17 ++-
 include/drm/ttm/ttm_bo_api.h  |5 --
 include/drm/ttm/ttm_bo_driver.h   |3 -
 17 files changed, 40 insertions(+), 142 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 62d79492c7c5..2cf5b0572f66 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1196,9 +1196,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict, 
bool intr,
}

/* Fallback to software copy. */
-   spin_lock(>bdev->fence_lock);
ret = ttm_bo_wait(bo, true, intr, no_wait_gpu);
-   spin_unlock(>bdev->fence_lock);
if (ret == 0)
ret = ttm_bo_move_memcpy(bo, evict, no_wait_gpu, new_mem);

@@ -1425,26 +1423,19 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
ttm_pool_unpopulate(ttm);
 }

+static void
+nouveau_bo_fence_unref(void **sync_obj)
+{
+   nouveau_fence_unref((struct nouveau_fence **)sync_obj);
+}
+
 void
 nouveau_bo_fence(struct nouveau_bo *nvbo, struct nouveau_fence *fence)
 {
-   struct nouveau_fence *new_fence = nouveau_fence_ref(fence);
-   struct nouveau_fence *old_fence = NULL;
-
lockdep_assert_held(>bo.resv->lock.base);

-   spin_lock(>bo.bdev->fence_lock);
-   old_fence = nvbo->bo.sync_obj;
-   nvbo->bo.sync_obj = new_fence;
-   spin_unlock(>bo.bdev->fence_lock);
-
-   nouveau_fence_unref(_fence);
-}
-
-static void
-nouveau_bo_fence_unref(void **sync_obj)
-{
-   nouveau_fence_unref((struct nouveau_fence **)sync_obj);
+   nouveau_bo_fence_unref(>bo.sync_obj);
+   nvbo->bo.sync_obj = nouveau_fence_ref(fence);
 }

 static void *
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 826b66c44235..7928f8f07334 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -721,11 +721,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
goto fail_unpin;

/* synchronise rendering channel with the kernel's channel */
-   spin_lock(_bo->bo.bdev->fence_lock);
-   fence = nouveau_fence_ref(new_bo->bo.sync_obj);
-   spin_unlock(_bo->bo.bdev->fence_lock);
-   ret = nouveau_fence_sync(fence, chan);
-   nouveau_fence_unref();
+   ret = nouveau_fence_sync(new_bo->bo.sync_obj, chan);
if (ret) {
ttm_bo_unreserve(_bo->bo);
goto fail_unpin;
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 0da3740f150f..474f67238cef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -105,9 +105,7 @@ nouveau_gem_object_unmap(struct nouveau_bo *nvbo, struct 
nouveau_vma *vma)
list_del(>head);

if (mapped) {
-   spin_lock(>bo.bdev->fence_lock);
fence = nouveau_fence_ref(nvbo->bo.sync_obj);
-   spin_unlock(>bo.bdev->fence_lock);
}

if (fence) {
@@ -432,17 +430,11 @@ retry:
 static int
 validate_sync(struct nouveau_channel *chan, struct nouveau_bo *nvbo)
 {
-   struct nouveau_fence *fence = NULL;
+   struct nouveau_fence *fence = nvbo->bo.sync_obj;
int ret = 0;

-   spin_lock(>bo.bdev->fence_lock);
-   fence = nouveau_fence_ref(nvbo->bo.sync_obj);
-   spin_unlock(>bo.bdev->fence_lock);
-
-   if (fence) {
+   if (fence)
ret = nouveau_fence_sync(fence, chan);
-   nouveau_fence_unref();
-   }

return ret;
 }
@@ -661,9 +653,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
data |= r->vor;
}

-   spin_lock(>bo.bdev->fence_lock);
ret = ttm_bo_wait(>bo, false, false, false);
-   spin_unlock(>bo.bdev->fence_lock);
if (ret) {
NV_ERROR(cli, "reloc 

[PATCH 06/19] drm/ttm: call ttm_bo_wait while inside a reservation

[Maarten Lankhorst]

This is the last remaining function that doesn't use the reservation
lock completely to fence off access to a buffer.
---
 drivers/gpu/drm/ttm/ttm_bo.c |   25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3da89d5dab60..df08f18f05ac 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -502,17 +502,6 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
if (ret)
return ret;

-   /*
-* remove sync_obj with ttm_bo_wait, the wait should be
-* finished, and no new wait object should have been added.
-*/
-   spin_lock(>fence_lock);
-   ret = ttm_bo_wait(bo, false, false, true);
-   WARN_ON(ret);
-   spin_unlock(>fence_lock);
-   if (ret)
-   return ret;
-
spin_lock(>lru_lock);
ret = __ttm_bo_reserve(bo, false, true, false, NULL);

@@ -528,8 +517,16 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
spin_unlock(>lru_lock);
return 0;
}
-   } else
-   spin_unlock(>fence_lock);
+
+   /*
+* remove sync_obj with ttm_bo_wait, the wait should be
+* finished, and no new wait object should have been added.
+*/
+   spin_lock(>fence_lock);
+   ret = ttm_bo_wait(bo, false, false, true);
+   WARN_ON(ret);
+   }
+   spin_unlock(>fence_lock);

if (ret || unlikely(list_empty(>ddestroy))) {
__ttm_bo_unreserve(bo);
@@ -1539,6 +1536,8 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
void *sync_obj;
int ret = 0;

+   lockdep_assert_held(>resv->lock.base);
+
if (likely(bo->sync_obj == NULL))
return 0;

[PATCH 05/19] drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence

[Maarten Lankhorst]

This will ensure we always hold the required lock when calling those functions.
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  |2 ++
 drivers/gpu/drm/nouveau/nouveau_display.c |   17 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index ba29a701ca1d..62d79492c7c5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1431,6 +1431,8 @@ nouveau_bo_fence(struct nouveau_bo *nvbo, struct 
nouveau_fence *fence)
struct nouveau_fence *new_fence = nouveau_fence_ref(fence);
struct nouveau_fence *old_fence = NULL;

+   lockdep_assert_held(>bo.resv->lock.base);
+
spin_lock(>bo.bdev->fence_lock);
old_fence = nvbo->bo.sync_obj;
nvbo->bo.sync_obj = new_fence;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 47ad74255bf1..826b66c44235 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -716,6 +716,9 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
}

mutex_lock(>cli->mutex);
+   ret = ttm_bo_reserve(_bo->bo, true, false, false, NULL);
+   if (ret)
+   goto fail_unpin;

/* synchronise rendering channel with the kernel's channel */
spin_lock(_bo->bo.bdev->fence_lock);
@@ -723,12 +726,18 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
spin_unlock(_bo->bo.bdev->fence_lock);
ret = nouveau_fence_sync(fence, chan);
nouveau_fence_unref();
-   if (ret)
+   if (ret) {
+   ttm_bo_unreserve(_bo->bo);
goto fail_unpin;
+   }

-   ret = ttm_bo_reserve(_bo->bo, true, false, false, NULL);
-   if (ret)
-   goto fail_unpin;
+   if (new_bo != old_bo) {
+   ttm_bo_unreserve(_bo->bo);
+
+   ret = ttm_bo_reserve(_bo->bo, true, false, false, NULL);
+   if (ret)
+   goto fail_unpin;
+   }

/* Initialize a page flip struct */
*s = (struct nouveau_page_flip_state)

[PATCH 04/19] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Maarten Lankhorst]

Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.

After the switch to rcu the reservation lock will be
removed again.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c |   22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index df9d451afdcd..0da3740f150f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -886,17 +886,31 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void 
*data,
struct drm_gem_object *gem;
struct nouveau_bo *nvbo;
bool no_wait = !!(req->flags & NOUVEAU_GEM_CPU_PREP_NOWAIT);
-   int ret = -EINVAL;
+   int ret;
+   struct nouveau_fence *fence = NULL;

gem = drm_gem_object_lookup(dev, file_priv, req->handle);
if (!gem)
return -ENOENT;
nvbo = nouveau_gem_object(gem);

-   spin_lock(>bo.bdev->fence_lock);
-   ret = ttm_bo_wait(>bo, true, true, no_wait);
-   spin_unlock(>bo.bdev->fence_lock);
+   ret = ttm_bo_reserve(>bo, true, false, false, 0);
+   if (!ret) {
+   spin_lock(>bo.bdev->fence_lock);
+   ret = ttm_bo_wait(>bo, true, true, true);
+   if (!no_wait && ret)
+   fence = nouveau_fence_ref(nvbo->bo.sync_obj);
+   spin_unlock(>bo.bdev->fence_lock);
+
+   ttm_bo_unreserve(>bo);
+   }
drm_gem_object_unreference_unlocked(gem);
+
+   if (fence) {
+   ret = nouveau_fence_wait(fence, true, no_wait);
+   nouveau_fence_unref();
+   }
+
return ret;
 }

[PATCH 03/19] drm/ttm: kill off some members to ttm_validate_buffer

[Maarten Lankhorst]

This reorders the list to keep track of what buffers are reserved,
so previous members are always unreserved.

This gets rid of some bookkeeping that's no longer needed,
while simplifying the code some.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/qxl/qxl_release.c   |1 
 drivers/gpu/drm/ttm/ttm_execbuf_util.c  |  142 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |1 
 include/drm/ttm/ttm_execbuf_util.h  |3 -
 4 files changed, 50 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 2b43e5deb051..e85c4d274dc0 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -350,7 +350,6 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)

ttm_bo_add_to_lru(bo);
__ttm_bo_unreserve(bo);
-   entry->reserved = false;
}
spin_unlock(>fence_lock);
spin_unlock(>lru_lock);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 39a11bbd2bac..6db47a72667e 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -32,20 +32,12 @@
 #include 
 #include 

-static void ttm_eu_backoff_reservation_locked(struct list_head *list)
+static void ttm_eu_backoff_reservation_reverse(struct list_head *list,
+ struct ttm_validate_buffer *entry)
 {
-   struct ttm_validate_buffer *entry;
-
-   list_for_each_entry(entry, list, head) {
+   list_for_each_entry_continue_reverse(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
-   if (!entry->reserved)
-   continue;

-   entry->reserved = false;
-   if (entry->removed) {
-   ttm_bo_add_to_lru(bo);
-   entry->removed = false;
-   }
__ttm_bo_unreserve(bo);
}
 }
@@ -56,27 +48,9 @@ static void ttm_eu_del_from_lru_locked(struct list_head 
*list)

list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
-   if (!entry->reserved)
-   continue;
+   unsigned put_count = ttm_bo_del_from_lru(bo);

-   if (!entry->removed) {
-   entry->put_count = ttm_bo_del_from_lru(bo);
-   entry->removed = true;
-   }
-   }
-}
-
-static void ttm_eu_list_ref_sub(struct list_head *list)
-{
-   struct ttm_validate_buffer *entry;
-
-   list_for_each_entry(entry, list, head) {
-   struct ttm_buffer_object *bo = entry->bo;
-
-   if (entry->put_count) {
-   ttm_bo_list_ref_sub(bo, entry->put_count, true);
-   entry->put_count = 0;
-   }
+   ttm_bo_list_ref_sub(bo, put_count, true);
}
 }

@@ -91,11 +65,18 @@ void ttm_eu_backoff_reservation(struct ww_acquire_ctx 
*ticket,

entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry->bo->glob;
+
spin_lock(>lru_lock);
-   ttm_eu_backoff_reservation_locked(list);
+   list_for_each_entry(entry, list, head) {
+   struct ttm_buffer_object *bo = entry->bo;
+
+   ttm_bo_add_to_lru(bo);
+   __ttm_bo_unreserve(bo);
+   }
+   spin_unlock(>lru_lock);
+
if (ticket)
ww_acquire_fini(ticket);
-   spin_unlock(>lru_lock);
 }
 EXPORT_SYMBOL(ttm_eu_backoff_reservation);

@@ -121,64 +102,55 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
if (list_empty(list))
return 0;

-   list_for_each_entry(entry, list, head) {
-   entry->reserved = false;
-   entry->put_count = 0;
-   entry->removed = false;
-   }
-
entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry->bo->glob;

if (ticket)
ww_acquire_init(ticket, _ww_class);
-retry:
+
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;

-   /* already slowpath reserved? */
-   if (entry->reserved)
-   continue;
-
ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), true,
   ticket);
+   if (!ret && unlikely(atomic_read(>cpu_writers) > 0)) {
+   __ttm_bo_unreserve(bo);

-   if (ret == -EDEADLK) {
-   /* uh oh, we lost out, drop every reservation and try
-* to only reserve this buffer, then start over if
-* this succeeds.
-*/
-   BUG_ON(ticket == NULL);
-   spin_lock(>lru_lock);
-  

[PATCH 02/19] drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers

[Maarten Lankhorst]

It seems some drivers really want this as a parameter,
like vmwgfx.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/qxl/qxl_release.c|2 +-
 drivers/gpu/drm/radeon/radeon_object.c   |2 +-
 drivers/gpu/drm/radeon/radeon_uvd.c  |2 +-
 drivers/gpu/drm/radeon/radeon_vm.c   |2 +-
 drivers/gpu/drm/ttm/ttm_execbuf_util.c   |   22 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |7 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |2 +-
 include/drm/ttm/ttm_execbuf_util.h   |9 +
 8 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 14e776f1d14e..2b43e5deb051 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -159,7 +159,7 @@ int qxl_release_reserve_list(struct qxl_release *release, 
bool no_intr)
if (list_is_singular(>bos))
return 0;

-   ret = ttm_eu_reserve_buffers(>ticket, >bos);
+   ret = ttm_eu_reserve_buffers(>ticket, >bos, !no_intr);
if (ret)
return ret;

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 6c717b257d6d..a3ed725ea641 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -438,7 +438,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
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);
+   r = ttm_eu_reserve_buffers(ticket, head, true);
if (unlikely(r != 0)) {
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index a4ad270e8261..67b2a367df40 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -620,7 +620,7 @@ static int radeon_uvd_send_msg(struct radeon_device *rdev,
INIT_LIST_HEAD();
list_add(, );

-   r = ttm_eu_reserve_buffers(, );
+   r = ttm_eu_reserve_buffers(, , true);
if (r)
return r;

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 725d3669014f..0a0d0291af0d 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -365,7 +365,7 @@ static int radeon_vm_clear_bo(struct radeon_device *rdev,
 INIT_LIST_HEAD();
 list_add(, );

-r = ttm_eu_reserve_buffers(, );
+r = ttm_eu_reserve_buffers(, , true);
 if (r)
return r;

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index e8dac8758528..39a11bbd2bac 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -112,7 +112,7 @@ EXPORT_SYMBOL(ttm_eu_backoff_reservation);
  */

 int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
-  struct list_head *list)
+  struct list_head *list, bool intr)
 {
struct ttm_bo_global *glob;
struct ttm_validate_buffer *entry;
@@ -140,7 +140,7 @@ retry:
if (entry->reserved)
continue;

-   ret = __ttm_bo_reserve(bo, true, (ticket == NULL), true,
+   ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), true,
   ticket);

if (ret == -EDEADLK) {
@@ -153,13 +153,17 @@ retry:
ttm_eu_backoff_reservation_locked(list);
spin_unlock(>lru_lock);
ttm_eu_list_ref_sub(list);
-   ret = ww_mutex_lock_slow_interruptible(>resv->lock,
-  ticket);
-   if (unlikely(ret != 0)) {
-   if (ret == -EINTR)
-   ret = -ERESTARTSYS;
-   goto err_fini;
-   }
+
+   if (intr) {
+   ret = 
ww_mutex_lock_slow_interruptible(>resv->lock,
+  ticket);
+   if (unlikely(ret != 0)) {
+   if (ret == -EINTR)
+   ret = -ERESTARTSYS;
+   goto err_fini;
+   }
+   } else
+   ww_mutex_lock_slow(>resv->lock, ticket);

entry->reserved = true;
if (unlikely(atomic_read(>cpu_writers) > 0)) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 7bfdaa163a33..24f067bf438d 100644
--- 

[PATCH 01/19] fence: add debugging lines to fence_is_signaled for the callback

[Maarten Lankhorst]

fence_is_signaled callback should support being run in
atomic context, but not in irq context.

Signed-off-by: Maarten Lankhorst 
---
 include/linux/fence.h |   23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index d174585b874b..c1a4519ba2f5 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -143,6 +143,7 @@ struct fence_cb {
  * the second time will be a noop since it was already signaled.
  *
  * Notes on signaled:
+ * Called with interrupts enabled, and never from interrupt context.
  * May set fence->status if returning true.
  *
  * Notes on wait:
@@ -268,15 +269,29 @@ fence_is_signaled_locked(struct fence *fence)
 static inline bool
 fence_is_signaled(struct fence *fence)
 {
+   bool ret;
+
if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
return true;

-   if (fence->ops->signaled && fence->ops->signaled(fence)) {
+   if (!fence->ops->signaled)
+   return false;
+
+   if (config_enabled(CONFIG_PROVE_LOCKING))
+   WARN_ON(in_interrupt() || irqs_disabled());
+
+   if (config_enabled(CONFIG_DEBUG_ATOMIC_SLEEP))
+   preempt_disable();
+
+   ret = fence->ops->signaled(fence);
+
+   if (config_enabled(CONFIG_DEBUG_ATOMIC_SLEEP))
+   preempt_enable();
+
+   if (ret)
fence_signal(fence);
-   return true;
-   }

-   return false;
+   return ret;
 }

 /**

[PATCH 01/18] fence: add debugging lines to fence_is_signaled for the callback

[Maarten Lankhorst]

fence_is_signaled callback should support being run in
atomic context, but not in irq context.

Signed-off-by: Maarten Lankhorst 
---
 include/linux/fence.h |   23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index d174585b874b..c1a4519ba2f5 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -143,6 +143,7 @@ struct fence_cb {
  * the second time will be a noop since it was already signaled.
  *
  * Notes on signaled:
+ * Called with interrupts enabled, and never from interrupt context.
  * May set fence->status if returning true.
  *
  * Notes on wait:
@@ -268,15 +269,29 @@ fence_is_signaled_locked(struct fence *fence)
 static inline bool
 fence_is_signaled(struct fence *fence)
 {
+   bool ret;
+
if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
return true;

-   if (fence->ops->signaled && fence->ops->signaled(fence)) {
+   if (!fence->ops->signaled)
+   return false;
+
+   if (config_enabled(CONFIG_PROVE_LOCKING))
+   WARN_ON(in_interrupt() || irqs_disabled());
+
+   if (config_enabled(CONFIG_DEBUG_ATOMIC_SLEEP))
+   preempt_disable();
+
+   ret = fence->ops->signaled(fence);
+
+   if (config_enabled(CONFIG_DEBUG_ATOMIC_SLEEP))
+   preempt_enable();
+
+   if (ret)
fence_signal(fence);
-   return true;
-   }

-   return false;
+   return ret;
 }

 /**

[PATCH 00/17] Convert TTM to the new fence interface. v2

[Maarten Lankhorst]

This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git

Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with fence_obj.
After flipping the switch RCU becomes available instead, and
the extra reservations can be dropped again. 

I've done at least basic testing on all the drivers I've converted
at some point, but more testing is definitely welcomed!

Changes since v1:
- Almost all radeon changes, radeon reworked their page flip code which
  made things easier for me.
- Added a delayed work for radeon that checks gpu lockups.
- Reworked the radeon fence implementation to remove deadlocks,
  and end up slightly cleaner.

---

Maarten Lankhorst (18):
  fence: add debugging lines to fence_is_signaled for the callback
  drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers
  drm/ttm: kill off some members to ttm_validate_buffer
  drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep
  drm/nouveau: require reservations for nouveau_fence_sync and 
nouveau_bo_fence
  drm/ttm: call ttm_bo_wait while inside a reservation
  drm/ttm: kill fence_lock
  drm/nouveau: rework to new fence interface
  drm/radeon: handle lockup in delayed work, v2
  drm/radeon: add timeout argument to radeon_fence_wait_seq
  drm/radeon: use common fence implementation for fences, v2
  drm/qxl: rework to new fence interface
  drm/vmwgfx: get rid of different types of fence_flags entirely
  drm/vmwgfx: rework to new fence interface
  drm/ttm: flip the switch, and convert to dma_fence
  drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep
  drm/radeon: use rcu waits in some ioctls
  drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab


 drivers/gpu/drm/nouveau/core/core/event.c |4 
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   59 +---
 drivers/gpu/drm/nouveau/nouveau_display.c |   25 +-
 drivers/gpu/drm/nouveau/nouveau_fence.c   |  431 +++--
 drivers/gpu/drm/nouveau/nouveau_fence.h   |   22 +
 drivers/gpu/drm/nouveau/nouveau_gem.c |   55 +---
 drivers/gpu/drm/nouveau/nv04_fence.c  |4 
 drivers/gpu/drm/nouveau/nv10_fence.c  |4 
 drivers/gpu/drm/nouveau/nv17_fence.c  |2 
 drivers/gpu/drm/nouveau/nv50_fence.c  |2 
 drivers/gpu/drm/nouveau/nv84_fence.c  |   11 -
 drivers/gpu/drm/qxl/Makefile  |2 
 drivers/gpu/drm/qxl/qxl_cmd.c |7 
 drivers/gpu/drm/qxl/qxl_debugfs.c |   16 +
 drivers/gpu/drm/qxl/qxl_drv.h |   20 -
 drivers/gpu/drm/qxl/qxl_fence.c   |   91 --
 drivers/gpu/drm/qxl/qxl_kms.c |1 
 drivers/gpu/drm/qxl/qxl_object.c  |2 
 drivers/gpu/drm/qxl/qxl_object.h  |6 
 drivers/gpu/drm/qxl/qxl_release.c |  172 ++--
 drivers/gpu/drm/qxl/qxl_ttm.c |   93 --
 drivers/gpu/drm/radeon/radeon.h   |   21 +
 drivers/gpu/drm/radeon/radeon_cs.c|   10 +
 drivers/gpu/drm/radeon/radeon_device.c|   27 +-
 drivers/gpu/drm/radeon/radeon_display.c   |8 -
 drivers/gpu/drm/radeon/radeon_fence.c |  405 +--
 drivers/gpu/drm/radeon/radeon_gem.c   |   19 +
 drivers/gpu/drm/radeon/radeon_irq_kms.c   |   43 +++
 drivers/gpu/drm/radeon/radeon_object.c|8 -
 drivers/gpu/drm/radeon/radeon_ring.c  |1 
 drivers/gpu/drm/radeon/radeon_ttm.c   |   34 --
 drivers/gpu/drm/radeon/radeon_uvd.c   |   10 -
 drivers/gpu/drm/radeon/radeon_vm.c|   16 +
 drivers/gpu/drm/ttm/ttm_bo.c  |  239 +---
 drivers/gpu/drm/ttm/ttm_bo_util.c |   28 --
 drivers/gpu/drm/ttm/ttm_bo_vm.c   |3 
 drivers/gpu/drm/ttm/ttm_execbuf_util.c|  146 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c|   47 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |1 
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |   24 --
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  329 --
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.h |   35 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |   43 +--
 include/drm/ttm/ttm_bo_api.h  |7 
 include/drm/ttm/ttm_bo_driver.h   |   29 --
 include/drm/ttm/ttm_execbuf_util.h|   22 +
 include/linux/fence.h |   23 +-
 47 files changed, 1408 insertions(+), 1199 deletions(-)
 delete mode 100644 drivers/gpu/drm/qxl/qxl_fence.c

-- 
Signature

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #133 from Luzipher  ---
(In reply to comment #132)
> Just a thought: you had radeon.dpm=0 set for a long time according to some
> of your posts. Are you sure you've removed that from your Kernel command
> line?

No, I removed that argument a while ago. But I just rechecked, this is what
dmesg prints - so it's really not there anymore:
Command line: BOOT_IMAGE=/kernel-3.16.0-rc4-gd8dacc8 root=/dev/sda7 ro
init=/usr/lib/systemd/systemd

> I can't tell if the reclocking is working as Marek reported in comment #131
> yet. I might have time fireing a game up during the weekend. But should that
> be a problem I can just open a new bug. I don't think this possible
> reclocking issue should keep this bug open.

No, probably not. I'll start a new bug if the issue is not related to bug
#74250.

(In reply to comment #131)
> DPM seems to be working here.

I guess you have a unmodified reference design card ?

-- 
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/20140731/a1d1784f/attachment.html>

[Bug 81837] [radeonsi] memory leaks in OpenCL

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

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

--- Comment #6 from Vladimir Ysikov  ---
Created attachment 103758
  --> https://bugs.freedesktop.org/attachment.cgi?id=103758=edit
valgrind debug symbols

-- 
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/20140731/5eb27d82/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #20 from Aaron B  ---
[7925:7960:0731/125644:ERROR:gpu_watchdog_thread.cc(253)] The GPU process hung.
Terminating after 1 ms.
[7894:7894:0731/125644:ERROR:gpu_process_transport_factory.cc(347)] Lost UI
shared context.

Here also is the message about the process hanging, it was in the log too,
missed it at first.

-- 
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/20140731/d8dc0c18/attachment.html>

[PATCH] drm/msm/hdmi: enable lpm-mux if it is present

[Andreas Färber]

Hi,

Am 31.07.2014 16:46, schrieb Stephane Viau:
> From: Beeresh Gopal 
> 
> lpm-mux is programmed to enable HDMI connector
> on the docking station for S805 chipset based
> devices.
> 
> Signed-off-by: Beeresh Gopal 

You forgot to sign off yourself.

[...]
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
> b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> index 93d1551..1301d03 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> @@ -63,7 +63,8 @@ static int gpio_config(struct hdmi *hdmi, bool on)
>   ret = gpio_request(config->mux_en_gpio, "HDMI_MUX_EN");
>   if (ret) {
>   dev_err(dev->dev, "'%s'(%d) gpio_request 
> failed: %d\n",
> - "HDMI_MUX_SEL", config->mux_en_gpio, 
> ret);
> + "HDMI_MUX_EN",
> + config->mux_en_gpio, ret);
>   goto error4;
>   }
>   gpio_set_value_cansleep(config->mux_en_gpio, 1);

This hunk looks like an unrelated typo fix, which should then probably
go into its own patch.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #19 from Aaron B  ---
It sounds like the same bug, but I'm not 1000% sure. But I had a few crashes in
Chromium, the only out of place log message is:

ATTENTION: default value of option force_s3tc_enable overridden by environment.
[8923:8923:0731/125646:ERROR:sandbox_linux.cc(302)] InitializeSandbox() called
with multiple threads in process gpu-process

Not what to make of it, but it's something more.

-- 
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/20140731/a87add7e/attachment-0001.html>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Am 31.07.2014 12:23, schrieb Thierry Reding:
> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
>> Am 31.07.2014 10:38, schrieb Ajay kumar:
>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>> in configs.
[...]
> If you have something like simplefb enabled in addition to a DRM driver,
> then perhaps the DRM driver isn't properly taking over the framebuffer
> console.

So, with simplefb reverted in U-Boot and ...

* with just the v6 applied (...~2), I get only a black screen from
Linux, no penguins, but the backlight seems on. System comes up okay,
ssh available, and nothing stands out in dmesg.

* with the two iommu patches on top, something breaks badly, no
backlight, no USB/network, system inaccessible.

I.e. U-Boot had no noticeable impact on these symptoms.

* with the iommu patches, but dp-controller, ps8622, panel commented
out, I do get backlight but USB/network not working, system inaccessible.

With simplefb support in U-Boot and with just v6 applied, but
dp-controller, ps8622, panel commented out, things work as well as
before, i.e. this series has no bad side effects. Note that I never
claimed Ajay's series were broken, just reported that things regressed
for me from v4, which may well be DT-related.

The iommu patches interfere with my USB somehow (none or not all devices
powered; with v4, plugging my wifi dongle led to oops but ethernet
dongle worked, so not entirely new symptom), which is bad since my
rootfs is on USB. The internal SDIO-connected Wifi is not enabled yet,
so USB based network is my only alternative to a working display once we
reach userspace.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/aa7eb1ab/attachment-0001.sig>

[libdrm PATCH 3/3] radeon: Use symbol visibility.

[Alex Deucher]

On Thu, Jul 31, 2014 at 9:46 AM, Maarten Lankhorst
 wrote:
> All the bof_* symbols are now no longer exported.
>
> Signed-off-by: Maarten Lankhorst 

Seems reasonable to me.

Reviewed-by: Alex Deucher 

> ---
>  radeon/Makefile.am   |  1 +
>  radeon/radeon_bo.c   | 46 
>  radeon/radeon_bo_gem.c   | 24 +--
>  radeon/radeon_cs.c   | 50 
> +---
>  radeon/radeon_cs_gem.c   |  8 ++--
>  radeon/radeon_cs_space.c | 18 +++--
>  radeon/radeon_surface.c  | 20 +--
>  7 files changed, 98 insertions(+), 69 deletions(-)
>
> diff --git a/radeon/Makefile.am b/radeon/Makefile.am
> index a8cd100..c969573 100644
> --- a/radeon/Makefile.am
> +++ b/radeon/Makefile.am
> @@ -24,6 +24,7 @@
>
>  AM_CFLAGS = \
> $(WARN_CFLAGS) \
> +   $(VISIBILITY_CFLAGS) \
> -I$(top_srcdir) \
> -I$(top_srcdir)/radeon \
> $(PTHREADSTUBS_CFLAGS) \
> diff --git a/radeon/radeon_bo.c b/radeon/radeon_bo.c
> index 6a0f8e7..865e3f7 100644
> --- a/radeon/radeon_bo.c
> +++ b/radeon/radeon_bo.c
> @@ -29,10 +29,14 @@
>   *  Dave Airlie
>   *  J?r?me Glisse 
>   */
> +#ifdef HAVE_CONFIG_H
> +#include 
> +#endif
> +#include 
>  #include 
>  #include 
>
> -void radeon_bo_debug(struct radeon_bo *bo, const char *op)
> +drm_public void radeon_bo_debug(struct radeon_bo *bo, const char *op)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>
> @@ -40,26 +44,23 @@ void radeon_bo_debug(struct radeon_bo *bo, const char *op)
>  op, bo, bo->handle, boi->size, boi->cref);
>  }
>
> -struct radeon_bo *radeon_bo_open(struct radeon_bo_manager *bom,
> - uint32_t handle,
> - uint32_t size,
> - uint32_t alignment,
> - uint32_t domains,
> - uint32_t flags)
> +drm_public struct radeon_bo *
> +radeon_bo_open(struct radeon_bo_manager *bom, uint32_t handle, uint32_t size,
> +  uint32_t alignment, uint32_t domains, uint32_t flags)
>  {
>  struct radeon_bo *bo;
>  bo = bom->funcs->bo_open(bom, handle, size, alignment, domains, flags);
>  return bo;
>  }
>
> -void radeon_bo_ref(struct radeon_bo *bo)
> +drm_public void radeon_bo_ref(struct radeon_bo *bo)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  boi->cref++;
>  boi->bom->funcs->bo_ref(boi);
>  }
>
> -struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
> +drm_public struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  if (bo == NULL)
> @@ -69,19 +70,19 @@ struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
>  return boi->bom->funcs->bo_unref(boi);
>  }
>
> -int radeon_bo_map(struct radeon_bo *bo, int write)
> +drm_public int radeon_bo_map(struct radeon_bo *bo, int write)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  return boi->bom->funcs->bo_map(boi, write);
>  }
>
> -int radeon_bo_unmap(struct radeon_bo *bo)
> +drm_public int radeon_bo_unmap(struct radeon_bo *bo)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  return boi->bom->funcs->bo_unmap(boi);
>  }
>
> -int radeon_bo_wait(struct radeon_bo *bo)
> +drm_public int radeon_bo_wait(struct radeon_bo *bo)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  if (!boi->bom->funcs->bo_wait)
> @@ -89,27 +90,29 @@ int radeon_bo_wait(struct radeon_bo *bo)
>  return boi->bom->funcs->bo_wait(boi);
>  }
>
> -int radeon_bo_is_busy(struct radeon_bo *bo, uint32_t *domain)
> +drm_public int radeon_bo_is_busy(struct radeon_bo *bo, uint32_t *domain)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  return boi->bom->funcs->bo_is_busy(boi, domain);
>  }
>
> -int radeon_bo_set_tiling(struct radeon_bo *bo,
> - uint32_t tiling_flags, uint32_t pitch)
> +drm_public int
> +radeon_bo_set_tiling(struct radeon_bo *bo,
> + uint32_t tiling_flags, uint32_t pitch)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  return boi->bom->funcs->bo_set_tiling(boi, tiling_flags, pitch);
>  }
>
> -int radeon_bo_get_tiling(struct radeon_bo *bo,
> - uint32_t *tiling_flags, uint32_t *pitch)
> +drm_public int
> +radeon_bo_get_tiling(struct radeon_bo *bo,
> + uint32_t *tiling_flags, uint32_t *pitch)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  return boi->bom->funcs->bo_get_tiling(boi, tiling_flags, pitch);
>  }
>
> -int radeon_bo_is_static(struct radeon_bo *bo)
> +drm_public int radeon_bo_is_static(struct radeon_bo *bo)
>  {
>  struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
>  if (boi->bom->funcs->bo_is_static)
> @@ -117,18 +120,19 @@ int 

[libdrm PATCH 3/3] radeon: Use symbol visibility.

[Maarten Lankhorst]

All the bof_* symbols are now no longer exported.

Signed-off-by: Maarten Lankhorst 
---
 radeon/Makefile.am   |  1 +
 radeon/radeon_bo.c   | 46 
 radeon/radeon_bo_gem.c   | 24 +--
 radeon/radeon_cs.c   | 50 +---
 radeon/radeon_cs_gem.c   |  8 ++--
 radeon/radeon_cs_space.c | 18 +++--
 radeon/radeon_surface.c  | 20 +--
 7 files changed, 98 insertions(+), 69 deletions(-)

diff --git a/radeon/Makefile.am b/radeon/Makefile.am
index a8cd100..c969573 100644
--- a/radeon/Makefile.am
+++ b/radeon/Makefile.am
@@ -24,6 +24,7 @@

 AM_CFLAGS = \
$(WARN_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
-I$(top_srcdir) \
-I$(top_srcdir)/radeon \
$(PTHREADSTUBS_CFLAGS) \
diff --git a/radeon/radeon_bo.c b/radeon/radeon_bo.c
index 6a0f8e7..865e3f7 100644
--- a/radeon/radeon_bo.c
+++ b/radeon/radeon_bo.c
@@ -29,10 +29,14 @@
  *  Dave Airlie
  *  J?r?me Glisse 
  */
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+#include 
 #include 
 #include 

-void radeon_bo_debug(struct radeon_bo *bo, const char *op)
+drm_public void radeon_bo_debug(struct radeon_bo *bo, const char *op)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;

@@ -40,26 +44,23 @@ void radeon_bo_debug(struct radeon_bo *bo, const char *op)
 op, bo, bo->handle, boi->size, boi->cref);
 }

-struct radeon_bo *radeon_bo_open(struct radeon_bo_manager *bom,
- uint32_t handle,
- uint32_t size,
- uint32_t alignment,
- uint32_t domains,
- uint32_t flags)
+drm_public struct radeon_bo *
+radeon_bo_open(struct radeon_bo_manager *bom, uint32_t handle, uint32_t size,
+  uint32_t alignment, uint32_t domains, uint32_t flags)
 {
 struct radeon_bo *bo;
 bo = bom->funcs->bo_open(bom, handle, size, alignment, domains, flags);
 return bo;
 }

-void radeon_bo_ref(struct radeon_bo *bo)
+drm_public void radeon_bo_ref(struct radeon_bo *bo)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 boi->cref++;
 boi->bom->funcs->bo_ref(boi);
 }

-struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
+drm_public struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 if (bo == NULL)
@@ -69,19 +70,19 @@ struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
 return boi->bom->funcs->bo_unref(boi);
 }

-int radeon_bo_map(struct radeon_bo *bo, int write)
+drm_public int radeon_bo_map(struct radeon_bo *bo, int write)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 return boi->bom->funcs->bo_map(boi, write);
 }

-int radeon_bo_unmap(struct radeon_bo *bo)
+drm_public int radeon_bo_unmap(struct radeon_bo *bo)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 return boi->bom->funcs->bo_unmap(boi);
 }

-int radeon_bo_wait(struct radeon_bo *bo)
+drm_public int radeon_bo_wait(struct radeon_bo *bo)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 if (!boi->bom->funcs->bo_wait)
@@ -89,27 +90,29 @@ int radeon_bo_wait(struct radeon_bo *bo)
 return boi->bom->funcs->bo_wait(boi);
 }

-int radeon_bo_is_busy(struct radeon_bo *bo, uint32_t *domain)
+drm_public int radeon_bo_is_busy(struct radeon_bo *bo, uint32_t *domain)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 return boi->bom->funcs->bo_is_busy(boi, domain);
 }

-int radeon_bo_set_tiling(struct radeon_bo *bo,
- uint32_t tiling_flags, uint32_t pitch)
+drm_public int
+radeon_bo_set_tiling(struct radeon_bo *bo,
+ uint32_t tiling_flags, uint32_t pitch)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 return boi->bom->funcs->bo_set_tiling(boi, tiling_flags, pitch);
 }

-int radeon_bo_get_tiling(struct radeon_bo *bo,
- uint32_t *tiling_flags, uint32_t *pitch)
+drm_public int
+radeon_bo_get_tiling(struct radeon_bo *bo,
+ uint32_t *tiling_flags, uint32_t *pitch)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 return boi->bom->funcs->bo_get_tiling(boi, tiling_flags, pitch);
 }

-int radeon_bo_is_static(struct radeon_bo *bo)
+drm_public int radeon_bo_is_static(struct radeon_bo *bo)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 if (boi->bom->funcs->bo_is_static)
@@ -117,18 +120,19 @@ int radeon_bo_is_static(struct radeon_bo *bo)
 return 0;
 }

-int radeon_bo_is_referenced_by_cs(struct radeon_bo *bo, struct radeon_cs *cs)
+drm_public int
+radeon_bo_is_referenced_by_cs(struct radeon_bo *bo, struct radeon_cs *cs)
 {
 struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
 return boi->cref > 1;
 }

-uint32_t radeon_bo_get_handle(struct radeon_bo *bo)

[PATCH 2/3] intel: Use symbol visibility.

[Maarten Lankhorst]

No exports changed for this driver.

Signed-off-by: Maarten Lankhorst 
---
 intel/Makefile.am |  1 +
 intel/intel_bufmgr.c  | 93 ---
 intel/intel_bufmgr_fake.c | 31 
 intel/intel_bufmgr_gem.c  | 53 +++
 intel/intel_decode.c  | 19 ++
 5 files changed, 114 insertions(+), 83 deletions(-)

diff --git a/intel/Makefile.am b/intel/Makefile.am
index f49b099..f734b0b 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -24,6 +24,7 @@

 AM_CFLAGS = \
$(WARN_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
-I$(top_srcdir) \
-I$(top_srcdir)/intel \
$(PTHREADSTUBS_CFLAGS) \
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 905556f..03dba50 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include "libdrm.h"
 #include "intel_bufmgr.h"
 #include "intel_bufmgr_priv.h"
 #include "xf86drm.h"
@@ -46,21 +47,21 @@
  * Convenience functions for buffer management methods.
  */

-drm_intel_bo *drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
-unsigned long size, unsigned int alignment)
+drm_public drm_intel_bo *
+drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
+  unsigned long size, unsigned int alignment)
 {
return bufmgr->bo_alloc(bufmgr, name, size, alignment);
 }

-drm_intel_bo *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
-   const char *name,
-   unsigned long size,
-   unsigned int alignment)
+drm_public drm_intel_bo *
+drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr, const char *name,
+ unsigned long size, unsigned int alignment)
 {
return bufmgr->bo_alloc_for_render(bufmgr, name, size, alignment);
 }

-drm_intel_bo *
+drm_public drm_intel_bo *
 drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
 int x, int y, int cpp, uint32_t *tiling_mode,
 unsigned long *pitch, unsigned long flags)
@@ -69,12 +70,14 @@ drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const 
char *name,
  tiling_mode, pitch, flags);
 }

-void drm_intel_bo_reference(drm_intel_bo *bo)
+drm_public void
+drm_intel_bo_reference(drm_intel_bo *bo)
 {
bo->bufmgr->bo_reference(bo);
 }

-void drm_intel_bo_unreference(drm_intel_bo *bo)
+drm_public void
+drm_intel_bo_unreference(drm_intel_bo *bo)
 {
if (bo == NULL)
return;
@@ -82,24 +85,26 @@ void drm_intel_bo_unreference(drm_intel_bo *bo)
bo->bufmgr->bo_unreference(bo);
 }

-int drm_intel_bo_map(drm_intel_bo *buf, int write_enable)
+drm_public int
+drm_intel_bo_map(drm_intel_bo *buf, int write_enable)
 {
return buf->bufmgr->bo_map(buf, write_enable);
 }

-int drm_intel_bo_unmap(drm_intel_bo *buf)
+drm_public int
+drm_intel_bo_unmap(drm_intel_bo *buf)
 {
return buf->bufmgr->bo_unmap(buf);
 }

-int
+drm_public int
 drm_intel_bo_subdata(drm_intel_bo *bo, unsigned long offset,
 unsigned long size, const void *data)
 {
return bo->bufmgr->bo_subdata(bo, offset, size, data);
 }

-int
+drm_public int
 drm_intel_bo_get_subdata(drm_intel_bo *bo, unsigned long offset,
 unsigned long size, void *data)
 {
@@ -118,24 +123,26 @@ drm_intel_bo_get_subdata(drm_intel_bo *bo, unsigned long 
offset,
return 0;
 }

-void drm_intel_bo_wait_rendering(drm_intel_bo *bo)
+drm_public void
+drm_intel_bo_wait_rendering(drm_intel_bo *bo)
 {
bo->bufmgr->bo_wait_rendering(bo);
 }

-void drm_intel_bufmgr_destroy(drm_intel_bufmgr *bufmgr)
+drm_public void
+drm_intel_bufmgr_destroy(drm_intel_bufmgr *bufmgr)
 {
bufmgr->destroy(bufmgr);
 }

-int
+drm_public int
 drm_intel_bo_exec(drm_intel_bo *bo, int used,
  drm_clip_rect_t * cliprects, int num_cliprects, int DR4)
 {
return bo->bufmgr->bo_exec(bo, used, cliprects, num_cliprects, DR4);
 }

-int
+drm_public int
 drm_intel_bo_mrb_exec(drm_intel_bo *bo, int used,
drm_clip_rect_t *cliprects, int num_cliprects, int DR4,
unsigned int rings)
@@ -155,17 +162,20 @@ drm_intel_bo_mrb_exec(drm_intel_bo *bo, int used,
}
 }

-void drm_intel_bufmgr_set_debug(drm_intel_bufmgr *bufmgr, int enable_debug)
+drm_public void
+drm_intel_bufmgr_set_debug(drm_intel_bufmgr *bufmgr, int enable_debug)
 {
bufmgr->debug = enable_debug;
 }

-int drm_intel_bufmgr_check_aperture_space(drm_intel_bo ** bo_array, int count)
+drm_public int
+drm_intel_bufmgr_check_aperture_space(drm_intel_bo ** bo_array, int count)
 {
return bo_array[0]->bufmgr->check_aperture_space(bo_array, count);
 }

-int drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name)
+drm_public int

[libdrm PATCH 1/3] nouveau: Only export public functions.

[Maarten Lankhorst]

This hides all the abi16_* functions and the nouveau_debug variable,
they should have been private to begin with.

Signed-off-by: Maarten Lankhorst 
---
 nouveau/Makefile.am |  1 +
 nouveau/bufctx.c| 10 +-
 nouveau/nouveau.c   | 40 
 nouveau/private.h   |  1 +
 nouveau/pushbuf.c   | 20 ++--
 5 files changed, 37 insertions(+), 35 deletions(-)

diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index 206e892..73cff9f 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -1,5 +1,6 @@
 AM_CFLAGS = \
$(WARN_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
-I$(top_srcdir) \
-I$(top_srcdir)/nouveau \
$(PTHREADSTUBS_CFLAGS) \
diff --git a/nouveau/bufctx.c b/nouveau/bufctx.c
index 23d6f09..fdd3164 100644
--- a/nouveau/bufctx.c
+++ b/nouveau/bufctx.c
@@ -68,7 +68,7 @@ nouveau_bufctx(struct nouveau_bufctx *bctx)
return (struct nouveau_bufctx_priv *)bctx;
 }

-int
+drm_public int
 nouveau_bufctx_new(struct nouveau_client *client, int bins,
   struct nouveau_bufctx **pbctx)
 {
@@ -88,7 +88,7 @@ nouveau_bufctx_new(struct nouveau_client *client, int bins,
return -ENOMEM;
 }

-void
+drm_public void
 nouveau_bufctx_del(struct nouveau_bufctx **pbctx)
 {
struct nouveau_bufctx_priv *pctx = nouveau_bufctx(*pbctx);
@@ -105,7 +105,7 @@ nouveau_bufctx_del(struct nouveau_bufctx **pbctx)
}
 }

-void
+drm_public void
 nouveau_bufctx_reset(struct nouveau_bufctx *bctx, int bin)
 {
struct nouveau_bufctx_priv *pctx = nouveau_bufctx(bctx);
@@ -123,7 +123,7 @@ nouveau_bufctx_reset(struct nouveau_bufctx *bctx, int bin)
pbin->relocs  = 0;
 }

-struct nouveau_bufref *
+drm_public struct nouveau_bufref *
 nouveau_bufctx_refn(struct nouveau_bufctx *bctx, int bin,
struct nouveau_bo *bo, uint32_t flags)
 {
@@ -150,7 +150,7 @@ nouveau_bufctx_refn(struct nouveau_bufctx *bctx, int bin,
return >base;
 }

-struct nouveau_bufref *
+drm_public struct nouveau_bufref *
 nouveau_bufctx_mthd(struct nouveau_bufctx *bctx, int bin, uint32_t packet,
struct nouveau_bo *bo, uint64_t data, uint32_t flags,
uint32_t vor, uint32_t tor)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 1bede84..43f0d3c 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -62,14 +62,14 @@ debug_init(char *args)
  * is kept here to prevent AIGLX from crashing if the DDX is linked against
  * the new libdrm, but the DRI driver against the old
  */
-int
+drm_public int
 nouveau_device_open_existing(struct nouveau_device **pdev, int close, int fd,
 drm_context_t ctx)
 {
return -EACCES;
 }

-int
+drm_public int
 nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev)
 {
struct nouveau_device_priv *nvdev = calloc(1, sizeof(*nvdev));
@@ -147,7 +147,7 @@ nouveau_device_wrap(int fd, int close, struct 
nouveau_device **pdev)
return 0;
 }

-int
+drm_public int
 nouveau_device_open(const char *busid, struct nouveau_device **pdev)
 {
int ret = -ENODEV, fd = drmOpen("nouveau", busid);
@@ -159,7 +159,7 @@ nouveau_device_open(const char *busid, struct 
nouveau_device **pdev)
return ret;
 }

-void
+drm_public void
 nouveau_device_del(struct nouveau_device **pdev)
 {
struct nouveau_device_priv *nvdev = nouveau_device(*pdev);
@@ -173,7 +173,7 @@ nouveau_device_del(struct nouveau_device **pdev)
}
 }

-int
+drm_public int
 nouveau_getparam(struct nouveau_device *dev, uint64_t param, uint64_t *value)
 {
struct drm_nouveau_getparam r = { param, 0 };
@@ -183,14 +183,14 @@ nouveau_getparam(struct nouveau_device *dev, uint64_t 
param, uint64_t *value)
return ret;
 }

-int
+drm_public int
 nouveau_setparam(struct nouveau_device *dev, uint64_t param, uint64_t value)
 {
struct drm_nouveau_setparam r = { param, value };
return drmCommandWrite(dev->fd, DRM_NOUVEAU_SETPARAM, , sizeof(r));
 }

-int
+drm_public int
 nouveau_client_new(struct nouveau_device *dev, struct nouveau_client **pclient)
 {
struct nouveau_device_priv *nvdev = nouveau_device(dev);
@@ -229,7 +229,7 @@ unlock:
return ret;
 }

-void
+drm_public void
 nouveau_client_del(struct nouveau_client **pclient)
 {
struct nouveau_client_priv *pcli = nouveau_client(*pclient);
@@ -245,7 +245,7 @@ nouveau_client_del(struct nouveau_client **pclient)
}
 }

-int
+drm_public int
 nouveau_object_new(struct nouveau_object *parent, uint64_t handle,
   uint32_t oclass, void *data, uint32_t length,
   struct nouveau_object **pobj)
@@ -307,7 +307,7 @@ nouveau_object_new(struct nouveau_object *parent, uint64_t 
handle,
return 0;
 }

-void
+drm_public void
 nouveau_object_del(struct nouveau_object **pobj)
 {
struct nouveau_object *obj = *pobj;
@@ -331,7 +331,7 @@ nouveau_object_del(struct nouveau_object **pobj)
*pobj 

[Bug 81967] [regression] Selections in Blender renders wrong

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


  
?r??#????1[???]???:?|???k??z?u?g|F5F???V???w?n+?g?e???)?A|?.?~
??G?
??G????(???:a6?75?g?m?">?W?h??_}??oX?}N??(?#?5????Of??f???
l?$>?W#?L??C?6?Hj?$>X#??M|??a???3?_?|?w?O?   
l?&>X?^???E/m??!??/??}??{?+??o@XUt???8?Y??/?????_2\?~???_???O????'?

$?5???/|?~??_??^?K??G??
B??V???~?m?o_Co?~??_?z{?7??pO?%??=?Z???u??:??;?{_~??V??x???o

t????t?|???   
o??}???~??{??}??w^??O;???k?w??9????3d??_??v   
??ka????6?hfitu?k??]??????/??_M?w?   
???E?~G??~?y??_?>??A[????}??I_??????3[3?_?7??|???/?y?7?ps???E?
?g?T???+?????i??_t?P???_tO???i
?7???O???o???/}?m??|??/_???w?i?v???p??
????K???9n??_2p???W?|w)_??>?
d??U???/??I?K?w~???^~??O"??g??
?G??7~?z?B???~??_?iO?
7?t??0?0?N??(?G??v???H?C?b???H?C?bG?C?bG?C?b???H?C??*?j??Q
S!T?T?v??0?GUL
j??QSa*T;j??Q
S??!T?T;??j?
>???*??!T?T?v????!T?T?v????!T?TF?v????!T?TF?v?
??!T?T?H?C??*?j??Q
S!T?T?v?U1???
?G??v?U1?Q?
?G??v?U1?Q?
?G??v?Uq???p?z?N?`???J5
???n?*??G???#?K??O?S???r
>???}'9
}??v0??#cIEND?B`?

-- 
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/20140731/7d9f22e9/attachment-0001.html>

[Bug 81967] New: [regression] Selections in Blender renders wrong

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

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

  Priority: medium
Bug ID: 81967
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [regression] Selections in Blender renders wrong
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: sa at whiz.se
  Hardware: x86 (IA32)
Status: NEW
   Version: 10.2
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 103754
  --> https://bugs.freedesktop.org/attachment.cgi?id=103754=edit
Screenshot of bug

Hi,

Selections in Blender edit mode does not render correctly. See screenshot for
explanation.

Everything is correct if software rendering is used, it seems to be specific to
Gallium as i965 is not affected.

This regressed in an update from 9.2.2 to 10.2.4 so I'll try to bisect when I
have more time.

System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 7.4.0
-- xserver: 1.16.0
-- mesa: 10.2.4
-- drm: 2.4.54
-- kernel: 3.13

-- 
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/20140731/3fef918a/attachment.html>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

On Thu, Jul 31, 2014 at 2:27 PM, Andreas F?rber  wrote:
> Ajay,
>
> Am 31.07.2014 10:38, schrieb Ajay kumar:
>> On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber  wrote:
>>> Am 30.07.2014 08:21, schrieb Ajay kumar:
 On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber  
 wrote:
> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> On 7/27/14, Andreas F?rber  wrote:
>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
 This series is based on exynos-drm-next branch of Inki Dae's tree at:
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

 I have tested this after adding few DT changes for exynos5250-snow,
 exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>
>>> I'm trying to test this with a modified exynos5250-spring DT based off
>>> kgene's for-next branch due to DT, and I run into the following:
>
> Unfortunately the most I got on Spring with attached DT was a blank
> screen with a white horizontal line in the middle.
 Then, I think bridge chip is working fine.
 You just need to configure the proper mode for FIMD.
 You can see backlight also, right?

> Do I need to specify a specific panel model for Spring?
 Yes! Try using "chunghwa,claa101wb01" as compatible string for
 panel node.
>>>
>>> With just your v6 applied plus updated DT patch (attached) [1], I see
>>> backlight and a black screen (no white line any more). dmesg attached.
>> I can see penguin's also!
>
> See below...
>
> For testing I re-applied your iommu patches (which btw fail now for 5420
> due to disp_pd) but didn't know what to do about your panel-lvds
> regulator patch now that it's gone.
 Ignore that regulator patch.

 Also, please attach the bootlog if possible after trying this.
>>>
>>> If I further apply the IOMMU patches [2], I get no backlight nor USB and
>>> thus can't obtain a boot log.
>>>
>>> Regards,
>>> Andreas
>>>
>>> [1] https://github.com/afaerber/linux/commits/spring-next
>
> (I updated the branch meantime, so what I meant was spring-bridge.v6~2)
>
>>> [2] https://github.com/afaerber/linux/commits/spring-bridge.v6
>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>> bootup logo on Skate(a variant of spring which also contains ps8622).
>> I have tried both exynos_defconfig and multi_v7_defconfig.
>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>> in configs.
>>
>> Even in your bootlogs, I can see DP getting probed.
>> And, you say backlight is also visible. That means entire display
>> path should be fine. Its just that you should start writing to the buffer.
>> Have you enabled boot logos?
>
> Let me clarify: U-Boot uses the display [*], so it is powered and I see
> penguins initially. Then, when drm gets initialized, the screen goes
> black and no longer prints kernel messages or systemd output or X11 gdm
> login screen.
>
> Since drm stuff is the only variance here and it works with simplefb,
> surely something prints to some buffer!
Well, I cannot really help you with this.
I think the ui process/X server is getting terminated for some reason.
That might be some issue induced by the platform/drm lib.
This cannot be an issue induced by the bridge chip series, definitely not!
I am able to run modetest, and also able to see random data on display
by doing "cat /dev/urandom > /dev/fb0"

Ajay

[PATCHv2 0/8] Upstreaming the Android build and misc fixes

[Gore, Tim]

Ok, I still had to manually apply some of patch 3/8 as it was corrupted
And would not apply, but after this I was able to build within one of 
My android trees. I have not tested the resulting libraries yet, but the
Overall build process seems ok.

  Tim

> -Original Message-
> From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
> Sent: Tuesday, July 29, 2014 6:27 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Gore, Tim
> Subject: [PATCHv2 0/8] Upstreaming the Android build and misc fixes
> 
> Changes since the orignal posting:
>  - Rebased on top of master.
>  - Used _H_FILES for header lists (_HEADERS is a no-go with autotools)
>  - Install the freedreno headers to {include_dir}/freedreno, similar to the
> automake builds.
>  - Correctly include $(hw)/Android.mk
> 
> The series is also available at the fixes+android-v2 branch in
> https://github.com/evelikov/libdrm.
> 
> -Emil

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #132 from Kai  ---
(In reply to comment #130)
> (In reply to comment #126)
> > (In reply to comment #124)
> > > 
> > > And for the DPM stuff: dpm doesn't seem to work, the numbers never changed
> > > (tested on console without X and Metro Last Light; I dropped my previous
> > > "radeon.dpm=0" from the kernel parameters):
> > > # cat /sys/kernel/debug/dri/64/radeon_pm_info
> > > power level avgsclk: 3 mclk: 15000
> > 
> > You need to print that out while you have a 3D app running.  Those numbers
> > are real-time.  E.g., in the console, there is no 3D acceleration happening
> > so they stay at their low levels.
> 
> I did just that :-) Sorry if I wasn't clear enough on this. Actually what I
> did was starting Metro Last Light and catting over ssh multiple times from
> my laptop (Metro doesn't allow alt-tab). The values never changed at all.
> 
> I chose Metro, because it's the most graphically challenging piece of
> software I have - and should therefore certainly cause a change of values.
> glxgears didn't cause a change as well, but I thought that might be because
> it's too simple.
> 
> Today, to verify, I also tried it with Half Life 2. Same result. (But MSAA
> works now with the libdrm patch, thanks Marek !)
> 
> All of the above still with the "ASIC_ProfilingInfo v3.1" as I got a NULL
> pointer dereference with yesterday's drm-next-3.17-rebased-on-fixes kernel.
> 
> I guess the new kernel to use is "standard" 3.17-wip, as it now contains all
> the Hawaii stuff ?

Just a thought: you had radeon.dpm=0 set for a long time according to some of
your posts. Are you sure you've removed that from your Kernel command line?

I can't tell if the reclocking is working as Marek reported in comment #131
yet. I might have time fireing a game up during the weekend. But should that be
a problem I can just open a new bug. I don't think this possible reclocking
issue should keep this bug open.

> I'm also ok with tracking the remaining issues in separate bugs - do I need
> to close this bug ? (I'd wait till the xf86-video-ati patch is applied).

Yes, that sounds reasonable: the person who commits the DDX patch can close
this bug, because then all pieces should be at least in Git.

> Any requests on which issues should get their own bugs now ? Turning off
> HDMI-0 and Glyphs come to mind ?


The glyph stuff is already tracked in bug 81930. We still need bugs for the
poor performance and crashing the GPU by running Unigine Heaven (you have to
actually reboot, otherwise the screen won't come up again, in fact the screen
is not just black, it loses its signal). And possible other issues I'm not
seeing myself or just have not noticed yet.

-- 
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/20140731/665f3d9c/attachment.html>

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Randy Dunlap]

On 05/12/14 11:04, Randy Dunlap wrote:
> On 05/12/2014 08:54 AM, Daniel Vetter wrote:
>> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
>>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
 On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
>>>
>>> If we decide to go for property documentation inside the source code 
>>> then I
>>> believe we'll have to create our own format, as creating a properties 
>>> table
>>> from kerneldoc information extracted from comments is probably not 
>>> possible.
>>
>> Can comeone pick up the ball here and figure out what needs to be done?
>>
>> The reason why I want a central place for the documentation is to force
>> people to collaborate outside their own sandbox when adding properties.
>> Whether that's docbook or some text file I don't care so much at this
>> point. The fact that it's a central place should mandate that the
>> patches changing it will go through dri-devel and so everyone should se
>> them, and when adding new properties it would make the patch author more
>> likely to look around a bit before adding another slighty incompatible
>> version of the same property. If someone has a better suggestion how to
>> encforce this I'm all ears.
>>
>> Of course this idea can still fail if our esteemed maintainer merges
>> stuff without checking for violations of this policy. Dave, any thoughts
>> on the subject?
>
> Yeah I'm happy to block merging stuff, if we can spot new properties
> when stuff is posted on dri-devel, so much the better,
>
> most drivers still send everything via dri-devel anyways, its only
> really Intel I have to worry about so far,

 I'll enforce that all prop stuff gets cc: dri-devel and that it has
 updates for the prop docs.

> But we should definitely add it to the new driver review checklist as 
> well.
>
> I'm also on the side of this patch is ugly and makes my eyes burn,
> please please get a plan to use something else ASAP, I'm willing to
> merge this but I'm tempted to give it a lifetime of a kernel or two
> before I burn it.

 Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
 find someone to do it for me internally ;-)
 -Daniel

>>>
>>> I certainly have no objections to making kerneldoc suck less.
>>> There was already an attempt to use asciidoc (like git uses) for kernel-doc
>>> (a few years ago, by Sam Ravnborg).  I support(ed) that effort.
>>
>> Hm, do you have pointers to those? My google-fu seems lacking ...
> 
> I googled for /kernel doc asciidoc ravnborg/ and found several hits for them.
> 
>> Ok, let's move this to the top and start discussions. The past few months
>> I've written piles of kerneldoc comments for the DRM DocBook (all pulled
>> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
>> sections are really useful to pull all the actual documentation out of the
>> docbook xml into kerneldoc.
>>
>> But I've also done piles of docs for intel-gpu-tools, which is using
>> gtkdoc. And there are some clear deficiencies:
>>
>> - No markdown for inline coments. Lack of lists and tables is hurting
>>   especially badly. If we add this (and I don't care one iota whether it's
> 
> Yes, I've tried to add lists to kernel-doc notation but have failed so far.
> 
>>   markdown or asciidoc or something else as long as it's readable plain
>>   text in comments) we should be able to move all the existing docbook xml
>>   paragraphs/lists/tables into kerneldoc comments.
>>
>> - Automatic cross-referencing of functions. If you place e.g. function()
>>   or #struct anywhere in a documentation comment gtk-doc automatically
>>   inserts a hyperlink to the relevant documentation page across the entire
>>   project. Really powerful and makes overview sections much more useful
>>   entry points for beginners since they can easily jump back
>>   betweeen the high-level overview and low-level per-function
>>   documentation.
>>
> 
> That's a nice-to-have IMO, but a really nice one.
> 
>> - In a really perfect world it would help if kerneldoc could collect
>>   structure member kerneldoc from per-member comments. Especially for
>>   large structures with lots of comments this would bring the kerneldoc
>>   and struct member much closer together.
>>
>> So that's my wishlist.
>>  
>>> OTOH, I would only want to add another way to do kernel-doc if it can be a
>>> full replacement for all of our docbook usage, i.e., it should provide a
>>> way that we can eliminate docbook and stop using it completely.
>>
>> Hm, I don't mind docbook at all, as long as all the real content is
>> embedded into source files as kerneldoc and the docbook template just
>> pulls in all the right bits and pieces. Even gtkdoc allos you to do that
>> and pull in the different libararies (== header files with declarations
>> for C) in 

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #74 from jackdachef at gmail.com ---
(In reply to comment #71)
> This bug was originally about a stability regression due to some GPUVM
> changes in 3.15.  If 3.14 is stable for you but newer kernels are not, then
> it may be related.  Otherwise, it's probably another issue.  See bug 81644
> about stability issues with Chromium specifically.

unfortunately 3.14 also isn't entirely stable it mostly is (99%) but here the
problem is that very very seldomly X simply crashes, gpu doesn't simply turn
black and recovers, so important data can be lost (when being worked on) -
couldn't pinpoint the reason yet - the gpu just "reboots"

no additional error messages dmesg or Xorg.0.log as far as I know

can't say anything about kernel versions prior to that since this card is still
a few days old


gcc 4.9 also couldn't be the cause, at least with 3.16-rc* kernels and
drm-next-3.17-rebased-on-fixes, since I've already added the patch manually and
the kernel also isn *NOT* compiled with -Os (optimize for size)


it seems to be more of general instability going towards 3.15 and 3.16 - but
who I am to ask, I'm just a enthusiast user :P


having read about stability issues with the new firmware somewhere

how could I test and revert to the old firmware ? would it still work ?

simply removing the PITCAIRN_mc2.bin (e.g. for the R9 270X) and leaving the
other PITCAIRN files in /lib/firmware ?

the graphics driver is loading as a module and not compiled into the kernel or
included in initramfs

I'd really like to upgrade to 3.16-rc* due to recent changes (especially in
connection with Btrfs)

an option to disable UVD entirely would have been nice (when still using 5850
and during the new introduction of DPM there was a patch which offered a module
parameter to turn it manually off) - would that be an option to further
troubleshoot this issue and to exclude UVD from the list of potential causes ?


Thanks

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

[Nouveau] [libdrm PATCH 1/3] nouveau: Only export public functions.

[Emil Velikov]

On 31/07/14 14:44, Maarten Lankhorst wrote:
> This hides all the abi16_* functions and the nouveau_debug variable,
> they should have been private to begin with.
> 
> Signed-off-by: Maarten Lankhorst 
Looks good afaict

Reviewed-by: Emil Velikov 

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #18 from jackdachef at gmail.com ---
so I got a different bug or could this be the same ?

running on drm-next-3.17-rebased-on-fixes

only doing some surfing via current opera-developer
(https://bugs.gentoo.org/show_bug.cgi?id=514696)

flash plugin was not working (tested via surfing over to speedtest.net)

switched a few times between KDE4, fluxbox, xfce4 and razor-qt

window managers were compiz-fusion (0.8.8/0.8.6), kwin with opengl compositing
(opengl 1.2, 2.0, 3.1 testing)


programs used:

- gnote, tomboy
- opera-developer
- firefox (flash rendered unusable by uninstalling vdpau, no data via env
VDPAU_TRACE=1 firefox), noscript, adblock
(these were all if I remember correctly)


first hardlock (no Magic SYSRQ Key recovery possible) was during playing around
and switching between Themes in Opera Developer (version 24)


second hardlock was during simply reading a few notes in gnote and surfing via
firefox (version 31)

-- 
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/20140731/e348a77b/attachment-0001.html>

[PATCH 1/2] drm/radeon: s/ioctl_wait_idle/mmio_hpd_flush/

[Alex Deucher]

On Thu, Jul 31, 2014 at 5:43 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> And clean up the function comment a little.
>
> Signed-off-by: Michel D?nzer 

Applied the series to my 3.17 tree.

Alex

> ---
>  drivers/gpu/drm/radeon/r600.c| 13 +--
>  drivers/gpu/drm/radeon/radeon.h  |  9 ++--
>  drivers/gpu/drm/radeon/radeon_asic.c | 44 
> ++--
>  drivers/gpu/drm/radeon/radeon_asic.h |  2 +-
>  drivers/gpu/drm/radeon/radeon_gem.c  |  6 ++---
>  5 files changed, 34 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index c17ff5d..76e1616 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -4088,16 +4088,15 @@ int r600_debugfs_mc_info_init(struct radeon_device 
> *rdev)
>  }
>
>  /**
> - * r600_ioctl_wait_idle - flush host path cache on wait idle ioctl
> + * r600_mmio_hdp_flush - flush Host Data Path cache via MMIO
>   * rdev: radeon device structure
> - * bo: buffer object struct which userspace is waiting for idle
>   *
> - * Some R6XX/R7XX doesn't seems to take into account HDP flush performed
> - * through ring buffer, this leads to corruption in rendering, see
> - * http://bugzilla.kernel.org/show_bug.cgi?id=15186 to avoid this we
> - * directly perform HDP flush by writing register through MMIO.
> + * Some R6XX/R7XX don't seem to take into account HDP flushes performed
> + * through the ring buffer. This leads to corruption in rendering, see
> + * http://bugzilla.kernel.org/show_bug.cgi?id=15186 . To avoid this, we
> + * directly perform the HDP flush by writing the register through MMIO.
>   */
> -void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo)
> +void r600_mmio_hdp_flush(struct radeon_device *rdev)
>  {
> /* r7xx hw bug.  write to HDP_DEBUG1 followed by fb read
>  * rather than write to HDP_REG_COHERENCY_FLUSH_CNTL.
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 6695b62..4a76e13 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1771,13 +1771,8 @@ struct radeon_asic {
> int (*suspend)(struct radeon_device *rdev);
> void (*vga_set_state)(struct radeon_device *rdev, bool state);
> int (*asic_reset)(struct radeon_device *rdev);
> -   /* ioctl hw specific callback. Some hw might want to perform special
> -* operation on specific ioctl. For instance on wait idle some hw
> -* might want to perform and HDP flush through MMIO as it seems that
> -* some R6XX/R7XX hw doesn't take HDP flush into account if programmed
> -* through ring.
> -*/
> -   void (*ioctl_wait_idle)(struct radeon_device *rdev, struct radeon_bo 
> *bo);
> +   /* Flush the HDP cache via MMIO */
> +   void (*mmio_hdp_flush)(struct radeon_device *rdev);
> /* check if 3D engine is idle */
> bool (*gui_idle)(struct radeon_device *rdev);
> /* wait for mc_idle */
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 34b9aa9..ba8caa7 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -194,7 +194,7 @@ static struct radeon_asic r100_asic = {
> .resume = _resume,
> .vga_set_state = _vga_set_state,
> .asic_reset = _asic_reset,
> -   .ioctl_wait_idle = NULL,
> +   .mmio_hdp_flush = NULL,
> .gui_idle = _gui_idle,
> .mc_wait_for_idle = _mc_wait_for_idle,
> .gart = {
> @@ -260,7 +260,7 @@ static struct radeon_asic r200_asic = {
> .resume = _resume,
> .vga_set_state = _vga_set_state,
> .asic_reset = _asic_reset,
> -   .ioctl_wait_idle = NULL,
> +   .mmio_hdp_flush = NULL,
> .gui_idle = _gui_idle,
> .mc_wait_for_idle = _mc_wait_for_idle,
> .gart = {
> @@ -340,7 +340,7 @@ static struct radeon_asic r300_asic = {
> .resume = _resume,
> .vga_set_state = _vga_set_state,
> .asic_reset = _asic_reset,
> -   .ioctl_wait_idle = NULL,
> +   .mmio_hdp_flush = NULL,
> .gui_idle = _gui_idle,
> .mc_wait_for_idle = _mc_wait_for_idle,
> .gart = {
> @@ -406,7 +406,7 @@ static struct radeon_asic r300_asic_pcie = {
> .resume = _resume,
> .vga_set_state = _vga_set_state,
> .asic_reset = _asic_reset,
> -   .ioctl_wait_idle = NULL,
> +   .mmio_hdp_flush = NULL,
> .gui_idle = _gui_idle,
> .mc_wait_for_idle = _mc_wait_for_idle,
> .gart = {
> @@ -472,7 +472,7 @@ static struct radeon_asic r420_asic = {
> .resume = _resume,
> .vga_set_state = _vga_set_state,
> .asic_reset = _asic_reset,
> -   .ioctl_wait_idle = NULL,
> +   .mmio_hdp_flush = NULL,
> .gui_idle = _gui_idle,
> .mc_wait_for_idle = _mc_wait_for_idle,
> .gart = {
> @@ 

[PATCH] drm/radeon: separate ring and IB handling

[Alex Deucher]

On Thu, Jul 31, 2014 at 7:44 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> Both on their own are complex enough.
>
> Signed-off-by: Christian K?nig 

Applied to my 3.17 tree.

Alex

> ---
>  drivers/gpu/drm/radeon/Makefile  |   2 +-
>  drivers/gpu/drm/radeon/radeon_ib.c   | 319 
> +++
>  drivers/gpu/drm/radeon/radeon_ring.c | 287 ---
>  3 files changed, 320 insertions(+), 288 deletions(-)
>  create mode 100644 drivers/gpu/drm/radeon/radeon_ib.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 1b04002..0013ad0 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
> rv740_dpm.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
> trinity_dpm.o \
> trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> -   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o
> +   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o
>
>  # add async DMA block
>  radeon-y += \
> diff --git a/drivers/gpu/drm/radeon/radeon_ib.c 
> b/drivers/gpu/drm/radeon/radeon_ib.c
> new file mode 100644
> index 000..65b0c21
> --- /dev/null
> +++ b/drivers/gpu/drm/radeon/radeon_ib.c
> @@ -0,0 +1,319 @@
> +/*
> + * Copyright 2008 Advanced Micro Devices, Inc.
> + * Copyright 2008 Red Hat Inc.
> + * Copyright 2009 Jerome Glisse.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: Dave Airlie
> + *  Alex Deucher
> + *  Jerome Glisse
> + *  Christian K?nig
> + */
> +#include 
> +#include "radeon.h"
> +
> +/*
> + * IB
> + * IBs (Indirect Buffers) and areas of GPU accessible memory where
> + * commands are stored.  You can put a pointer to the IB in the
> + * command ring and the hw will fetch the commands from the IB
> + * and execute them.  Generally userspace acceleration drivers
> + * produce command buffers which are send to the kernel and
> + * put in IBs for execution by the requested ring.
> + */
> +static int radeon_debugfs_sa_init(struct radeon_device *rdev);
> +
> +/**
> + * radeon_ib_get - request an IB (Indirect Buffer)
> + *
> + * @rdev: radeon_device pointer
> + * @ring: ring index the IB is associated with
> + * @ib: IB object returned
> + * @size: requested IB size
> + *
> + * Request an IB (all asics).  IBs are allocated using the
> + * suballocator.
> + * Returns 0 on success, error on failure.
> + */
> +int radeon_ib_get(struct radeon_device *rdev, int ring,
> + struct radeon_ib *ib, struct radeon_vm *vm,
> + unsigned size)
> +{
> +   int r;
> +
> +   r = radeon_sa_bo_new(rdev, >ring_tmp_bo, >sa_bo, size, 256);
> +   if (r) {
> +   dev_err(rdev->dev, "failed to get a new IB (%d)\n", r);
> +   return r;
> +   }
> +
> +   r = radeon_semaphore_create(rdev, >semaphore);
> +   if (r) {
> +   return r;
> +   }
> +
> +   ib->ring = ring;
> +   ib->fence = NULL;
> +   ib->ptr = radeon_sa_bo_cpu_addr(ib->sa_bo);
> +   ib->vm = vm;
> +   if (vm) {
> +   /* ib pool is bound at RADEON_VA_IB_OFFSET in virtual address
> +* space and soffset is the offset inside the pool bo
> +*/
> +   ib->gpu_addr = ib->sa_bo->soffset + RADEON_VA_IB_OFFSET;
> +   } else {
> +   ib->gpu_addr = radeon_sa_bo_gpu_addr(ib->sa_bo);
> +   }
> +   ib->is_const_ib = false;
> +
> +   return 0;
> +}
> +
> +/**
> + * radeon_ib_free - free an IB (Indirect Buffer)
> + *
> + * @rdev: radeon_device pointer
> + * @ib: IB object to free
> + *
> + * Free an IB (all asics).
> + */
> +void radeon_ib_free(struct radeon_device 

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Andreas,

On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber  wrote:
> Hi Ajay,
>
> Am 30.07.2014 08:21, schrieb Ajay kumar:
>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber  wrote:
>>> Am 28.07.2014 08:13, schrieb Ajay kumar:
 On 7/27/14, Andreas F?rber  wrote:
> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> I have tested this after adding few DT changes for exynos5250-snow,
>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>
> I'm trying to test this with a modified exynos5250-spring DT based off
> kgene's for-next branch due to DT, and I run into the following:
>>>
>>> Unfortunately the most I got on Spring with attached DT was a blank
>>> screen with a white horizontal line in the middle.
>> Then, I think bridge chip is working fine.
>> You just need to configure the proper mode for FIMD.
>> You can see backlight also, right?
>>
>>> Do I need to specify a specific panel model for Spring?
>> Yes! Try using "chunghwa,claa101wb01" as compatible string for
>> panel node.
>
> With just your v6 applied plus updated DT patch (attached) [1], I see
> backlight and a black screen (no white line any more). dmesg attached.
I can see penguin's also!

>>> For testing I re-applied your iommu patches (which btw fail now for 5420
>>> due to disp_pd) but didn't know what to do about your panel-lvds
>>> regulator patch now that it's gone.
>> Ignore that regulator patch.
>>
>> Also, please attach the bootlog if possible after trying this.
>
> If I further apply the IOMMU patches [2], I get no backlight nor USB and
> thus can't obtain a boot log.
>
> Regards,
> Andreas
>
> [1] https://github.com/afaerber/linux/commits/spring-next
> [2] https://github.com/afaerber/linux/commits/spring-bridge.v6
With just the spring-bridge.v6 branch of your own tree, I am able to see
bootup logo on Skate(a variant of spring which also contains ps8622).
I have tried both exynos_defconfig and multi_v7_defconfig.
I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
in configs.

Even in your bootlogs, I can see DP getting probed.
And, you say backlight is also visible. That means entire display
path should be fine. Its just that you should start writing to the buffer.
Have you enabled boot logos?

Ajay
> P.S. Note that your Snow DT patch will conflict with my Snow cleanups,
> shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH] drm/radeon: separate ring and IB handling

[Christian König]

From: Christian K?nig 

Both on their own are complex enough.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/Makefile  |   2 +-
 drivers/gpu/drm/radeon/radeon_ib.c   | 319 +++
 drivers/gpu/drm/radeon/radeon_ring.c | 287 ---
 3 files changed, 320 insertions(+), 288 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_ib.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 1b04002..0013ad0 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
-   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o
+   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o

 # add async DMA block
 radeon-y += \
diff --git a/drivers/gpu/drm/radeon/radeon_ib.c 
b/drivers/gpu/drm/radeon/radeon_ib.c
new file mode 100644
index 000..65b0c21
--- /dev/null
+++ b/drivers/gpu/drm/radeon/radeon_ib.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright 2008 Advanced Micro Devices, Inc.
+ * Copyright 2008 Red Hat Inc.
+ * Copyright 2009 Jerome Glisse.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Dave Airlie
+ *  Alex Deucher
+ *  Jerome Glisse
+ *  Christian K?nig
+ */
+#include 
+#include "radeon.h"
+
+/*
+ * IB
+ * IBs (Indirect Buffers) and areas of GPU accessible memory where
+ * commands are stored.  You can put a pointer to the IB in the
+ * command ring and the hw will fetch the commands from the IB
+ * and execute them.  Generally userspace acceleration drivers
+ * produce command buffers which are send to the kernel and
+ * put in IBs for execution by the requested ring.
+ */
+static int radeon_debugfs_sa_init(struct radeon_device *rdev);
+
+/**
+ * radeon_ib_get - request an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index the IB is associated with
+ * @ib: IB object returned
+ * @size: requested IB size
+ *
+ * Request an IB (all asics).  IBs are allocated using the
+ * suballocator.
+ * Returns 0 on success, error on failure.
+ */
+int radeon_ib_get(struct radeon_device *rdev, int ring,
+ struct radeon_ib *ib, struct radeon_vm *vm,
+ unsigned size)
+{
+   int r;
+
+   r = radeon_sa_bo_new(rdev, >ring_tmp_bo, >sa_bo, size, 256);
+   if (r) {
+   dev_err(rdev->dev, "failed to get a new IB (%d)\n", r);
+   return r;
+   }
+
+   r = radeon_semaphore_create(rdev, >semaphore);
+   if (r) {
+   return r;
+   }
+
+   ib->ring = ring;
+   ib->fence = NULL;
+   ib->ptr = radeon_sa_bo_cpu_addr(ib->sa_bo);
+   ib->vm = vm;
+   if (vm) {
+   /* ib pool is bound at RADEON_VA_IB_OFFSET in virtual address
+* space and soffset is the offset inside the pool bo
+*/
+   ib->gpu_addr = ib->sa_bo->soffset + RADEON_VA_IB_OFFSET;
+   } else {
+   ib->gpu_addr = radeon_sa_bo_gpu_addr(ib->sa_bo);
+   }
+   ib->is_const_ib = false;
+
+   return 0;
+}
+
+/**
+ * radeon_ib_free - free an IB (Indirect Buffer)
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to free
+ *
+ * Free an IB (all asics).
+ */
+void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib *ib)
+{
+   radeon_semaphore_free(rdev, >semaphore, ib->fence);
+   radeon_sa_bo_free(rdev, >sa_bo, ib->fence);
+   radeon_fence_unref(>fence);
+}
+
+/**
+ * radeon_ib_schedule - schedule an IB (Indirect Buffer) on the ring
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB object to schedule
+ * 

[PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge

[Thierry Reding]

On Wed, Jul 30, 2014 at 09:44:32PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 9:10 PM, Thierry Reding
>  wrote:
> > On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
> >> On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding  >> gmail.com> wrote:
> >> > On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
> > [...]
> >> >> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
> >> >> +{
> >> >> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> >> >> + int ret;
> >> >> +
> >> >> + /* bridge is attached to encoder.
> >> >> +  * safe to remove it from the bridge_lookup table.
> >> >> +  */
> >> >> + drm_bridge_remove_from_lookup(bridge);
> >> >
> >> > No, you should never do this. First, you're not adding it back to the
> >> > registry when the bridge is detached, so unloading and reloading the
> >> > display driver will fail. Second there should never be a need to remove
> >> > it from the registry as long as the driver itself is loaded. If you're
> >> > concerned about a single bridge being used multiple times, there's
> >> > already code to handle that in your previous patch:
> >> >
> >> > int drm_bridge_attach_encoder(...)
> >> > {
> >> > ...
> >> >
> >> > if (bridge->encoder)
> >> > return -EBUSY;
> >> >
> >> > ...
> >> > }
> >> >
> >> > Generally the registry should contain a list of bridges that have been
> >> > registered, whether they're used or not is irrelevant.
> >> I was just wondering if it is ok to have a node in two independent lists?
> >> bridge_lookup_table and the other mode_config.bridge_list?
> >
> > Oh, it reuses the head field for the registry. I hadn't noticed before.
> > No, you certainly can't have the same node in two lists. Honestly I
> > don't quite understand why there was a need to expose drm_bridge as a
> > drm_mode_object in the first place since it's never exported to
> > userspace.
> >
> > So I think that perhaps we could simply get rid of the base field and
> > not tie in drm_bridge objects with the DRM object as we currently do.
> > But until Sean or Rob comment on this it might be better to simply add
> > another struct list_head field for the registry. That way both can
> > coexist and we can independently still decide to remove the base and
> > head fields if they're no longer needed.
> Ok. What shall I name the new list_head?

"list" would be a good choice in my opinion.

> > .get_modes() still needs to be done from the bridge because that is the
> > most closely connected to the display controller and therefore dictates
> > the timing that the display controller needs to generate.
> >
> > Querying the panel's .get_modes() might be useful to figure out which
> > emulation mode to use in the bridge.
> But, get_modes from panel returns me only the no_of_modes but
> not the actual mode structure. How do I compare the list of supported
> emulation modes?

You could iterate over the connector's probed_modes list which should
contain all the modes that the panel reported (after .get_modes() was
called).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/4e25edb4/attachment.sig>

[RFC PATCH] drm/mipi-dsi: add some generic functions for DCS

[YoungJun Cho]

This patch adds some generic functions for DCS like below
to standize on common APIs rather than per-driver
implementations.

mipi_dcs_enter_sleep_mode() / mipi_dcs_exit_sleep_mode()
- These are required to disable / enable all blocks inside
  the display module.

mipi_dcs_set_display_off() / mipi_dcs_set_display_on()
- These are required to stop / start displaying the image
  data on the display device.

mipi_dcs_set_tear_off() / mipi_dcs_set_tear_on()
- These are required to turn off or on the display module's
  TE output signal on the TE signal line.

mipi_dsi_set_maximum_return_packet_size()
- Although it is not related with DCS, it is required before
  using mipi_dsi_dcs_read() to specify the maximum size of
  the payload in a long packet.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 113 +
 include/drm/drm_mipi_dsi.h |  14 +
 2 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 6b2bbda..ba506d7 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -269,6 +269,119 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, 
unsigned int channel,
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_read);

+/**
+ * mipi_dsi_set_maximum_return_packet_size
+ * - specify the maximum size of the payload in a Long packet transmitted from
+ *   peripheral back to the host processor
+ * @dsi: DSI peripheral device
+ * @size: the maximum size of the payload
+ */
+int mipi_dsi_set_maximum_return_packet_size(struct mipi_dsi_device *dsi,
+   u16 size)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+   struct mipi_dsi_msg msg;
+
+   if (!ops || !ops->transfer)
+   return -ENOSYS;
+
+   memset(, 0, sizeof(msg));
+   msg.channel = dsi->channel;
+   msg.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE;
+   msg.tx_len = sizeof(size);
+   msg.tx_buf = (const void *)();
+
+   return ops->transfer(dsi->host, );
+}
+EXPORT_SYMBOL(mipi_dsi_set_maximum_return_packet_size);
+
+/**
+ * mipi_dcs_enter_sleep_mode - disable all unnecessary blocks inside the 
display
+ * module except interface communication
+ * @dsi: DSI peripheral device
+ */
+int mipi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi)
+{
+   u8 data = MIPI_DCS_ENTER_SLEEP_MODE;
+
+   return mipi_dsi_dcs_write(dsi, dsi->channel, (const void *),
+   sizeof(data));
+}
+EXPORT_SYMBOL(mipi_dcs_enter_sleep_mode);
+
+/**
+ * mipi_dcs_exit_sleep_mode - enable all blocks inside the display module
+ * @dsi: DSI peripheral device
+ */
+int mipi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi)
+{
+   u8 data = MIPI_DCS_EXIT_SLEEP_MODE;
+
+   return mipi_dsi_dcs_write(dsi, dsi->channel, (const void *),
+   sizeof(data));
+}
+EXPORT_SYMBOL(mipi_dcs_exit_sleep_mode);
+
+/**
+ * mipi_dcs_set_display_off - stop displaying the image data on the display 
device
+ * @dsi: DSI peripheral device
+ */
+int mipi_dcs_set_display_off(struct mipi_dsi_device *dsi)
+{
+   u8 data = MIPI_DCS_SET_DISPLAY_OFF;
+
+   return mipi_dsi_dcs_write(dsi, dsi->channel, (const void *),
+   sizeof(data));
+}
+EXPORT_SYMBOL(mipi_dcs_set_display_off);
+
+/**
+ * mipi_dcs_set_display_on - start displaying the image data on the display 
device
+ * @dsi: DSI peripheral device
+ */
+int mipi_dcs_set_display_on(struct mipi_dsi_device *dsi)
+{
+   u8 data = MIPI_DCS_SET_DISPLAY_ON;
+
+   return mipi_dsi_dcs_write(dsi, dsi->channel, (const void *),
+   sizeof(data));
+}
+EXPORT_SYMBOL(mipi_dcs_set_display_on);
+
+/**
+ * mipi_dcs_set_tear_off - turn off the display module's Tearing Effect output
+ * signal on the TE signal line
+ * @dsi: DSI peripheral device
+ */
+int mipi_dcs_set_tear_off(struct mipi_dsi_device *dsi)
+{
+   u8 data = MIPI_DCS_SET_TEAR_OFF;
+
+   return mipi_dsi_dcs_write(dsi, dsi->channel, (const void *),
+   sizeof(data));
+}
+EXPORT_SYMBOL(mipi_dcs_set_tear_off);
+
+/**
+ * mipi_dcs_set_tear_on - turn on the display module's Tearing Effect output
+ *signal on the TE signal line.
+ * @dsi: DSI peripheral device
+ * @mode: the Tearing Effect output line mode
+ *  - MIPI_DCS_TEAR_MODE_VBLANK: the TE output line consists of V-Blanking
+ *   information only
+ *  - MIPI_DCS_TEAR_MODE_VHBLANK : the TE output line consists of both
+ * V-Blanking and H-Blanking information
+ */
+int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
+   enum mipi_dcs_tear_mode mode)
+{
+   u8 data[2] = { MIPI_DCS_SET_TEAR_ON, mode };
+
+   return 

[PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Thierry Reding]

>> Without the polled flag, I get display very late.
> >> Please throw some light on this!
> >
> > I just don't understand why it's necessary to implement this field in
> > the drm_bridge. Every bridge driver will already implement a connector,
> > in which case it can simply set the connector's .polled field, can't it?
> >
> > It seems like the only reason you have it in drm_bridge is so that the
> > encoder driver can set it. But I don't see why it should be doing that.
> > The polled state is a property of the connector, and the encoder driver
> > doesn't know anything about it. So if the bridge has a way to detect HPD
> > then it should be setting up the connector to properly report it. For
> > example if the bridge has an input pin to detect it, then it could use a
> > GPIO to receive interrupts and call drm_helper_hpd_irq_event() in the
> > interrupt handler.
> Hmm. Are we allowed to call drm_helper_hpd_irq_event() the way
> DSI panels use it? Like the last step in panel probe?
> For bridges, it will be in post_encoder_init!

drm_helper_hpd_irq_event() should only be called when a hotplug event is
detected. For all other cases detection should already happen when DRM
initializes.

I see that on Tegra we call drm_helper_hpd_irq_event() in the DSI host's
->attach(), but I don't remember why that's there and I don't see why it
would be necessary either. I'll try to remove it and see if things still
work without.

> > Perhaps you can explain the exact setup where you need this (or point me
> > at the code since I can't seem to find the relevant location) so that I
> > can gain a better understanding.
> 
> I can see bridge getting detected only when I set polled member of
> bridge connector to DRM_CONNECTOR_POLL_HPD, because exynos_drm
> also calls drm_helper_hpd_irq_event() to force detect all connectors at the
> end of drm_load.

That shouldn't be necessary. DRM automatically force detects all outputs
(at least if you use drm_helper_probe_single_connector_modes(), which
seems to be the case for Exynos).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/be6cb5cc/attachment-0001.sig>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Am 31.07.2014 12:23, schrieb Thierry Reding:
> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
>> Am 31.07.2014 10:38, schrieb Ajay kumar:
> [...]
>>> With just the spring-bridge.v6 branch of your own tree, I am able to see
>>> bootup logo on Skate(a variant of spring which also contains ps8622).
>>> I have tried both exynos_defconfig and multi_v7_defconfig.
>>> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
>>> in configs.
>>>
>>> Even in your bootlogs, I can see DP getting probed.
>>> And, you say backlight is also visible. That means entire display
>>> path should be fine. Its just that you should start writing to the buffer.
>>> Have you enabled boot logos?
>>
>> Let me clarify: U-Boot uses the display [*], so it is powered and I see
>> penguins initially. Then, when drm gets initialized, the screen goes
>> black and no longer prints kernel messages or systemd output or X11 gdm
>> login screen.
> 
> Who's displaying the penguins? If you're referring to the Linux boot
> logo then it shouldn't be displayed at all until after DRM has been
> initialized (and the framebuffer console been set up).

Yes, I'm referring to the default boot logo, but before the boot
messages (console=tty1) indicate that [drm] driver is being initialized.

>> Since drm stuff is the only variance here and it works with simplefb,
>> surely something prints to some buffer!
> 
> If you have something like simplefb enabled in addition to a DRM driver,
> then perhaps the DRM driver isn't properly taking over the framebuffer
> console.

Okay, that's worth a try. Around v4 of this series it was not a problem.

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/1dede008/attachment-0001.sig>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Thierry Reding]

On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote:
> Am 31.07.2014 10:38, schrieb Ajay kumar:
[...]
> > With just the spring-bridge.v6 branch of your own tree, I am able to see
> > bootup logo on Skate(a variant of spring which also contains ps8622).
> > I have tried both exynos_defconfig and multi_v7_defconfig.
> > I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
> > in configs.
> > 
> > Even in your bootlogs, I can see DP getting probed.
> > And, you say backlight is also visible. That means entire display
> > path should be fine. Its just that you should start writing to the buffer.
> > Have you enabled boot logos?
> 
> Let me clarify: U-Boot uses the display [*], so it is powered and I see
> penguins initially. Then, when drm gets initialized, the screen goes
> black and no longer prints kernel messages or systemd output or X11 gdm
> login screen.

Who's displaying the penguins? If you're referring to the Linux boot
logo then it shouldn't be displayed at all until after DRM has been
initialized (and the framebuffer console been set up).

> Since drm stuff is the only variance here and it works with simplefb,
> surely something prints to some buffer!

If you have something like simplefb enabled in addition to a DRM driver,
then perhaps the DRM driver isn't properly taking over the framebuffer
console.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/304a7d2c/attachment.sig>

[PATCH 2/2] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffers

[Christian König]

Am 31.07.2014 um 11:57 schrieb Michel D?nzer:
> On 31.07.2014 18:52, Christian K?nig wrote:
>> Am 31.07.2014 um 11:43 schrieb Michel D?nzer:
>>> From: Michel D?nzer 
>>>
>>> Signed-off-by: Michel D?nzer 
>> At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are
>> used by VDPAU to read back to data to a CPU buffer and that's really
>> slow from VRAM.
>  From src/gallium/docs/source/screen.rst:
>
> * ``PIPE_USAGE_DEFAULT``: Optimized for fast GPU access.
> * ``PIPE_USAGE_IMMUTABLE``: Optimized for fast GPU access and the resource is
>not expected to be mapped or changed (even by the GPU) after the first 
> upload.
> * ``PIPE_USAGE_DYNAMIC``: Expect frequent write-only CPU access. What is
>uploaded is expected to be used at least several times by the GPU.
> * ``PIPE_USAGE_STREAM``: Expect frequent write-only CPU access. What is
>uploaded is expected to be used only once by the GPU.
> * ``PIPE_USAGE_STAGING``: Optimized for fast CPU access.
>
> That reads to me like only PIPE_USAGE_STAGING is expected to provide fast
> CPU reads.

Forget what I've wrote, we do this handling by letting the driver copy 
the bitmap content to a staging texture. All other use case indeed use 
PIPE_USAGE_STAGING.

Christian.

[PATCH 2/2] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffers

[Christian König]

Am 31.07.2014 um 11:43 schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> Signed-off-by: Michel D?nzer 

At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are 
used by VDPAU to read back to data to a CPU buffer and that's really 
slow from VRAM.

Christian.

> ---
>   src/gallium/drivers/radeon/r600_buffer_common.c | 15 +++
>   1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index 154c33d..d747cbc 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -110,14 +110,21 @@ bool r600_init_resource(struct r600_common_screen 
> *rscreen,
>   enum radeon_bo_flag flags = 0;
>   
>   switch (res->b.b.usage) {
> - case PIPE_USAGE_DYNAMIC:
> - case PIPE_USAGE_STREAM:
> - flags = RADEON_FLAG_GTT_WC;
> - /* fall through */
>   case PIPE_USAGE_STAGING:
>   /* Transfers are likely to occur more often with these 
> resources. */
>   res->domains = RADEON_DOMAIN_GTT;
>   break;
> + case PIPE_USAGE_STREAM:
> + case PIPE_USAGE_DYNAMIC:
> + /* Older kernels didn't always flush the HDP cache before
> +  * CS execution
> +  */
> + if (rscreen->info.drm_minor < 40) {
> + res->domains = RADEON_DOMAIN_GTT;
> + flags = RADEON_FLAG_GTT_WC;
> + break;
> + }
> + /* fall through */
>   case PIPE_USAGE_DEFAULT:
>   case PIPE_USAGE_IMMUTABLE:
>   default:

[Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function

[Daniel Vetter]

On Thu, Jul 31, 2014 at 10:56 AM, Michel D?nzer  wrote:
> On 31.07.2014 16:54, Daniel Vetter wrote:
>> On Thu, Jul 31, 2014 at 3:14 AM, Michel D?nzer  wrote:
>>> I think it would be better to refactor drm_wait_vblank() than to
>>> reinvent it.
>>
>> That's the ioctl implementation which spends most of its time decoding
>> ioctl structures. If we take that out then there's about half a line
>> which would be shared (since a lot of the stuff in there is ums gunk
>> that we don't want to carry over to a kms-only internal interface). So
>> imo that doesn't make sense.
>
> I'm referring to the core logic of waiting for a number of vblank
> periods or until the vblank period with a given sequence number, dealing
> with wraparound etc. The issues you guys were discussing for a new
> function were ironed out there long ago.

I'm referering to the same, but that logic is gunked up with
special-cases for UMS and absolute vblank waits and all kinds of other
stuff, so that sharing this with a kms helper to wait a few vblanks
(so relative only) really doesn't buy us all that much. Actually I
think you'll be left with nothing shared since for the kms
driver-internal functions really shouldn't have all these hacks to
paper over races and other issues (like ums shutting down the pipe
while we didn't look).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #73 from darkbasic  ---
Alex I didn't use vdpau when playing back, also I got an X freeze even without
playing back anything: I was just starting Android Studio, PyCharm and Netbeans
(I often get freezes when starting these editors).

-- 
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/20140731/f0e0cd95/attachment.html>

[PATCH] drm/msm/hdmi: enable lpm-mux if it is present

[Rob Clark]

On Thu, Jul 31, 2014 at 10:46 AM, Stephane Viau  wrote:
> From: Beeresh Gopal 
>
> lpm-mux is programmed to enable HDMI connector
> on the docking station for S805 chipset based
> devices.
>
> Signed-off-by: Beeresh Gopal 

other than the issues Andreas mentioned, it looks good, so with those addressed:

Reviewed-by: Rob Clark 


> ---
>  drivers/gpu/drm/msm/hdmi/hdmi.c   |  1 +
>  drivers/gpu/drm/msm/hdmi/hdmi.h   |  1 +
>  drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 24 +++-
>  3 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
> index bb1f696..f2c92e6 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
> @@ -453,6 +453,7 @@ static int hdmi_bind(struct device *dev, struct device 
> *master, void *data)
> config.hpd_gpio  = get_gpio("qcom,hdmi-tx-hpd");
> config.mux_en_gpio   = get_gpio("qcom,hdmi-tx-mux-en");
> config.mux_sel_gpio  = get_gpio("qcom,hdmi-tx-mux-sel");
> +   config.mux_lpm_gpio  = get_gpio("qcom,hdmi-tx-mux-lpm");
> config.shared_irq= true;
>
>  #else
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
> index 0a077b0..323ceb7 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi.h
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
> @@ -103,6 +103,7 @@ struct hdmi_platform_config {
>
> /* gpio's: */
> int ddc_clk_gpio, ddc_data_gpio, hpd_gpio, mux_en_gpio, mux_sel_gpio;
> +   int mux_lpm_gpio;
>
> /* older devices had their own irq, mdp5+ it is shared w/ mdp: */
> bool shared_irq;
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
> b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> index 93d1551..1301d03 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
> @@ -63,7 +63,8 @@ static int gpio_config(struct hdmi *hdmi, bool on)
> ret = gpio_request(config->mux_en_gpio, 
> "HDMI_MUX_EN");
> if (ret) {
> dev_err(dev->dev, "'%s'(%d) gpio_request 
> failed: %d\n",
> -   "HDMI_MUX_SEL", config->mux_en_gpio, 
> ret);
> +   "HDMI_MUX_EN",
> +   config->mux_en_gpio, ret);
> goto error4;
> }
> gpio_set_value_cansleep(config->mux_en_gpio, 1);
> @@ -78,6 +79,19 @@ static int gpio_config(struct hdmi *hdmi, bool on)
> }
> gpio_set_value_cansleep(config->mux_sel_gpio, 0);
> }
> +
> +   if (config->mux_lpm_gpio != -1) {
> +   ret = gpio_request(config->mux_lpm_gpio,
> +   "HDMI_MUX_LPM");
> +   if (ret) {
> +   dev_err(dev->dev,
> +   "'%s'(%d) gpio_request failed: %d\n",
> +   "HDMI_MUX_LPM",
> +   config->mux_lpm_gpio, ret);
> +   goto error6;
> +   }
> +   gpio_set_value_cansleep(config->mux_lpm_gpio, 1);
> +   }
> DBG("gpio on");
> } else {
> gpio_free(config->ddc_clk_gpio);
> @@ -93,11 +107,19 @@ static int gpio_config(struct hdmi *hdmi, bool on)
> gpio_set_value_cansleep(config->mux_sel_gpio, 1);
> gpio_free(config->mux_sel_gpio);
> }
> +
> +   if (config->mux_lpm_gpio != -1) {
> +   gpio_set_value_cansleep(config->mux_lpm_gpio, 0);
> +   gpio_free(config->mux_lpm_gpio);
> +   }
> DBG("gpio off");
> }
>
> return 0;
>
> +error6:
> +   if (config->mux_sel_gpio != -1)
> +   gpio_free(config->mux_sel_gpio);
>  error5:
> if (config->mux_en_gpio != -1)
> gpio_free(config->mux_en_gpio);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Ajay,

Am 31.07.2014 10:38, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber  wrote:
>> Am 30.07.2014 08:21, schrieb Ajay kumar:
>>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber  wrote:
 Am 28.07.2014 08:13, schrieb Ajay kumar:
> On 7/27/14, Andreas F?rber  wrote:
>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have tested this after adding few DT changes for exynos5250-snow,
>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>
>> I'm trying to test this with a modified exynos5250-spring DT based off
>> kgene's for-next branch due to DT, and I run into the following:

 Unfortunately the most I got on Spring with attached DT was a blank
 screen with a white horizontal line in the middle.
>>> Then, I think bridge chip is working fine.
>>> You just need to configure the proper mode for FIMD.
>>> You can see backlight also, right?
>>>
 Do I need to specify a specific panel model for Spring?
>>> Yes! Try using "chunghwa,claa101wb01" as compatible string for
>>> panel node.
>>
>> With just your v6 applied plus updated DT patch (attached) [1], I see
>> backlight and a black screen (no white line any more). dmesg attached.
> I can see penguin's also!

See below...

 For testing I re-applied your iommu patches (which btw fail now for 5420
 due to disp_pd) but didn't know what to do about your panel-lvds
 regulator patch now that it's gone.
>>> Ignore that regulator patch.
>>>
>>> Also, please attach the bootlog if possible after trying this.
>>
>> If I further apply the IOMMU patches [2], I get no backlight nor USB and
>> thus can't obtain a boot log.
>>
>> Regards,
>> Andreas
>>
>> [1] https://github.com/afaerber/linux/commits/spring-next

(I updated the branch meantime, so what I meant was spring-bridge.v6~2)

>> [2] https://github.com/afaerber/linux/commits/spring-bridge.v6
> With just the spring-bridge.v6 branch of your own tree, I am able to see
> bootup logo on Skate(a variant of spring which also contains ps8622).
> I have tried both exynos_defconfig and multi_v7_defconfig.
> I enable DRM, EXYNOS DRM, BRIDGE CHIPS, IOMMU, EXYNOS IOMMU
> in configs.
> 
> Even in your bootlogs, I can see DP getting probed.
> And, you say backlight is also visible. That means entire display
> path should be fine. Its just that you should start writing to the buffer.
> Have you enabled boot logos?

Let me clarify: U-Boot uses the display [*], so it is powered and I see
penguins initially. Then, when drm gets initialized, the screen goes
black and no longer prints kernel messages or systemd output or X11 gdm
login screen.

Since drm stuff is the only variance here and it works with simplefb,
surely something prints to some buffer!

Andreas

[*] https://github.com/afaerber/u-boot/commits/spring

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH] drm/msm/hdmi: enable lpm-mux if it is present

[Stephane Viau]

From: Beeresh Gopal 

lpm-mux is programmed to enable HDMI connector
on the docking station for S805 chipset based
devices.

Signed-off-by: Beeresh Gopal 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c   |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi.h   |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 24 +++-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index bb1f696..f2c92e6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -453,6 +453,7 @@ static int hdmi_bind(struct device *dev, struct device 
*master, void *data)
config.hpd_gpio  = get_gpio("qcom,hdmi-tx-hpd");
config.mux_en_gpio   = get_gpio("qcom,hdmi-tx-mux-en");
config.mux_sel_gpio  = get_gpio("qcom,hdmi-tx-mux-sel");
+   config.mux_lpm_gpio  = get_gpio("qcom,hdmi-tx-mux-lpm");
config.shared_irq= true;

 #else
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 0a077b0..323ceb7 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -103,6 +103,7 @@ struct hdmi_platform_config {

/* gpio's: */
int ddc_clk_gpio, ddc_data_gpio, hpd_gpio, mux_en_gpio, mux_sel_gpio;
+   int mux_lpm_gpio;

/* older devices had their own irq, mdp5+ it is shared w/ mdp: */
bool shared_irq;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index 93d1551..1301d03 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -63,7 +63,8 @@ static int gpio_config(struct hdmi *hdmi, bool on)
ret = gpio_request(config->mux_en_gpio, "HDMI_MUX_EN");
if (ret) {
dev_err(dev->dev, "'%s'(%d) gpio_request 
failed: %d\n",
-   "HDMI_MUX_SEL", config->mux_en_gpio, 
ret);
+   "HDMI_MUX_EN",
+   config->mux_en_gpio, ret);
goto error4;
}
gpio_set_value_cansleep(config->mux_en_gpio, 1);
@@ -78,6 +79,19 @@ static int gpio_config(struct hdmi *hdmi, bool on)
}
gpio_set_value_cansleep(config->mux_sel_gpio, 0);
}
+
+   if (config->mux_lpm_gpio != -1) {
+   ret = gpio_request(config->mux_lpm_gpio,
+   "HDMI_MUX_LPM");
+   if (ret) {
+   dev_err(dev->dev,
+   "'%s'(%d) gpio_request failed: %d\n",
+   "HDMI_MUX_LPM",
+   config->mux_lpm_gpio, ret);
+   goto error6;
+   }
+   gpio_set_value_cansleep(config->mux_lpm_gpio, 1);
+   }
DBG("gpio on");
} else {
gpio_free(config->ddc_clk_gpio);
@@ -93,11 +107,19 @@ static int gpio_config(struct hdmi *hdmi, bool on)
gpio_set_value_cansleep(config->mux_sel_gpio, 1);
gpio_free(config->mux_sel_gpio);
}
+
+   if (config->mux_lpm_gpio != -1) {
+   gpio_set_value_cansleep(config->mux_lpm_gpio, 0);
+   gpio_free(config->mux_lpm_gpio);
+   }
DBG("gpio off");
}

return 0;

+error6:
+   if (config->mux_sel_gpio != -1)
+   gpio_free(config->mux_sel_gpio);
 error5:
if (config->mux_en_gpio != -1)
gpio_free(config->mux_en_gpio);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function

[Michel Dänzer]

On 31.07.2014 00:21, Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrj?l? wrote:
>> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
>>> On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel D?nzer wrote:
>>>> On 30.07.2014 17:22, Daniel Vetter wrote:
>>>>> On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel D?nzer wrote:
>>>>>> On 30.07.2014 06:32, Daniel Vetter wrote:
>>>>>>> + * due to lack of driver support or because the crtc is off.
>>>>>>> + */
>>>>>>> +void drm_crtc_vblank_wait(struct drm_crtc *crtc)
>>>>>>> +{
>>>>>>> +   drm_vblank_wait(crtc->dev, drm_crtc_index(crtc));
>>>>>>> +}
>>>>>>> +EXPORT_SYMBOL(drm_crtc_vblank_wait);
>>>>>>> +
>>>>>>> +/**
>>>>>>
>>>>>> Maybe the function names should be *_vblank_wait_next() or something to
>>>>>> clarify the purpose and reduce potential confusion versus 
>>>>>> drm_wait_vblank().
>>>>>
>>>>> Yeah that name is just transferred from the i915 driver. What about
>>>>> drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
>>>>
>>>> I don't care that much :), go ahead.
>>>
>>> Just my two cents: our downstream kernel has a helper somewhat like this
>>> which waits for a specified number of frames (apparently this is useful
>>> for some panels that require up to 5 or 6 frames before they display the
>>> correct image on screen). So perhaps something like this could work:
>>>
>>> void drm_wait_vblank_count(struct drm_device *dev, unsigned int crtc,
>>>unsigned int count)
>>> {
>>> u32 last;
>>> int ret;
>>>
>>> ret = drm_vblank_get(dev, crtc);
>>> if (WARN_ON(ret))
>>> return;
>>>
>>> while (count--) {
>>> last = drm_vblank_count(dev, crtc);
>>>
>>> ...
>>> }
>>>
>>> drm_vblank_put(dev, crtc);
>>> }
>>
>> Would be nicer to wait for an absolute vblank count instead IMO. Or
>> if you want to pass a relative count in just convert it to an absolute
>> count first and wait for it (taking wraparound into account obviously).
> 
> Hmm... would something like this work?
> 
>   target = drm_vblank_count(dev, crtc) + count;
> 
>   ret = wait_event_timeout(...,
>drm_vblank_count(dev, crtc) == target,
>...);
> 
> That should properly take into account wrap-around given that both sites
> use drm_vblank_count().

I think it would be better to refactor drm_wait_vblank() than to
reinvent it.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 234 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/a4eace1e/attachment.sig>

[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card

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

https://bugzilla.kernel.org/show_bug.cgi?id=80331

Colin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #16 from Colin  ---
(In reply to Alex Deucher from comment #15)
> (In reply to Colin from comment #14)
> > 
> > Thanks I'll give it a go when I home from work tonight. I am sure that will
> > be the solution. Strange thing is that even with the firmware not loaded the
> > card works fine when the patch is not present.
> 
> The patch changes when the firmware loads during driver init.  With the
> patch the failure happens earlier so the error is fatal and the driver
> doesn't load.  Without the patch, the driver still loads but all
> acceleration, interrupts, and most other features are disabled so it's not
> exactly working.

That explains it. I guess when it is a module it loads the firmware when the
module loads and initializes. I had a look at the request_firmware() function
and I think it will read the firmware if it is not already in memory. I suspect
that can't work when it is static as the driver is initialized before the disk
drivers are loaded. Anyway the so called "bug" turns out to be my stupidity:-(
Such is life.

In any event thanks for all your help and the explanation.

Best wishes.
Colin

PS I'm not sure what the correct code from the list is. There isn't a "Stupid
User" one so I picked Invalid. I hope that's ok.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function

[Daniel Vetter]

On Thu, Jul 31, 2014 at 3:14 AM, Michel D?nzer  wrote:
> I think it would be better to refactor drm_wait_vblank() than to
> reinvent it.

That's the ioctl implementation which spends most of its time decoding
ioctl structures. If we take that out then there's about half a line
which would be shared (since a lot of the stuff in there is ums gunk
that we don't want to carry over to a kms-only internal interface). So
imo that doesn't make sense.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v8 11/11] drm: sti: Add DRM driver itself

[Benjamin Gaignard]

It is a regression that I have introduce with universal plane.
I have fix it and refresh v8 branch.

I have map CRTC on hardware mixers IP.
I could have one or two mixers, its depends of the chipset and I use
one graphic input (GDP) per mixer as primary plane.
Other GPD are used as overlay planes.
Some version of the display IP have one hardware cursor which could be
used only with the first mixer.

I haven't push yet the code to support the cursor, I would like to do
it when the current patches will have been accepted and merge
upstream.


2014-07-30 23:04 GMT+02:00 Rob Clark :
> On Wed, Jul 30, 2014 at 3:48 PM, Daniel Vetter  wrote:
>> On Wed, Jul 30, 2014 at 7:42 PM, Benjamin Gaignard
>>  wrote:
>>> @@ -87,11 +90,50 @@ static int sti_compositor_bind(struct device *dev, 
>>> struct device *master,
>>> struct sti_compositor *compo = dev_get_drvdata(dev);
>>> struct drm_device *drm_dev = data;
>>> unsigned int i, crtc = 0, plane = 0;
>>> +   struct sti_drm_private *dev_priv = drm_dev->dev_private;
>>> +   struct drm_plane *cursor = NULL;
>>> +   struct drm_plane *primary = NULL;
>>> +
>>> +   dev_priv->compo = compo;
>>>
>>> drm_vblank_init(drm_dev, crtc);
>>
>>
>> This looks strange - you should pass this the total number of crtcs
>> (the same that eventually ends up in dev->mode_config.num_crtc), not
>> 0. And the assignement of cursors to crtcs looks a bit strange on
>
> hmm, Benjamin probably should try modetest w/ -v arg..  it does look a
> bit like something is missing here..
>
> BR,
> -R
>
>> first read-through, but I have no clue about the sti hw. And in any
>> case those pointers really only matter for backwards compat with
>> existing pageflip and cursor ioctls, so doesn't really matter too
>> much.
>>
>> Anyway didn't spot anything else which would need to be upgrade to
>> never kms interfaces, so ack from my side for that. Only looked at
>> that since right now I'm refreshing drm docs in those areas ;-)
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org ? Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Bug 81930] [glamor] misrendered glyphs

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

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

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |xorg-team at lists.x.org
   |.org|
 QA Contact||xorg-team at lists.x.org
Summary|[Hawaii] misrendered glyphs |[glamor] misrendered glyphs
Product|Mesa|xorg
  Component|Drivers/Gallium/radeonsi|Driver/glamor

--- Comment #5 from Michel D?nzer  ---
I think this is most likely a bug in the glamor glyph cache code.

(In reply to comment #3)
> Very rarely I see misrendered windows as well, is this related or a
> different bug?

Probably different. There is at least one existing bug report about glamor
rendering issues in KDE.

-- 
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/20140731/d24562b4/attachment-0001.html>

[Bug 81930] [Hawaii] misrendered glyphs

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

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

--- Comment #4 from Zolt?n B?sz?rm?nyi  ---
I see some misrendered glyphs on my Radeon R9 270X, too, in Firefox. So it's
not Hawaii specific.

-- 
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/20140731/9c0c33c4/attachment.html>

[Bug 81837] [radeonsi] memory leaks in OpenCL

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

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

--- Comment #5 from Michel D?nzer  ---
(In reply to comment #3)
> valgrind.log

If you could do this again with /usr/lib/gallium-pipe/pipe_radeonsi.so having
debugging symbols as well, that might make it clearer whether the biggest leak
is in Mesa or LLVM.

-- 
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/20140731/54fc0e1f/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #131 from Marek Ol??k  ---
DPM seems to be working here. If I do "sudo cat
/sys/kernel/debug/dri/64/radeon_pm_info" with no 3D app running, I get:

power level avgsclk: 30047 mclk: 15000

If I do the same while glxgears is running, I get:

power level avgsclk: 8 mclk: 112500

That said, the performance seems to be lower than Bonaire. The open source game
Torcs has 27 FPS with Bonaire and 18 FPS with Hawaii. radeontop shows 100% GPU
usage with Hawaii while Torcs is running.

-- 
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/20140731/ac6d44f1/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #130 from Luzipher  ---
(In reply to comment #126)
> (In reply to comment #124)
> > 
> > And for the DPM stuff: dpm doesn't seem to work, the numbers never changed
> > (tested on console without X and Metro Last Light; I dropped my previous
> > "radeon.dpm=0" from the kernel parameters):
> > # cat /sys/kernel/debug/dri/64/radeon_pm_info
> > power level avgsclk: 3 mclk: 15000
> 
> You need to print that out while you have a 3D app running.  Those numbers
> are real-time.  E.g., in the console, there is no 3D acceleration happening
> so they stay at their low levels.

I did just that :-) Sorry if I wasn't clear enough on this. Actually what I did
was starting Metro Last Light and catting over ssh multiple times from my
laptop (Metro doesn't allow alt-tab). The values never changed at all.

I chose Metro, because it's the most graphically challenging piece of software
I have - and should therefore certainly cause a change of values. glxgears
didn't cause a change as well, but I thought that might be because it's too
simple.

Today, to verify, I also tried it with Half Life 2. Same result. (But MSAA
works now with the libdrm patch, thanks Marek !)

All of the above still with the "ASIC_ProfilingInfo v3.1" as I got a NULL
pointer dereference with yesterday's drm-next-3.17-rebased-on-fixes kernel.

I guess the new kernel to use is "standard" 3.17-wip, as it now contains all
the Hawaii stuff ?


I'm also ok with tracking the remaining issues in separate bugs - do I need to
close this bug ? (I'd wait till the xf86-video-ati patch is applied).
Any requests on which issues should get their own bugs now ? Turning off HDMI-0
and Glyphs come to mind ?

Oh and I had a typo in my last comment - of course I updated bug #74250. Is
that maybe related to my never changing power states ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: