date:20121204

On Tue, Dec 4, 2012 at 11:09 PM, Lekensteyn  wrote:
> On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
>> Ok, but in comment 11 in the same thread you mention that reverting
>> this patch didn't fix the issue for you:
>>
>> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue."
> The bisected commit was from between rc2 and rc3:
> $ git describe 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> v3.6-rc2-88-g504c726

This just means that after -rc2 there are 88 patches until 504c72.
This doesn't mean at all that this patch is included in -rc3 - git
history is non-linear! In fact this commit is only part of the 3.7-rc1
release, so if you just update Linus' tree it will have shown up
somewhere between the 3.6 and 3.7-rc1 tag being pushed out.

> The fact that reverting that commit does not help implies that some commits
> thereafter also expose the bug.

Well, enabling rc6 was merge before the offending commit but still
works around at least a class of bugs. So it's very likely that we're
just hunting down different strawmens ...

>> > i915.i915_enable_rc6=0 worked for me, if it does not work for you, then
>> > you  probably hit another bug.
>>
>> I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
>> compositor. Now I'm trying to hit the bug again...
> Do you have a reliable reproduce method? As you can see in the linked bug it
> was caused by relatively low memory pressure combined with high I/O (caching?
> delays? Who knows).

Nope, we could only reproduce quickly with rc6 enabled :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

i915 freakout with latest 3.7 git

2012-12-04 Thread Lekensteyn

On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
> Ok, but in comment 11 in the same thread you mention that reverting
> this patch didn't fix the issue for you:
> 
> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue."
The bisected commit was from between rc2 and rc3:
$ git describe 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
v3.6-rc2-88-g504c726
The fact that reverting that commit does not help implies that some commits 
thereafter also expose the bug.

> > i915.i915_enable_rc6=0 worked for me, if it does not work for you, then
> > you  probably hit another bug.
> 
> I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
> compositor. Now I'm trying to hit the bug again...
Do you have a reliable reproduce method? As you can see in the linked bug it 
was caused by relatively low memory pressure combined with high I/O (caching? 
delays? Who knows).

> A shot in the dark: could it be that all the machines wich encounter
> this hang have nvidia's optimus? Mine has. Could that somehow be
> related? (I'm by no means a programmer or a kernel hacker..).
It is unlikely that Optimus has anything to do with this.

Peter

[Bug 37485] Noise in some tracks in SuperTuxKart (HyperZ related)

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

gsr.bugs  changed:

   What|Removed |Added

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

--- Comment #3 from gsr.bugs  ---
Sorry, no easy access to try with the RV360 currently. If Tomasz P. says
that no more lines or squares, great. If the issue reappears, we can reopen
it or fill a new report. 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/20121204/cf33f0c8/attachment.html>

[RFC v2 1/8] video: tegra: Add nvhost driver

On Mon, Dec 03, 2012 at 12:23:32PM -0700, Stephen Warren wrote:
> On 12/01/2012 07:58 AM, Thierry Reding wrote:
> > On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergstr?m wrote:
> ...
> >> I was thinking of definitions like this:
> >> 
> >> static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f(u32 v) { 
> >> return (v & 0x1ff) << 0; }
> >> 
> >> versus
> >> 
> >> #define host1x_sync_cfpeek_ctrl_cfpeek_addr_f(v) ((v) >> 16) &
> >> 0x3ff
> >> 
> >> Both of these produce the same machine code and have same usage,
> >> but the latter has type checking and code coverage analysis and
> >> the former is (in my eyes) clearer. In both of these cases the
> >> usage is like this:
> >> 
> >> writel(host1x_sync_cfpeek_ctrl_cfpeek_ena_f(1) |
> >> host1x_sync_cfpeek_ctrl_cfpeek_channr_f(chid) |
> >> host1x_sync_cfpeek_ctrl_cfpeek_addr_f(rd_ptr), m->sync_aperture +
> >> host1x_sync_cfpeek_ctrl_r());
> > 
> > Again there's no precedent for doing this with static inline
> > functions. You can do the same with macros. Type checking isn't an
> > issue in these cases since we're talking about bitfields for which
> > no proper type exists.
> 
> I suspect the inline functions could encode signed-vs-unsigned fields,
> perhaps catch u8 variables when they should have been u32, etc.?

I don't see how this would be relevant here. These definitions are only
used in the driver internally and not a public API, therefore none of
those checks should really be needed. If somebody writes code for this
driver and uses the register definitions, they better know what they're
doing. Or at least wrong usage should be filtered out through review.

In my opinion the consistency with how other drivers are written far
outweigh the benefits provided by inline functions. That said, I'm out
of arguments and I don't have a final say anyway, so if it is decided
to stick with inline functions I can find a way to live with them.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/21cdb9cc/attachment.pgp>

i915 freakout with latest 3.7 git

On 04.12.2012, Daniel Vetter wrote: 

> The important part is to not enable rc6 (on ironlake at least) when
> bisecting.

A shot in the dark: could it be that all the machines wich encounter
this hang have nvidia's optimus? Mine has. Could that somehow be
related? (I'm by no means a programmer or a kernel hacker..).

i915 freakout with latest 3.7 git

On 04.12.2012, Lekensteyn wrote: 

> As mentioned in the linked bug [1], I bisected it to:
> 
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson 
> Date:   Thu Aug 23 13:12:52 2012 +0100
> 
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable

Ok, but in comment 11 in the same thread you mention that reverting
this patch didn't fix the issue for you:

"Reverting that commit on top of 3.7-rc4 did not fix the hang issue."

> i5-420M is not SB, but ILK. i5-2xxx is SB. I have a i5-460M myself. 

Yes, you're right, my bad! Don't know what I was thinking as I wrote that. I
don't have any i5-420M either, but an i5-450M. It was clearly not my
day..

[htd at wildsau ~]$ cat /proc/cpuinfo | grep model
model: 37
model name   : Intel(R) Core(TM) i5 CPU   M 450  @ 2.40GHz
[]

> i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you 
> probably hit another bug.

I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
compositor. Now I'm trying to hit the bug again...

Heinz

[Bug 51301] [-next-20121129] memory leak/page allocator fragmentation?

2012-12-04 Thread bugzilla-dae...@bugzilla.kernel.org

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|kvm |Page Allocator
Version|unspecified |2.5
 AssignedTo|virtualization_kvm at kernel-b |akpm at linux-foundation.org
   |ugs.osdl.org|
Product|Virtualization  |Memory Management




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching someone on the CC list of the bug.

i915 freakout with latest 3.7 git

On Tue, Dec 4, 2012 at 9:41 PM, Lekensteyn  wrote:
> On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
>> Btw: which kernel is known to be the "last good one"?
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson 
> Date:   Thu Aug 23 13:12:52 2012 +0100
>
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable

Iirc your issue goes away with rc6=0, the residual bugs we still have
all still happen with rc6 disable, so probably something else. Hence
also why we're asking everyone who can still reproduce to try a
bisect, since with rc6 disabled we've can't reproduce the hang any
more (beforehand we could reproduce it on 3 different ilk machines).
The important part is to not enable rc6 (on ironlake at least) when
bisecting.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 51301] [-next-20121129] memory leak/page allocator fragmentation?

2012-12-04 Thread bugzilla-dae...@bugzilla.kernel.org

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


Marcelo Tosatti  changed:

   What|Removed |Added

 CC||mtosatti at redhat.com




--- Comment #5 from Marcelo Tosatti   2012-12-04 
21:42:00 ---
Dec  4 09:38:25 thor kernel: [322576.251464] firefox: page allocation failure:
order:4, mode:0x80c0d0

This is an order-4 allocation failure. This is due to kernel failure to
allocate physically contiguous region of memory. Please reassign to "Memory
Management" component.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching someone on the CC list of the bug.

i915 freakout with latest 3.7 git

2012-12-04 Thread Lekensteyn

On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
> Btw: which kernel is known to be the "last good one"?
As mentioned in the linked bug [1], I bisected it to:

commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
Author: Chris Wilson 
Date:   Thu Aug 23 13:12:52 2012 +0100

drm/i915: Use cpu relocations if the object is in the GTT but not mappable

> > (you need to disable rc6 on ilk to not hit another issue which seems much
> > easier to hit)
> 
> Ilk? If this stands for "Ironlake": I'm on Sandybridge.
> 
> > ...
> 
> Bisecting will be a pain without being able to reproduce
> the hang reliably.
> 
> > Atm we're trying to come up with ways to dump more debug
> > information, >but with no clue whatsoever what's going on that's
> > slow-going.
> Is there anything at the moment I can do to help you to get a grip on
> this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus
> U45-JC).
i5-420M is not SB, but ILK. i5-2xxx is SB. I have a i5-460M myself. 
i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you 
probably hit another bug.

Peter


 [1]: https://bugs.freedesktop.org/show_bug.cgi?id=55984#c9

[PATCH v2] drm/exynos: release fb pended by page flip

Changelog v2:
fix page fault issue.
- defer to unreference old fb to avoid page fault issue.
So with this fixup, new fb would be updated to hardware
prior to old fb unreferencing. And it removes unnecessary
patch, "drm/exynos: Unreference fb in exynos_disable_plane()"

Changelog v1:
This patch releases the fb pended by page flip after fbdev is
restored propely. And fixes invalid memory access when drm is
released while doing pageflip.

This patch makes fb's refcount to be increased when setcrtc and
pageflip are requested. In other words, it increases fb's refcount
only if dma is going to access memory region to fb and decreases
old fb's because the old fb isn't accessed by dma anymore.

This could guarantee releasing gem buffer to the fb after dma
access to the gem buffer has been completed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   28 ++-
 5 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2efa4b0..b9c37eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,6 +32,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_encoder.h"
 #include "exynos_drm_plane.h"
+#include "exynos_drm_fb.h"

 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc,\
drm_crtc)
@@ -139,8 +140,25 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
plane->crtc = crtc;
plane->fb = crtc->fb;

+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane->fb);
+
exynos_drm_fn_encoder(crtc, , exynos_drm_encoder_crtc_pipe);

+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
return 0;
 }

@@ -169,8 +187,27 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
if (ret)
return ret;

+   plane->fb = crtc->fb;
+
+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane->fb);
+
exynos_drm_crtc_commit(crtc);

+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
return 0;
 }

@@ -243,7 +280,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,

crtc->fb = fb;
ret = exynos_drm_crtc_mode_set_base(crtc, crtc->x, crtc->y,
-   NULL);
+   old_fb);
if (ret) {
crtc->fb = old_fb;

@@ -254,6 +291,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,

goto out;
}
+
+   exynos_drm_fb_set_pending(old_fb, false);
+   exynos_drm_fb_set_pending(fb, true);
}
 out:
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 7190b64..7ed5507 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -45,11 +45,15 @@
  * @fb: drm framebuffer obejct.
  * @buf_cnt: a buffer count to drm framebuffer.
  * @exynos_gem_obj: array of exynos specific gem object containing a gem 
object.
+ * @pending: indicate whehter a fb was pended by page flip.
+ * if true, the fb should be released after fbdev is restored to avoid
+ * accessing invalid memory region.
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
unsigned intbuf_cnt;
struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
+   boolpending;
 };

 static int check_fb_gem_memory_type(struct drm_device *drm_dev,
@@ -278,6 +282,25 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return fb;
 }

+void exynos_drm_fb_set_pending(struct drm_framebuffer *fb, bool pending)
+{
+

[Bug 57842] r200: Culling is broken when rendering to an FBO

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

--- Comment #2 from Roland Scheidegger  ---
Created attachment 71014
  --> https://bugs.freedesktop.org/attachment.cgi?id=71014=edit
potential fixes for viewport trouble

I had something like this in mind. Untested though and all that viewport
updating stuff seems really weird. I hope I didn't create circular calling
chains...
Might not fix this bug at all...

-- 
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/20121204/e441e77b/attachment.html>

[PATCH 0/3] drm/exynos: modify usage of wait for vblank

This patchset fixes a few issues with use of wait for vblank in
exynos drm. 

Please apply these three patches without "drm/exynos: release fb pended by page 
flip"
patch.

Patch 1: modify wait for vsync functions to use wait queues
This modifies the wait_for_vblank functions to use wait queues
thus ensuring that the current task goes to sleep without taking
up CPU while waiting.

Patch 2: move wait_for_vblank to manager_ops
Currently, we do not call wait for vblank if encoder is in DPMS_OFF
state inside exynos_drm_encoder_complete_scanout function. This is
because wait for vblank is treated as an overlay op. This can be
modified to a manager_op thus removing the above check for DPMS_OFF.
This fixes a crash while removing a fb.
While removing the current fb (crtc->fb == fb) the encoder
dpms off is called and then the framebuffer is removed. So in
this case, the wait for vblank is not called thus leading to a crash
(since fb might get removed before dma is finished)

Patch 3: do not disable crtc if already off
We should not disable the overlay if the crtc is in DPMS_OFF state.
Also, the disable function should not call DPMS_OFF of the crtc.
This is required to ensure we are able to wait for vblank
before freeing any framebuffers after disabling the crtc.

With these three patches and without "drm/exynos: release fb pended by page 
flip"
I could not find any crash/page_fault in drm with fimd/hdmi during hotplug
and page flips.

Prathyush K (3):
  drm/exynos: modify wait for vsync functions to use wait queues
  drm/exynos: move wait_for_vblank to manager_ops
  drm/exynos: do not disable crtc if already off

 drivers/gpu/drm/exynos/exynos_drm_crtc.c|6 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   20 ++
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   37 ++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|   22 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   37 +-
 7 files changed, 73 insertions(+), 66 deletions(-)

[Bug 57842] r200: Culling is broken when rendering to an FBO

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

--- Comment #1 from Roland Scheidegger  ---
Hmm this is odd I can't see anything wrong with the culling setup wrt fbos.
The viewport, window handling though seems somewhat bogus.
First, r200UpdateViewportOffset() has no callers (it is used in
radeon->vtbl.update_viewport_offset but that one seems to have no callers
neither). This function would not take the y flip into account but since it
isn't used... I'd just get rid of it but it's the only thing handling stippling
that probably needs to move somewhere else.
Also, both r200UpdateViewportOffset() and r200UpdateWindow() use the
driDrawable height for the yoffset in the viewport. I don't think that will
work for fbos, should just use the ctx->DrawBuffer height instead?
I can't see though why that would just cause failures with culling.

-- 
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/20121204/ca254407/attachment.html>

[PATCH 3/3] drm/exynos: do not disable crtc if already off

The crtc disable function should not disable the overlays if the
crtc is already in DPMS_OFF as this will lead to register access
when clock is off.
Also the crtc disable function should not call DPMS OFF of the
crtc. This is required to ensure we are able to wait for vblank
before freeing any framebuffers after disabling the crtc.

Signed-off-by: Prathyush K 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2efa4b0..faa6ee0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -186,8 +186,12 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)

DRM_DEBUG_KMS("%s\n", __FILE__);

+   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
+   DRM_DEBUG_KMS("crtc is already off.\n");
+   return;
+   }
+
exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_OFF);
-   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
 }

 static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
-- 
1.7.0.4

[PATCH 2/3] drm/exynos: move wait_for_vblank to manager_ops

Currently wait_for_vblank is set as an overlay_op which is not
correct since wait for vblank is not dependant on any particular
overlay. It should be grouped with enable/disable vblank calls
inside manager_ops.
Also if wait for vblank is a manager op, the check for DPMS_OFF
of encoder can be removed inside exynos_drm_encoder_complete_scanout.
This fixes the following issue while removing a fb.
While removing the current fb (crtc->fb == fb) the encoder
dpms off is called and then the framebuffer is removed. So in
this case, the wait for vblank is not called thus leading to a crash
(since fb might get removed before dma is finished).

Signed-off-by: Prathyush K 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |6 ++--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   34 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|   22 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   34 +-
 6 files changed, 53 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6bb8644..98597d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -60,8 +60,6 @@ enum exynos_drm_output_type {
  * @commit: apply hardware specific overlay data to registers.
  * @enable: enable hardware specific overlay.
  * @disable: disable hardware specific overlay.
- * @wait_for_vblank: wait for vblank interrupt to make sure that
- * hardware overlay is disabled.
  */
 struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -69,7 +67,6 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
-   void (*wait_for_vblank)(struct device *subdrv_dev);
 };

 /*
@@ -172,6 +169,8 @@ struct exynos_drm_display_ops {
  * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * hardware overlay is updated.
  */
 struct exynos_drm_manager_ops {
void (*dpms)(struct device *subdrv_dev, int mode);
@@ -186,6 +185,7 @@ struct exynos_drm_manager_ops {
void (*commit)(struct device *subdrv_dev);
int (*enable_vblank)(struct device *subdrv_dev);
void (*disable_vblank)(struct device *subdrv_dev);
+   void (*wait_for_vblank)(struct device *subdrv_dev);
 };

 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index d9afb11..3014852 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -237,8 +237,7 @@ static void exynos_drm_encoder_commit(struct drm_encoder 
*encoder)
 void exynos_drm_encoder_complete_scanout(struct drm_framebuffer *fb)
 {
struct exynos_drm_encoder *exynos_encoder;
-   struct exynos_drm_overlay_ops *overlay_ops;
-   struct exynos_drm_manager *manager;
+   struct exynos_drm_manager_ops *ops;
struct drm_device *dev = fb->dev;
struct drm_encoder *encoder;

@@ -248,21 +247,15 @@ void exynos_drm_encoder_complete_scanout(struct 
drm_framebuffer *fb)
 */
list_for_each_entry(encoder, >mode_config.encoder_list, head) {
exynos_encoder = to_exynos_encoder(encoder);
-
-   /* if exynos was disabled, just ignor it. */
-   if (exynos_encoder->dpms > DRM_MODE_DPMS_ON)
-   continue;
-
-   manager = exynos_encoder->manager;
-   overlay_ops = manager->overlay_ops;
+   ops = exynos_encoder->manager->ops;

/*
 * wait for vblank interrupt
 * - this makes sure that overlay data are updated to
 *  real hardware.
 */
-   if (overlay_ops->wait_for_vblank)
-   overlay_ops->wait_for_vblank(manager->dev);
+   if (ops->wait_for_vblank)
+   ops->wait_for_vblank(exynos_encoder->manager->dev);
}
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 63f0d0f..020eb86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -320,12 +320,29 @@ static void fimd_disable_vblank(struct device *dev)
}
 }

+static void fimd_wait_for_vblank(struct device *dev)
+{
+   struct fimd_context *ctx = get_fimd_context(dev);
+
+   atomic_set(>wait_vsync_event, 1);
+
+   /*
+* wait for FIMD to signal VSYNC interrupt

[PATCH 1/3] drm/exynos: modify wait for vsync functions to use wait queues

It is more optimium to use wait queues while waiting for vsync so
that the current task is put to sleep. This way, the task wont
hog the CPU while waiting. We use wait_event_timeout and not
an interruptible function since we dont want the function to exit
when a signal is pending (e.g. drm release). This patch modifies
the wait for vblank functions of both fimd and mixer.

Also, the current fimd wait_for_vblank did not work in exynos5
since VIDCON1 has to be used in addition to timing base offset
(0x2). This patch also eliminates this problem.

Signed-off-by: Prathyush K 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   14 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   21 +
 drivers/gpu/drm/exynos/exynos_mixer.c|   21 -
 3 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a4702a8..6bb8644 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -36,20 +36,6 @@
 #define MAX_FB_BUFFER  4
 #define DEFAULT_ZPOS   -1

-#define _wait_for(COND, MS) ({ \
-   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS);   \
-   int ret__ = 0;  \
-   while (!(COND)) {   \
-   if (time_after(jiffies, timeout__)) {   \
-   ret__ = -ETIMEDOUT; \
-   break;  \
-   }   \
-   }   \
-   ret__;  \
-})
-
-#define wait_for(COND, MS) _wait_for(COND, MS)
-
 struct drm_device;
 struct exynos_drm_overlay;
 struct drm_connector;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e2abae6..63f0d0f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -101,6 +101,8 @@ struct fimd_context {
u32 vidcon1;
boolsuspended;
struct mutexlock;
+   wait_queue_head_t   wait_vsync_queue;
+   atomic_twait_vsync_event;

struct exynos_drm_panel_info *panel;
 };
@@ -606,11 +608,16 @@ static void fimd_win_disable(struct device *dev, int zpos)
 static void fimd_wait_for_vblank(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
-   int ret;

-   ret = wait_for((__raw_readl(ctx->regs + VIDCON1) &
-   VIDCON1_VSTATUS_VSYNC), 50);
-   if (ret < 0)
+   atomic_set(>wait_vsync_event, 1);
+
+   /*
+* wait for FIMD to signal VSYNC interrupt or return after
+* timeout which is set to 50ms (refresh rate of 20).
+*/
+   if (!wait_event_timeout(ctx->wait_vsync_queue,
+   !atomic_read(>wait_vsync_event),
+   DRM_HZ/20))
DRM_DEBUG_KMS("vblank wait timed out.\n");
 }

@@ -677,6 +684,10 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
drm_handle_vblank(drm_dev, manager->pipe);
fimd_finish_pageflip(drm_dev, manager->pipe);

+   /* set wait vsync event to zero and wake up queue. */
+   atomic_set(>wait_vsync_event, 0);
+   DRM_WAKEUP(>wait_vsync_queue);
+
 out:
return IRQ_HANDLED;
 }
@@ -967,6 +978,8 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
ctx->vidcon1 = pdata->vidcon1;
ctx->default_win = pdata->default_win;
ctx->panel = panel;
+   DRM_INIT_WAITQUEUE(>wait_vsync_queue);
+   atomic_set(>wait_vsync_event, 0);

subdrv = >subdrv;

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 50100cf..972281e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -93,6 +93,8 @@ struct mixer_context {
struct hdmi_win_datawin_data[MIXER_WIN_NR];
enum mixer_version_id   mxr_ver;
void*parent_ctx;
+   wait_queue_head_t   wait_vsync_queue;
+   atomic_twait_vsync_event;
 };

 struct mixer_drv_data {
@@ -791,12 +793,16 @@ static void mixer_dpms(void *ctx, int mode)
 static void mixer_wait_for_vblank(void *ctx)
 {
struct mixer_context *mixer_ctx = ctx;
-   struct mixer_resources *res = _ctx->mixer_res;
-   int ret;

-   ret = wait_for((mixer_reg_read(res, MXR_INT_STATUS) &
-   MXR_INT_STATUS_VSYNC), 50);
-   if (ret < 0)
+   atomic_set(_ctx->wait_vsync_event, 1);
+
+   /*
+* wait for MIXER to

i915 freakout with latest 3.7 git

2012-12-04 Thread Dave Airlie

On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl  wrote:
> On 03.12.2012, devendra.aaru wrote:
>
>> Add more CC's
>
> Thanks!
>
> This is a real showstopper for me, it occurs in every session now.
> Booting with "i915.i915_enable_rc6=0" doesn't help

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

intel guys are as lost as anyone.

Dave.

[Bug 57888] Amnesia shader compiler errors on RV350

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

Andreas Boll  changed:

   What|Removed |Added

  Attachment #71005|text/plain  |image/png
  mime type||

-- 
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/20121204/c1a79a64/attachment.html>

[PATCH] drm: Make the HPD status updates debug logs more readable

On Tue, Dec 04, 2012 at 04:00:17PM +, Damien Lespiau wrote:
> From: Damien Lespiau 
> 
> Instead of just printing "status updated from 1 to 2", make those enum
> numbers immediately readable.
> 
> Signed-off-by: Damien Lespiau 

I like, stupid me can never remember the magic values. For the patch
itself, can you please also patch the connector updates in
drm_helper_probe_single_connector_modes (which is required to avoid losing
hpd events when doing a manual probe cycle) and output_poll_execute. For
completeness maybe also throw in a debug output in
drm_helper_disable_unused_functions, but that's only relevant for drivers
that use the modeset helpers (i.e. not for drm/i915).

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 1fe719f..8b963fd 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -1043,6 +1043,18 @@ void drm_kms_helper_poll_fini(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_kms_helper_poll_fini);
>  
> +static const char *connector_status_str(enum drm_connector_status status)
> +{
> + switch (status) {
> + case connector_status_connected:
> + return "connected";
> + case connector_status_disconnected:
> + return "disconnected";
> + default:
> + return "unknown";
> + }
> +}
> +
>  void drm_helper_hpd_irq_event(struct drm_device *dev)
>  {
>   struct drm_connector *connector;
> @@ -1062,10 +1074,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
>   old_status = connector->status;
>  
>   connector->status = connector->funcs->detect(connector, false);
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> %d\n",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
> %s\n",
> connector->base.id,
> drm_get_connector_name(connector),
> -   old_status, connector->status);
> +   connector_status_str(old_status),
> +   connector_status_str(connector->status));
>   if (old_status != connector->status)
>   changed = true;
>   }
> -- 
> 1.7.11.7
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 57888] Amnesia shader compiler errors on RV350

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

--- Comment #4 from Scott Moreau  ---
Created attachment 71007
  --> https://bugs.freedesktop.org/attachment.cgi?id=71007=edit
amnesia output with RADEON_DEBUG=fp

(In reply to comment #3)
> Could you run the program with the environment variable RADEON_DEBUG=fp and
> then post the output.

Yes, I have attached a file with the output. 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/20121204/7cbe07d4/attachment.html>

[PATCH v2] drm/exynos: release fb pended by page flip

.c
> @@ -203,11 +203,29 @@ exynos_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> if (ret < 0)
> return ret;
>
> -   plane->crtc = crtc;
> +   /*
> +* Take a reference to new fb.
> +*
> +* Taking a reference means that this plane's dma is going to
> access
> +* memory region to the new fb.
> +*/
> +   drm_framebuffer_reference(fb);
>
> +   plane->crtc = crtc;
> exynos_plane_commit(plane);
> exynos_plane_dpms(plane, DRM_MODE_DPMS_ON);
>
> +   /*
> +* If plane->fb is existed, unreference the fb.
> +*
> +* This means that memory region to the fb isn't accessed by the
> dma
> +* of this plane anymore.
> +*/
> +   if (plane->fb)
> +   drm_framebuffer_unreference(plane->fb);
> +
> +   plane->fb = fb;
> +
> return 0;
>  }
>
> @@ -215,6 +233,14 @@ static int exynos_disable_plane(struct drm_plane
> *plane)
>  {
> DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>
> +   /*
> +* Unreference the (current)fb if plane->fb is existed.
> +* In exynos_update_plane(), the new fb reference count can be
> bigger
> +* than 1. So it can't be removed for that reference count.
> +*/
> +   if (plane->fb)
> +   drm_framebuffer_unreference(plane->fb);
> +
> exynos_plane_dpms(plane, DRM_MODE_DPMS_OFF);
>
> return 0;
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5d0cc13a/attachment-0001.html>

[Bug 40554] r200 falls back to software when clearing FBOs

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

--- Comment #3 from Roland Scheidegger  ---
FWIW the relevant commit fixing this bug was
de694b6b10b7ce23a00cd7296a955f162704ee62.

-- 
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/20121204/0811e8d1/attachment.html>

[Bug 34097] Screen clearing issues in Minecraft and Blender

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

--- Comment #6 from Tomasz P.  ---
on rv350 rendering in blender looks normal with mesa-git, is the situation
changed with current mesa ?

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

[Bug 57888] Amnesia shader compiler errors on RV350

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

--- Comment #3 from Tom Stellard  ---
Could you run the program with the environment variable RADEON_DEBUG=fp and
then post the output.

-- 
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/20121204/48ba6823/attachment.html>

[Bug 57888] Amnesia shader compiler errors on RV350

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

--- Comment #2 from Alex Deucher  ---
If the game uses compressed textures, you may need to install libtxc_dxtn.

-- 
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/20121204/c3127275/attachment-0001.html>

[Bug 57888] Amnesia shader compiler errors on RV350

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

Scott Moreau  changed:

   What|Removed |Added

  Attachment #71005|0   |1
is obsolete||

--- Comment #1 from Scott Moreau  ---
Created attachment 71006
  --> https://bugs.freedesktop.org/attachment.cgi?id=71006=edit
side-by-side comparison

Correctly set type for image attachment.

-- 
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/20121204/7fd455b6/attachment.html>

[Bug 57888] New: Amnesia shader compiler errors on RV350

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

Priority: medium
Bug ID: 57888
Assignee: dri-devel at lists.freedesktop.org
Summary: Amnesia shader compiler errors on RV350
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: oreaus at gmail.com
Hardware: x86 (IA32)
Status: NEW
Version: git
Component: Drivers/Gallium/r300
Product: Mesa

Created attachment 71005
--> https://bugs.freedesktop.org/attachment.cgi?id=71005=edit
side-by-side comparison

Running the game Amnesia with minimal graphics settings and resolution causes
the following error:

r300 FP: Compiler Error:
Too many hardware temporaries used.
Using a dummy shader instead.

With all graphics settings highest, this message is output additionally:

r300 FP: Compiler Error:
compiler/r300_fragprog_emit.c::emit_alu(): Too many ALU instructions

Here is some additional information:

Distro: Xubuntu 12.04 32bit
Kernel: 3.5.0-18-generic
Mesa: ec83535c83c748b067ecf4548e5396fef8719725
libtxc_dxtn.so installed

The game runs but most of the textures are black, except light sources such as
the torches and windows. On Intel Sandybridge, the textures render correctly.
I've attached an image to demonstrate the difference. The left is i965, the
right is r300g. On intel, there are no errors output.

--
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/20121204/224cc406/attachment.html>

[PATCH] drm/radeon: fix eDP clk and lane setup for scaled modes

2012-12-04 Thread Jerome Glisse

On Tue, Dec 4, 2012 at 4:53 PM,   wrote:
> From: Alex Deucher 
>
> Need to use the adjusted mode since we are sending native
> timing and using the scaler for non-native modes.
>
> Signed-off-by: Alex Deucher 
Reviewed-by: Jerome Glisse 
> cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 010bae1..4552d4a 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -340,7 +340,7 @@ static bool radeon_atom_mode_fixup(struct drm_encoder 
> *encoder,
> ((radeon_encoder->active_device & (ATOM_DEVICE_DFP_SUPPORT | 
> ATOM_DEVICE_LCD_SUPPORT)) ||
>  (radeon_encoder_get_dp_bridge_encoder_id(encoder) != 
> ENCODER_OBJECT_ID_NONE))) {
> struct drm_connector *connector = 
> radeon_get_connector_for_encoder(encoder);
> -   radeon_dp_set_link_config(connector, mode);
> +   radeon_dp_set_link_config(connector, adjusted_mode);
> }
>
> return true;
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/exynos: release fb pended by page flip

On Tue, Dec 4, 2012 at 1:14 PM, Inki Dae  wrote:
> Changelog v2:
> fix page fault issue.
> - defer to unreference old fb to avoid page fault issue.
> So with this fixup, new fb would be updated to hardware
> prior to old fb unreferencing. And it removes unnecessary
> patch, "drm/exynos: Unreference fb in exynos_disable_plane()"
>
> Changelog v1:
> This patch releases the fb pended by page flip after fbdev is
> restored propely. And fixes invalid memory access when drm is
> released while doing pageflip.
>
> This patch makes fb's refcount to be increased when setcrtc and
> pageflip are requested. In other words, it increases fb's refcount
> only if dma is going to access memory region to fb and decreases
> old fb's because the old fb isn't accessed by dma anymore.
>
> This could guarantee releasing gem buffer to the fb after dma
> access to the gem buffer has been completed.
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 

Just an fyi, I'm looking into revamping the locking/refcounting in
this area in the drm core right now. No patches yet for public
consumption, but I hope that I can send out and rfc at the end of this
week. Might fix your problem, too, and certainly addresses the issue
Prathyush noticed, since the refcounting is done in the drm core and
should be able to catch all the cases where we need to
reference/unreference an fb.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 37485] Noise in some tracks in SuperTuxKart (HyperZ related)

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

--- Comment #2 from Tomasz P.  ---
(In reply to comment #1)
> Is this still an issue with current Mesa git?

I playing with supertuxcart today.The game is boring so I don't test all
tracks,but I cannot see any rendering errors with hyperz on. I run it on full
details in 1600x1200 and it looks good for me.

mesa-git (today)
xorg-server-git
kernel 3.6.9
kde 4.9.80 (kwin effects enabled)

-- 
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/20121204/a3308fde/attachment.html>

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium

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

--- Comment #17 from Tomasz P.  ---
I just instaled xscreensaver and run crackberg on rv350 / radeon 9600
agp.Normal memory usage nothing special.No warnings in logs. Animation works
without any artefacts or screen flashing.

-- 
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/20121204/1dc0a12c/attachment.html>

[PATCH] drm/radeon: fix eDP clk and lane setup for scaled modes

2012-12-04 Thread alexdeuc...@gmail.com

From: Alex Deucher 

Need to use the adjusted mode since we are sending native
timing and using the scaler for non-native modes.

Signed-off-by: Alex Deucher 
cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 010bae1..4552d4a 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -340,7 +340,7 @@ static bool radeon_atom_mode_fixup(struct drm_encoder 
*encoder,
((radeon_encoder->active_device & (ATOM_DEVICE_DFP_SUPPORT | 
ATOM_DEVICE_LCD_SUPPORT)) ||
 (radeon_encoder_get_dp_bridge_encoder_id(encoder) != 
ENCODER_OBJECT_ID_NONE))) {
struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
-   radeon_dp_set_link_config(connector, mode);
+   radeon_dp_set_link_config(connector, adjusted_mode);
}

return true;
-- 
1.7.7.5

[Bug 51301] [-next-20121129] memory leak/page allocator fragmentation?

2012-12-04 Thread bugzilla-dae...@bugzilla.kernel.org

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





--- Comment #4 from Peter Hurley   2012-12-04 
16:48:22 ---
Not sure why I picked kvm/nouveau for this OOM ;)

Could be any number of apps over a 3.5 period...

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching someone on the CC list of the bug.

[RFC libdrm] Add NVIDIA Tegra support

On Tue, Dec 04, 2012 at 09:28:25AM -0600, Rob Clark wrote:
> On Tue, Dec 4, 2012 at 9:13 AM, Thierry Reding
>  wrote:
> > +int drm_tegra_bo_new(struct drm_tegra *device, uint32_t flags, uint32_t 
> > size,
> > +struct drm_tegra_bo **bop)
> > +{
> > +   struct drm_tegra_gem_create args;
> > +   struct drm_tegra_bo *bo;
> > +   struct tegra_bo *priv;
> > +   int err;
> > +
> > +   if (!device || size == 0 || !bop)
> > +   return -EINVAL;
> > +
> > +   bo = calloc(1, sizeof(*bo));
> > +   if (!bo)
> > +   return -ENOMEM;
> > +
> > +   priv = tegra_bo(bo);
> > +
> > +   DRMLISTINITHEAD(>list);
> > +   atomic_set(>ref, 1);
> > +   bo->device = device;
> > +   bo->flags = flags;
> > +   bo->size = size;
> > +
> > +   memset(, 0, sizeof(args));
> > +   args.flags = flags;
> > +   args.size = size;
> > +
> > +   err = drmCommandWriteRead(device->fd, DRM_TEGRA_GEM_CREATE, ,
> > + sizeof(args));
> > +   if (err < 0) {
> > +   err = -errno;
> > +   free(bo);
> > +   return err;
> > +   }
> > +
> > +   DRMLISTADD(>list, >bo_list);
> > +   bo->handle = args.handle;
> > +   bo->offset = args.offset;
> 
> btw, x11 can rapidly create/destroy temporary pixmaps.. which don't
> necessarily need userspace access.  You might prefer to avoid creating
> mmap offset on GEM bo creation, and instead do this only if userspace
> needs to mmap the bo

Ah, so that's the reason for the MMAP IOCTL provided by other DRMs. Yes,
that might be better in the long run. For now I don't think it makes
much of a difference since the GEM objects are backed by CMA, and
therefore the offset will be created along with the GEM anyway.

With Terje's upcoming rework that handles all the allocations in host1x
this should become more important, especially when the mapping is done
through the Tegra30's IOMMU.

I'll rework that. Thanks for the quick reply.

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

[Bug 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

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

--- Comment #5 from Tomasz P.  ---
(In reply to comment #4)
> I compiled latest mesa (git-51d0892) on my other, desktop computer with ATI
> Technologies Inc RV350 AR [Radeon 9600] and it has the same problem. Xorg
> server is 1.10.2, Linux kernel is 2.6.38.4 and KDE us also 4.6.3

Also have rv350/radeon 9600.I am using kde 4.9.80, kernel 3.6.9, mesa-git from
today xorg-server-git from today . It look like the problem is gone.I changing
gl-screensavers without any screen blanking / flashing.I have kwin effects
enabled.

-- 
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/20121204/56bb3c9b/attachment.html>

[RFC libdrm] Add NVIDIA Tegra support

Add the libdrm_tegra helper library to encapsulate Tegra-specific
interfaces to the DRM.

Furthermore, Tegra is added to the list of supported chips in the
modetest and vbltest programs.

Signed-off-by: Thierry Reding 
---
 Makefile.am   |   6 +-
 configure.ac  |  15 ++-
 include/drm/Makefile.am   |   1 +
 include/drm/tegra_drm.h   |  48 ++
 tegra/Makefile.am |  17 
 tegra/libdrm_tegra.pc.in  |  11 +++
 tegra/tegra.c | 227 ++
 tegra/tegra.h |  51 +++
 tests/modetest/modetest.c |   2 +-
 tests/vbltest/vbltest.c   |   2 +-
 10 files changed, 376 insertions(+), 4 deletions(-)
 create mode 100644 include/drm/tegra_drm.h
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra.c
 create mode 100644 tegra/tegra.h

diff --git a/Makefile.am b/Makefile.am
index 8ecd9d9..e90ae43 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -49,7 +49,11 @@ if HAVE_EXYNOS
 EXYNOS_SUBDIR = exynos
 endif

-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include man
+if HAVE_TEGRA
+TEGRA_SUBDIR = tegra
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(TEGRA_SUBDIR) tests include 
man

 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 0c19929..72d6dfa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -114,6 +114,11 @@ AC_ARG_ENABLE(exynos-experimental-api,
  [Enable support for EXYNOS's experimental API (default: 
disabled)]),
  [EXYNOS=$enableval], [EXYNOS=no])

+AC_ARG_ENABLE(tegra-experimental-api,
+ AS_HELP_STRING([--enable-tegra-experimental-api],
+ [Enable support for Tegra's experimental API (default: 
disabled)]),
+ [TEGRA=$enableval], [TEGRA=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -222,6 +227,11 @@ if test "x$EXYNOS" = xyes; then
AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
 fi

+AM_CONDITIONAL(HAVE_TEGRA, [test "x$TEGRA" = xyes])
+if test "x$TEGRA" = xyes; then
+   AC_DEFINE(HAVE_TEGRA, 1, [Have Tegra support])
+fi
+
 AC_ARG_ENABLE([cairo-tests],
   [AS_HELP_STRING([--enable-cairo-tests],
   [Enable support for Cairo rendering in tests 
(default: auto)])],
@@ -247,7 +257,7 @@ if test "x$HAVE_LIBUDEV" = xyes; then
 fi
 AM_CONDITIONAL(HAVE_LIBUDEV, [test "x$HAVE_LIBUDEV" = xyes])

-if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o 
"x$OMAP" != "xno"; then
+if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o 
"x$OMAP" != "xno" -o "x$TEGRA" != "xno"; then
 # Check for atomic intrinsics
 AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives,
 [
@@ -358,6 +368,8 @@ AC_CONFIG_FILES([
omap/libdrm_omap.pc
exynos/Makefile
exynos/libdrm_exynos.pc
+   tegra/Makefile
+   tegra/libdrm_tegra.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -380,4 +392,5 @@ echo "  Radeon API $RADEON"
 echo "  Nouveau API$NOUVEAU"
 echo "  OMAP API   $OMAP"
 echo "  EXYNOS API $EXYNOS"
+echo "  Tegra API  $TEGRA"
 echo ""
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 2923ab4..3e33ed0 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -35,6 +35,7 @@ klibdrminclude_HEADERS = \
radeon_drm.h \
savage_drm.h \
sis_drm.h \
+   tegra_drm.h \
via_drm.h \
mach64_drm.h

diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
new file mode 100644
index 000..eaec602
--- /dev/null
+++ b/include/drm/tegra_drm.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright ? 2012 Thierry Reding
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY

[RFC libdrm] Add NVIDIA Tegra support

Hi,

I mentioned in a reply to Terje's patch series for 2D acceleration that
I had prototyped some libdrm support a few weeks back. I've spent a bit
of time cleaning it up and decided to post it for early review.

There's really not much interesting code here. A basic API is provided
along with two IOCTLs that can be used to create Tegra-specific GEM, as
opposed to dumb buffer objects. Given the various comments on Terje's
proposed IOCTLs I wanted to make sure that these will be safe. I've seen
that other chips use 64-bit fields for the size and offset of buffer
objects and I wonder if those are really necessary.

Linux kernel patches for the IOCTLs are also in the works and I hope to
get around to posting them this week. Obviously there will be some
overlap between this and what Terje posted in his series, but it should
be easy to synchronize.

Thierry

Thierry Reding (1):
  libdrm: Add NVIDIA Tegra support

 Makefile.am   |   6 +-
 configure.ac  |  15 ++-
 include/drm/Makefile.am   |   1 +
 include/drm/tegra_drm.h   |  48 ++
 tegra/Makefile.am |  17 
 tegra/libdrm_tegra.pc.in  |  11 +++
 tegra/tegra.c | 227 ++
 tegra/tegra.h |  51 +++
 tests/modetest/modetest.c |   2 +-
 tests/vbltest/vbltest.c   |   2 +-
 10 files changed, 376 insertions(+), 4 deletions(-)
 create mode 100644 include/drm/tegra_drm.h
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra.c
 create mode 100644 tegra/tegra.h

-- 
1.8.0.1

[PATCH] drm: Make the HPD status updates debug logs more readable

2012-12-04 Thread Damien Lespiau

From: Damien Lespiau 

Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fe719f..8b963fd 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1043,6 +1043,18 @@ void drm_kms_helper_poll_fini(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_fini);

+static const char *connector_status_str(enum drm_connector_status status)
+{
+   switch (status) {
+   case connector_status_connected:
+   return "connected";
+   case connector_status_disconnected:
+   return "disconnected";
+   default:
+   return "unknown";
+   }
+}
+
 void drm_helper_hpd_irq_event(struct drm_device *dev)
 {
struct drm_connector *connector;
@@ -1062,10 +1074,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
old_status = connector->status;

connector->status = connector->funcs->detect(connector, false);
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
%s\n",
  connector->base.id,
  drm_get_connector_name(connector),
- old_status, connector->status);
+ connector_status_str(old_status),
+ connector_status_str(connector->status));
if (old_status != connector->status)
changed = true;
}
-- 
1.7.11.7

[Bug 36554] Amnesia game causes black screen or kernel locks

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

Scott Moreau  changed:

   What|Removed |Added

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

--- Comment #12 from Scott Moreau  ---
(In reply to comment #10)
> Do you have still the same problem with current mesa ? On my rv350 works
> good.

Hi, thanks for testing. I have tried again with xubuntu 12.04:

Kernel: 3.5.0-18-generic
OpenGL version string: 2.1 Mesa 9.1-devel

It runs and does not lock up the machine. However, most textures are black. The
output complains about too many ALU instructions and uses a dummy shader. The
bug in this report is resolved so I'm closing it for now.

-- 
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/20121204/d1af243a/attachment.html>

[PATCH] drm/exynos: enable iommu for mixer and not hdmi

> hdata->dev);
> -
> -   drm_iommu_detach_device(drm_dev, hdata->dev);
> -   }
> -
> -   return 0;
> -}
> -
>  static void hdmi_mode_fixup(void *ctx, struct drm_connector *connector,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> @@ -2122,7 +2100,6 @@ static struct exynos_hdmi_ops hdmi_ops = {
> .check_timing   = hdmi_check_timing,
>
> /* manager */
> -   .iommu_on   = hdmi_iommu_on,
> .mode_fixup = hdmi_mode_fixup,
> .mode_set   = hdmi_mode_set,
> .get_max_resol  = hdmi_get_max_resol,
> @@ -2379,7 +2356,6 @@ static int __devinit hdmi_probe(struct
> platform_device *pdev)
> mutex_init(>hdmi_mutex);
>
> drm_hdmi_ctx->ctx = (void *)hdata;
> -   hdata->parent_ctx = (void *)drm_hdmi_ctx;
>

this one.


>
> platform_set_drvdata(pdev, drm_hdmi_ctx);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 614b2e9..574ed3f 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -36,6 +36,7 @@
>
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_hdmi.h"
> +#include "exynos_drm_iommu.h"
>
>  #define get_mixer_context(dev)
> platform_get_drvdata(to_platform_device(dev))
>
> @@ -80,6 +81,7 @@ enum mixer_version_id {
>
>  struct mixer_context {
> struct device   *dev;
> +   struct drm_device   *drm_dev;
> int pipe;
> boolinterlace;
> boolpowered;
> @@ -90,6 +92,7 @@ struct mixer_context {
> struct mixer_resources  mixer_res;
> struct hdmi_win_datawin_data[MIXER_WIN_NR];
> enum mixer_version_id   mxr_ver;
> +   void*parent_ctx;
>  };
>
>  struct mixer_drv_data {
> @@ -665,6 +668,24 @@ static void mixer_win_reset(struct mixer_context *ctx)
> spin_unlock_irqrestore(>reg_slock, flags);
>  }
>
> +static int mixer_iommu_on(void *ctx, bool enable)
> +{
> +   struct exynos_drm_hdmi_context *drm_hdmi_ctx;
> +   struct mixer_context *mdata = ctx;
> +   struct drm_device *drm_dev;
> +
> +   drm_hdmi_ctx = mdata->parent_ctx;
> +   drm_dev = drm_hdmi_ctx->drm_dev;
> +
> +   if (is_drm_iommu_supported(drm_dev)) {
> +   if (enable)
> +   return drm_iommu_attach_device(drm_dev,
> mdata->dev);
> +
> +   drm_iommu_detach_device(drm_dev, mdata->dev);
> +   }
> +   return 0;
> +}
> +
>  static void mixer_poweron(struct mixer_context *ctx)
>  {
> struct mixer_resources *res = >mixer_res;
> @@ -866,6 +887,7 @@ static void mixer_win_disable(void *ctx, int win)
>
>  static struct exynos_mixer_ops mixer_ops = {
> /* manager */
> +   .iommu_on   = mixer_iommu_on,
> .enable_vblank  = mixer_enable_vblank,
> .disable_vblank = mixer_disable_vblank,
> .dpms   = mixer_dpms,
> @@ -1149,6 +1171,7 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
> }
>
> ctx->dev = >dev;
> +   ctx->parent_ctx = (void *)drm_hdmi_ctx;
> drm_hdmi_ctx->ctx = (void *)ctx;
> ctx->vp_enabled = drv->is_vp_enabled;
> ctx->mxr_ver = drv->version;
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5f8a7a94/attachment-0001.html>

[PATCH v2] drm/exynos: add iommu support for hdmi driver

Changelog v2:
move iommu support feature to mixer side.
And below is Prathyush's comment.

According to the new IOMMU framework for exynos sysmmus,
the owner of the sysmmu-tv is mixer (which is the actual
device that does DMA) and not hdmi.
The mmu-master in sysmmu-tv node is set as below in exynos5250.dtsi
sysmmu-tv {
-
mmu-master = <>;
};

Changelog v1:
The iommu will be enabled when hdmi sub driver is probed and
will be disabled when removed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   15 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c|   23 +++
 4 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index c3b9e2b..2d11e70 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -346,9 +346,23 @@ static int hdmi_subdrv_probe(struct drm_device *drm_dev,
ctx->hdmi_ctx->drm_dev = drm_dev;
ctx->mixer_ctx->drm_dev = drm_dev;

+   if (mixer_ops->iommu_on)
+   mixer_ops->iommu_on(ctx->mixer_ctx->ctx, true);
+
return 0;
 }

+static void hdmi_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
+{
+   struct drm_hdmi_context *ctx;
+   struct exynos_drm_subdrv *subdrv = to_subdrv(dev);
+
+   ctx = get_ctx_from_subdrv(subdrv);
+
+   if (mixer_ops->iommu_on)
+   mixer_ops->iommu_on(ctx->mixer_ctx->ctx, false);
+}
+
 static int __devinit exynos_drm_hdmi_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -368,6 +382,7 @@ static int __devinit exynos_drm_hdmi_probe(struct 
platform_device *pdev)
subdrv->dev = dev;
subdrv->manager = _manager;
subdrv->probe = hdmi_subdrv_probe;
+   subdrv->remove = hdmi_subdrv_remove;

platform_set_drvdata(pdev, subdrv);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 2da5ffd..54b5223 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -62,6 +62,7 @@ struct exynos_hdmi_ops {

 struct exynos_mixer_ops {
/* manager */
+   int (*iommu_on)(void *ctx, bool enable);
int (*enable_vblank)(void *ctx, int pipe);
void (*disable_vblank)(void *ctx);
void (*dpms)(void *ctx, int mode);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..c73f438 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -74,6 +74,7 @@ struct hdmi_context {
struct mutexhdmi_mutex;

void __iomem*regs;
+   void*parent_ctx;
int external_irq;
int internal_irq;

@@ -84,7 +85,6 @@ struct hdmi_context {
int cur_conf;

struct hdmi_resources   res;
-   void*parent_ctx;

int hpd_gpio;

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0d3ed28..50100cf 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -36,6 +36,7 @@

 #include "exynos_drm_drv.h"
 #include "exynos_drm_hdmi.h"
+#include "exynos_drm_iommu.h"

 #define get_mixer_context(dev) platform_get_drvdata(to_platform_device(dev))

@@ -80,6 +81,7 @@ enum mixer_version_id {

 struct mixer_context {
struct device   *dev;
+   struct drm_device   *drm_dev;
int pipe;
boolinterlace;
boolpowered;
@@ -90,6 +92,7 @@ struct mixer_context {
struct mixer_resources  mixer_res;
struct hdmi_win_datawin_data[MIXER_WIN_NR];
enum mixer_version_id   mxr_ver;
+   void*parent_ctx;
 };

 struct mixer_drv_data {
@@ -665,6 +668,24 @@ static void mixer_win_reset(struct mixer_context *ctx)
spin_unlock_irqrestore(>reg_slock, flags);
 }

+static int mixer_iommu_on(void *ctx, bool enable)
+{
+   struct exynos_drm_hdmi_context *drm_hdmi_ctx;
+   struct mixer_context *mdata = ctx;
+   struct drm_device *drm_dev;
+
+   drm_hdmi_ctx = mdata->parent_ctx;
+   drm_dev = drm_hdmi_ctx->drm_dev;
+
+   if (is_drm_iommu_supported(drm_dev)) {
+   if (enable)
+   return drm_iommu_attach_device(drm_dev, mdata->dev);
+
+   drm_iommu_detach_device(drm_dev, mdata->dev);
+   }
+   return 0;
+}
+
 static void mixer_poweron(struct mixer_context *ctx)
 {
struct mixer_resources *res = >mixer_res;

[PATCH] drm/exynos: enable iommu for mixer and not hdmi

m_dev;
> -
> -   if (is_drm_iommu_supported(drm_dev)) {
> -   if (enable)
> -   return drm_iommu_attach_device(drm_dev,
> hdata->dev);
> -
> -   drm_iommu_detach_device(drm_dev, hdata->dev);
> -   }
> -
> -   return 0;
> -}
> -
>  static void hdmi_mode_fixup(void *ctx, struct drm_connector *connector,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> @@ -2122,7 +2100,6 @@ static struct exynos_hdmi_ops hdmi_ops = {
> .check_timing   = hdmi_check_timing,
>
> /* manager */
> -   .iommu_on   = hdmi_iommu_on,
> .mode_fixup = hdmi_mode_fixup,
> .mode_set   = hdmi_mode_set,
> .get_max_resol  = hdmi_get_max_resol,
> @@ -2379,7 +2356,6 @@ static int __devinit hdmi_probe(struct
> platform_device *pdev)
> mutex_init(>hdmi_mutex);
>
> drm_hdmi_ctx->ctx = (void *)hdata;
> -   hdata->parent_ctx = (void *)drm_hdmi_ctx;
>
> platform_set_drvdata(pdev, drm_hdmi_ctx);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 614b2e9..574ed3f 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -36,6 +36,7 @@
>
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_hdmi.h"
> +#include "exynos_drm_iommu.h"
>
>  #define get_mixer_context(dev)
> platform_get_drvdata(to_platform_device(dev))
>
> @@ -80,6 +81,7 @@ enum mixer_version_id {
>
>  struct mixer_context {
> struct device   *dev;
> +   struct drm_device   *drm_dev;
> int pipe;
> boolinterlace;
> boolpowered;
> @@ -90,6 +92,7 @@ struct mixer_context {
> struct mixer_resources  mixer_res;
> struct hdmi_win_datawin_data[MIXER_WIN_NR];
> enum mixer_version_id   mxr_ver;
> +   void*parent_ctx;
>  };
>
>  struct mixer_drv_data {
> @@ -665,6 +668,24 @@ static void mixer_win_reset(struct mixer_context *ctx)
> spin_unlock_irqrestore(>reg_slock, flags);
>  }
>
> +static int mixer_iommu_on(void *ctx, bool enable)
> +{
> +   struct exynos_drm_hdmi_context *drm_hdmi_ctx;
> +   struct mixer_context *mdata = ctx;
> +   struct drm_device *drm_dev;
> +
> +   drm_hdmi_ctx = mdata->parent_ctx;
> +   drm_dev = drm_hdmi_ctx->drm_dev;
> +
> +   if (is_drm_iommu_supported(drm_dev)) {
> +   if (enable)
> +   return drm_iommu_attach_device(drm_dev,
> mdata->dev);
> +
> +   drm_iommu_detach_device(drm_dev, mdata->dev);
> +   }
> +   return 0;
> +}
> +
>  static void mixer_poweron(struct mixer_context *ctx)
>  {
> struct mixer_resources *res = >mixer_res;
> @@ -866,6 +887,7 @@ static void mixer_win_disable(void *ctx, int win)
>
>  static struct exynos_mixer_ops mixer_ops = {
> /* manager */
> +   .iommu_on   = mixer_iommu_on,
> .enable_vblank  = mixer_enable_vblank,
> .disable_vblank = mixer_disable_vblank,
> .dpms   = mixer_dpms,
> @@ -1149,6 +1171,7 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
> }
>
> ctx->dev = >dev;
> +   ctx->parent_ctx = (void *)drm_hdmi_ctx;
> drm_hdmi_ctx->ctx = (void *)ctx;
> ctx->vp_enabled = drv->is_vp_enabled;
> ctx->mxr_ver = drv->version;
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/170f18c4/attachment-0001.html>

[PATCH v2] drm/exynos: create new sgt from existing sgt

2012/12/3 Prathyush K 

> Changelog v2:
>
> Implement copy sgt code in exynos_get_sgt itself instead of calling
> sg_clone_table.
>
>
Now we are working on dmabuf feature update that adds attach and detach
callbacks and with this patch, exynos_get_sgt function will be removed.
For this, please refer to the below link,

http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git;a=commit;h=a9626efd74cb9133d31f4f42e16a59d3e2cfb03e

And this patch would resolve the performance deterioration to v4l2's
streaming service.
The performance issue are induced when v4l2's qbuf and dqbuf are called
repeatedly with gem buffer imported.(dmabuf fd -> vb2 buffer)
So unmapping would be done by dma_buf_detach instead of
dma_buf_unmap_attachment.
For this, we are testing it and if works fine then this patch will be
posted.


> Changelog v1:
>
> During map_dma_buf, a new sgt needs to be created before being mapped to
> another device's address space. Currently, this sgt is created by calling
> dma_get_sgtable which creates a sgt from pages. This will be time consuming
> if the map/unmap calls are done repeatedly for very large buffers.
>
> Instead, we can just use the sgt which was already created during
> buffer allocation and create the new sgt by copying the sgls from the
> existing sgt.
>
> And this patch is based on exynos-drm-next-iommu branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
>
> Signed-off-by: Prathyush K 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |   18 +++---
>  1 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> index d9307bd..91c7db1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -34,19 +34,31 @@ static struct sg_table *exynos_get_sgt(struct
> drm_device *drm_dev,
> struct exynos_drm_gem_buf *buf)
>  {
> struct sg_table *sgt = NULL;
> +   struct scatterlist *s, *s_out;
> +   unsigned int i;
> int ret;
>
> +   if (!buf->sgt) {
> +   DRM_ERROR("no sg table.\n");
> +   goto out;
> +   }
> +
> sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> if (!sgt)
> goto out;
>
> -   ret = dma_get_sgtable(drm_dev->dev, sgt, buf->kvaddr,
> -   buf->dma_addr, buf->size);
> +   ret = sg_alloc_table(sgt, buf->sgt->orig_nents, GFP_KERNEL);
> if (ret < 0) {
> -   DRM_ERROR("failed to get sgtable.\n");
> +   DRM_ERROR("failed to alloc table\n");
> goto err_free_sgt;
> }
>
> +   s_out = sgt->sgl;
> +   for_each_sg(buf->sgt->sgl, s, buf->sgt->orig_nents, i) {
> +   sg_set_page(s_out, sg_page(s), s->length, s->offset);
> +   s_out = sg_next(s_out);
> +   }
> +
> return sgt;
>
>  err_free_sgt:
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5e766406/attachment.html>

[PATCH] drm/omap: use omapdss low level API

2012-12-04 Thread Rob Clark

This patch changes the omapdrm KMS to bypass the omapdss "compat"
layer and use the core omapdss API directly.  This solves some layering
issues that would cause unpin confusion vs GO bit status, because we
would not know whether a particular pageflip or overlay update has hit
the screen or not.  Now instead we explicitly manage the GO bits in
dispc and handle the vblank/framedone interrupts ourself so that we
always know which buffers are being scanned out at any given time, and
so on.

As an added bonus, we no longer leave the last overlay buffer pinned
when the display is disabled, and have been able to add the previously
missing vblank event handling.

v1: original
v2: rebased on latest staging-next and omapdss patches from Tomi and
review comments from Archit Taneja

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/Makefile |   1 +
 drivers/staging/omapdrm/TODO |   3 -
 drivers/staging/omapdrm/omap_connector.c | 111 +--
 drivers/staging/omapdrm/omap_crtc.c  | 507 +++
 drivers/staging/omapdrm/omap_drv.c   | 439 +-
 drivers/staging/omapdrm/omap_drv.h   | 140 +++--
 drivers/staging/omapdrm/omap_encoder.c   | 132 
 drivers/staging/omapdrm/omap_irq.c   | 322 
 drivers/staging/omapdrm/omap_plane.c | 452 +++
 9 files changed, 1214 insertions(+), 893 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_irq.c

diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 1ca0e00..d85e058 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -5,6 +5,7 @@

 ccflags-y := -Iinclude/drm -Werror
 omapdrm-y := omap_drv.o \
+   omap_irq.o \
omap_debugfs.o \
omap_crtc.o \
omap_plane.o \
diff --git a/drivers/staging/omapdrm/TODO b/drivers/staging/omapdrm/TODO
index 938c788..abeeb00 100644
--- a/drivers/staging/omapdrm/TODO
+++ b/drivers/staging/omapdrm/TODO
@@ -17,9 +17,6 @@ TODO
 . Revisit GEM sync object infrastructure.. TTM has some framework for this
   already.  Possibly this could be refactored out and made more common?
   There should be some way to do this with less wheel-reinvention.
-. Review DSS vs KMS mismatches.  The omap_dss_device is sort of part encoder,
-  part connector.  Which results in a bit of duct tape to fwd calls from
-  encoder to connector.  Possibly this could be done a bit better.
 . Solve PM sequencing on resume.  DMM/TILER must be reloaded before any
   access is made from any component in the system.  Which means on suspend
   CRTC's should be disabled, and on resume the LUT should be reprogrammed
diff --git a/drivers/staging/omapdrm/omap_connector.c 
b/drivers/staging/omapdrm/omap_connector.c
index 91edb3f..4cc9ee7 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -31,9 +31,10 @@
 struct omap_connector {
struct drm_connector base;
struct omap_dss_device *dssdev;
+   struct drm_encoder *encoder;
 };

-static inline void copy_timings_omap_to_drm(struct drm_display_mode *mode,
+void copy_timings_omap_to_drm(struct drm_display_mode *mode,
struct omap_video_timings *timings)
 {
mode->clock = timings->pixel_clock;
@@ -64,7 +65,7 @@ static inline void copy_timings_omap_to_drm(struct 
drm_display_mode *mode,
mode->flags |= DRM_MODE_FLAG_NVSYNC;
 }

-static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings,
+void copy_timings_drm_to_omap(struct omap_video_timings *timings,
struct drm_display_mode *mode)
 {
timings->pixel_clock = mode->clock;
@@ -96,48 +97,7 @@ static inline void copy_timings_drm_to_omap(struct 
omap_video_timings *timings,
timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
 }

-static void omap_connector_dpms(struct drm_connector *connector, int mode)
-{
-   struct omap_connector *omap_connector = to_omap_connector(connector);
-   struct omap_dss_device *dssdev = omap_connector->dssdev;
-   int old_dpms;
-
-   DBG("%s: %d", dssdev->name, mode);
-
-   old_dpms = connector->dpms;
-
-   /* from off to on, do from crtc to connector */
-   if (mode < old_dpms)
-   drm_helper_connector_dpms(connector, mode);
-
-   if (mode == DRM_MODE_DPMS_ON) {
-   /* store resume info for suspended displays */
-   switch (dssdev->state) {
-   case OMAP_DSS_DISPLAY_SUSPENDED:
-   dssdev->activate_after_resume = true;
-   break;
-   case OMAP_DSS_DISPLAY_DISABLED: {
-   int ret = dssdev->driver->enable(dssdev);
-   if (ret) {
-   DBG("%s: failed to enable: %d",
-   dssdev->name, ret);
-

i915 freakout with latest 3.7 git

On Tue, Dec 04, 2012 at 01:35:22PM +0100, Heinz Diehl wrote:
> On 04.12.2012, Daniel Vetter wrote: 
> 
> > Yeah, if anyone can somewhat reliably reproduce this
> 
> Ok, I see. So the beginning would be to reliably reproduce the the
> hang. I have encountered it in any possbile situasjon, both when
> watching videos on Youtube and right after booting the machine and
> doing absolutely nothing.
> 
> I'll try around a little bit and see if I can find something that
> triggers this hang. 
> 
> Btw: which kernel is known to be the "last good one"?

If it's the ilk one we only know that 3.6.x series seems to be solid, and
something in 3.7-rc (probably before -rc1) broke stuff. So not too useful.

> > (you need to disable rc6 on ilk to not hit another issue which seems much 
> > easier to
> > hit) 
> 
> Ilk? If this stands for "Ironlake": I'm on Sandybridge.

Hm, then it could very well be something different, so I think we need to
track this one as a separate bug. Can you please file a new one on
bugs.freedesktop.org against DRI -> DRM (Intel) and attach dmesg when
booting with drm.debug=0xe (just so we know what's in your box) plus the
i915_error_state from debugfs once the gpu is hung (if you can get at that
file, reboot kills it).

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

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

--- Comment #3 from Piero Finizio  ---
Yes, reverting commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 works.

-- 
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/20121204/e6ba0598/attachment.html>

i915 freakout with latest 3.7 git

On 04.12.2012, Daniel Vetter wrote: 

> Yeah, if anyone can somewhat reliably reproduce this

Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing absolutely nothing.

I'll try around a little bit and see if I can find something that
triggers this hang. 

Btw: which kernel is known to be the "last good one"?

> (you need to disable rc6 on ilk to not hit another issue which seems much 
> easier to
> hit) 

Ilk? If this stands for "Ironlake": I'm on Sandybridge.

> and bisect it, this would be _very_ much appreciated - we've
> pretty much tested all possible "disable stuff" and "revert random
> patch" we could thing of, and we can't reproduce these hangs no matter
> how hard we bang our heads against this.

Bisecting will be a pain without being able to reproduce
the hang reliably.

> Atm we're trying to come up with ways to dump more debug
> information, >but with no clue whatsoever what's going on that's slow-going.

Is there anything at the moment I can do to help you to get a grip on
this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus
U45-JC). 

Heinz

[Bug 41051] Portal hard locks the machine on rv350.

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

--- Comment #2 from Scott Moreau  ---
(In reply to comment #1)
> Still you have the same problem ?

Yes, it's still the same problem with ubuntu 12.04, kernel 3.0.0, Mesa 9.1 and
wine 1.4.

-- 
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/20121204/ef1fb19d/attachment.html>

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

--- Comment #2 from Marek Ol??k  ---
Does reverting the commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 help?

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

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

--- Comment #1 from Piero Finizio  ---
Created attachment 70995
  --> https://bugs.freedesktop.org/attachment.cgi?id=70995=edit
The "blue triangles"

-- 
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/20121204/e0a0613f/attachment.html>

[Bug 57875] New: Second Life viewer bad rendering with git-ec83535

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

  Priority: medium
Bug ID: 57875
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Second Life viewer bad rendering with git-ec83535
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: andabata12 at yahoo.it
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/Gallium/r300
   Product: Mesa

With git  "HEAD at ec83535 automake/gallium: attempt to fix -lrt", Cool VL
Viewer a TPV for Second Life 3D world  ( the official Linden Lab viewer is from
ages blocked cause of https://bugs.freedesktop.org/show_bug.cgi?id=39251 ) can
set only basic shaders otherwise with atmospheric, water and reflections
shaders enabled, I have extensive blue triangles  during the execution.
On the contrary with graphics drivers from git-54ff536 ( HyperZ enabled by
default) all was right  with smooth rendering, lowered cpu usage and augmented
framerate ( 8-10 %).

-- 
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/20121204/f1437b97/attachment.html>

[PATCH] drm: tegra: Use framebuffer pitch as line stride

On 12/04/2012 11:50 AM, Stephen Warren wrote:
> On 12/03/2012 08:00 PM, Mark Zhang wrote:
>> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
 On 11/27/2012 11:17 AM, Stephen Warren wrote:
> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
 Instead of using the stride derived from the display mode, use the 
 pitch
 associated with the currently active framebuffer. This fixes a bug 
 where
 the LCD display content would be skewed when enabling HDMI with a video
 mode different from that of the LCD.
>>>
>>> This patch certainly doesn't cause any additional issues for me, so:
>>>
>>> Tested-by: Stephen Warren 
>>>
>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external
>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or
>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
>>> are active, then some kind of display corruption starts; it looks like a
>>> clocking issue or perhaps memory underflow.
>>
>> I haven't observed this issue. What kind of display corruption you mean?
>> Did it recover after some seconds or the display in LVDS panel was
>> always corrupted?
>>
>> During my testing, I connected HDMI while booting cardhu and I can see
>> the LVDS and HDMI working with no corruptions.
>
> For your viewing pleasure (and playing with my new phone) :-)
> http://www.youtube.com/watch?v=ZJxJnONz7DA
>
> The external monitor is 1920x1200 I believe.

 Jon Mayo says the corruption in the video is display (memory fetch)
 underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
 programs the memory controller at a slow rate, and the bootloader and/or
 kernel is supposed to bump up the rate to the max, but that's not
 implemented anywhere yet upstream. If you're testing with "fastboot"
 instead of U-Boot, that might be re-programming the memory frequencies,
 and hence avoiding this.

>>>
>>> All right, I just test the framebuffer console and "xinit", I didn't
>>> install the whole ubuntu.
>>>
>>> I'll install the ubuntu in my cardhu and see whether I have this kind of
>>> issues.
>>
>> Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue
>> you described. The display worked with no corruptions. I can show you
>> the video if you want.
>>
>> What I used for testing is a cardhu board with our downstream U-Boot.
>>
>> But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY
>> THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080 at 60HZ". So
>> sounds like the clock setting has some problems... I'll have a look at this.
> 
> Oh, I thought I'd followed up on this - Jon Mayo said it was display
> underflow due to lack of memory bandwidth. IIRC, this may be due to the
> BCT programming the memory controller for conservative settings that
> don't require non-default voltages from the PMIC, with the expectation
> that the bootloader or kernel will reprogram everything for correct
> performance.
> 

OK, I see. But my HDMI doesn't work so I will spend some time digging it.

Mark

[Bug 39308] mplayer -vo vdpau draws incorrectly on rv350

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

--- Comment #6 from Tomasz P.  ---
(In reply to comment #4)
> I don't have full access to my old machine with the rv350 anymore (I gave it
> to my father), but I'll try to test vdpau on it. If I don't answer in a
> month, feel free to close this bug (assuming it works for you).

I read a title only and checked only "mplayer -vo vdpau" variant. I forgot that
it's only with software decoding.With "-vc ffmpeg12vdpau" indeed not
working.Sorry for noise.

-- 
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/20121204/76afc31e/attachment.html>

[PATCH] drm: tegra: Use framebuffer pitch as line stride

On 11/28/2012 02:37 PM, Mark Zhang wrote:
> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
 On 11/27/2012 06:37 AM, Stephen Warren wrote:
> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>> Instead of using the stride derived from the display mode, use the pitch
>> associated with the currently active framebuffer. This fixes a bug where
>> the LCD display content would be skewed when enabling HDMI with a video
>> mode different from that of the LCD.
>
> This patch certainly doesn't cause any additional issues for me, so:
>
> Tested-by: Stephen Warren 
>
> Howwever, it still doesn't allow both Cardhu's LCD panel and external
> HDMI port (1080p) to be active at once. If I boot with both enabled, or
> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
> are active, then some kind of display corruption starts; it looks like a
> clocking issue or perhaps memory underflow.

 I haven't observed this issue. What kind of display corruption you mean?
 Did it recover after some seconds or the display in LVDS panel was
 always corrupted?

 During my testing, I connected HDMI while booting cardhu and I can see
 the LVDS and HDMI working with no corruptions.
>>>
>>> For your viewing pleasure (and playing with my new phone) :-)
>>> http://www.youtube.com/watch?v=ZJxJnONz7DA
>>>
>>> The external monitor is 1920x1200 I believe.
>>
>> Jon Mayo says the corruption in the video is display (memory fetch)
>> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
>> programs the memory controller at a slow rate, and the bootloader and/or
>> kernel is supposed to bump up the rate to the max, but that's not
>> implemented anywhere yet upstream. If you're testing with "fastboot"
>> instead of U-Boot, that might be re-programming the memory frequencies,
>> and hence avoiding this.
>>
> 
> All right, I just test the framebuffer console and "xinit", I didn't
> install the whole ubuntu.
> 
> I'll install the ubuntu in my cardhu and see whether I have this kind of
> issues.

Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue
you described. The display worked with no corruptions. I can show you
the video if you want.

What I used for testing is a cardhu board with our downstream U-Boot.

But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY
THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080 at 60HZ". So
sounds like the clock setting has some problems... I'll have a look at this.

Mark
> 
> Mark
>> I guess we have a fun time ahead of us with mode validation and memory
>> controller programming.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

i915 freakout with latest 3.7 git

On Tue, Dec 4, 2012 at 10:27 AM, Dave Airlie  wrote:
> On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl  wrote:
>> On 03.12.2012, devendra.aaru wrote:
>>
>>> Add more CC's
>>
>> Thanks!
>>
>> This is a real showstopper for me, it occurs in every session now.
>> Booting with "i915.i915_enable_rc6=0" doesn't help
>
> https://bugs.freedesktop.org/show_bug.cgi?id=55984
>
> intel guys are as lost as anyone.

Yeah, if anyone can somewhat reliably reproduce this (you need to
disable rc6 on ilk to not hit another issue which seems much easier to
hit) and bisect it, this would be _very_ much appreciated - we've
pretty much tested all possible "disable stuff" and "revert random
patch" we could thing of, and we can't reproduce these hangs no matter
how hard we bang our heads against this. Atm we're trying to come up
with ways to dump more debug information, but with no clue whatsoever
what's going on that's slow-going.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC v2 1/8] video: tegra: Add nvhost driver

On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
> 
> One other thing that such a design can help with is refactoring common
> code or parameterizing code. Maybe newer generations are not compatible
> but can easily be made to work with existing code by introducing a
> variable such as register stride or something.
> 
> What's really difficult to follow is if an ops structure is accessed via
> some global macro. It also breaks encapsulation because you have a
> global ops structure. That may even work fine for now, but it will break
> once you have more than a single host1x in a system. I know this will
> never happen, but all of a sudden it happens anyway and the code breaks.
> Doing this right isn't very hard and it will lead to a better design and
> is less likely to break at some point.
> 

Sorry I forget to reply this in last mail...

Agree. Even for userspace programs, we should avoid using global
variables as possible as we can. So we need to think about this and try
to reduce the number of global vars.

Mark
> Thierry
> 
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[RFC v2 1/8] video: tegra: Add nvhost driver

On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
>> I think there's room for letting Terje's complete knowledge of future
>> chips guide the design of the current code that's sent upstream.
>> Certainly we shouldn't add a ton of unnecessary abstraction layers
>> right now that aren't needed for Tegra20/30, but if there's some
>> decision that doesn't affect the bloat, opaqueness, ... of the current
>> code but one choice is better for future development without serious
>> negatives for the current code, it's pretty reasonable to make that
>> decision rather than the other.
> 
> The original point was that the current design stashes every function of
> host1x into an ops structure and you have to go through those ops to get
> at the functionality. I can understand the need to add an ops structure
> to cope with incompatibilities between versions, but as you say there
> should to be a reason for them being introduced. If such reasons exists,
> then I think they at least warrant a comment somewhere.
> 
> Furthermore this is usually best handled by wrapping the ops accesses in
> a public API, so that the ops structure can be hidden within the driver.
> For example, submitting a job to a channel should have a public API such
> as:
> 
>   int host1x_channel_submit(struct host1x_channel *channel,
> struct host1x_job *job)
>   {
>   ...
>   }
> 
> An initial implementation would just add the code into this function. If
> it turns out some future version requires special incantations to submit
> a job, only then should we introduce an ops structure, with only the one
> function:
> 
>   struct host1x_channel_ops {
>   int (*submit)(struct host1x_channel *channel,
> struct host1x_job *job);
>   };
> 
> But since only the public API above has been used, access to the special
> implementation can be hidden from the user. So the public function could
> be modified in this way:
> 
>   int host1x_channel_submit(struct hostx1_channel *channel,
> struct host1x_job *job)
>   {
>   if (channel->ops && channel->ops->submit)
>   return channel->ops->submit(channel, job);
> 
>   ...
>   }
> 

I guess we do this in exactly this way at the beginning. Then we
realized that we need to define callbacks to make different tegra has
different logics. So that's why we see the codes have lots of function
ops right now.

If so, this will make Terje modify the code back to the original
version, and this is not an interesting work.

Just my personal guess, no offence.

Mark
> And then you have two choices: either you keep the code for previous
> generations after the if block or you provide a separate ops structure
> for older generations as well and handle them via the same code path.
> 
> One other thing that such a design can help with is refactoring common
> code or parameterizing code. Maybe newer generations are not compatible
> but can easily be made to work with existing code by introducing a
> variable such as register stride or something.
> 
> What's really difficult to follow is if an ops structure is accessed via
> some global macro. It also breaks encapsulation because you have a
> global ops structure. That may even work fine for now, but it will break
> once you have more than a single host1x in a system. I know this will
> never happen, but all of a sudden it happens anyway and the code breaks.
> Doing this right isn't very hard and it will lead to a better design and
> is less likely to break at some point.
> 
> Thierry
> 
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[RFC v2 8/8] drm: tegra: Add gr2d device

On 12/03/2012 05:40 PM, Daniel Vetter wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang  wrote:
>> I'm new in kernel development. Could you tell me or give me some
>> materials to read that why we need to align the size of IOCTL structures
>> to 64bit? I can understand if we're working in a 64bit kernel but why we
>> need to do this if we're in a 32bit arm kernel? Besides, why the
>> pointers in IOCTL structure should be declared as u64?
> 
> Because in a few years/months you'll have arm64, but still the same
> driver with the same ioctls ... and if the ioctls are not _exactly_
> the same you get to write compat ioctl code which copies the old 32bit
> struct into the 64bit struct the kernel understands. Hence your ioctl
> must be laid out exactly the same for both 32bit and 64bit, which
> happens if you naturally align/pad everything to 64bits and only use
> fixed-sized integers and no pointers.

Ah, I see. Thanks. Yes, u64 still works as 32 bit pointer.

Mark
> -Daniel
>

i915 freakout with latest 3.7 git

On 03.12.2012, devendra.aaru wrote: 

> Add more CC's

Thanks!

This is a real showstopper for me, it occurs in every session now. 
Booting with "i915.i915_enable_rc6=0" doesn't help either..

[RFC libdrm] Add NVIDIA Tegra support

2012-12-04 Thread Rob Clark

On Tue, Dec 4, 2012 at 9:13 AM, Thierry Reding
 wrote:
> +int drm_tegra_bo_new(struct drm_tegra *device, uint32_t flags, uint32_t size,
> +struct drm_tegra_bo **bop)
> +{
> +   struct drm_tegra_gem_create args;
> +   struct drm_tegra_bo *bo;
> +   struct tegra_bo *priv;
> +   int err;
> +
> +   if (!device || size == 0 || !bop)
> +   return -EINVAL;
> +
> +   bo = calloc(1, sizeof(*bo));
> +   if (!bo)
> +   return -ENOMEM;
> +
> +   priv = tegra_bo(bo);
> +
> +   DRMLISTINITHEAD(>list);
> +   atomic_set(>ref, 1);
> +   bo->device = device;
> +   bo->flags = flags;
> +   bo->size = size;
> +
> +   memset(, 0, sizeof(args));
> +   args.flags = flags;
> +   args.size = size;
> +
> +   err = drmCommandWriteRead(device->fd, DRM_TEGRA_GEM_CREATE, ,
> + sizeof(args));
> +   if (err < 0) {
> +   err = -errno;
> +   free(bo);
> +   return err;
> +   }
> +
> +   DRMLISTADD(>list, >bo_list);
> +   bo->handle = args.handle;
> +   bo->offset = args.offset;

btw, x11 can rapidly create/destroy temporary pixmaps.. which don't
necessarily need userspace access.  You might prefer to avoid creating
mmap offset on GEM bo creation, and instead do this only if userspace
needs to mmap the bo

BR,
-R

> +
> +   *bop = bo;
> +
> +   return 0;
> +}

[RFC v2 1/8] video: tegra: Add nvhost driver

2012-12-04 Thread Terje Bergström

On 03.12.2012 23:03, Thierry Reding wrote:
> What's really difficult to follow is if an ops structure is accessed via
> some global macro. It also breaks encapsulation because you have a
> global ops structure. That may even work fine for now, but it will break
> once you have more than a single host1x in a system. I know this will
> never happen, but all of a sudden it happens anyway and the code breaks.
> Doing this right isn't very hard and it will lead to a better design and
> is less likely to break at some point.

I agree that the chip ops access goes through too much indirection and
macro magic (which I already declared I hate), so we're going to design
something simpler.

Terje

[Bug 39308] mplayer -vo vdpau draws incorrectly on rv350

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

--- Comment #5 from Andy Furniss  ---
(In reply to comment #4)
> I don't have full access to my old machine with the rv350 anymore (I gave it
> to my father), but I'll try to test vdpau on it. If I don't answer in a
> month, feel free to close this bug (assuming it works for you).

mplayer -vo vdpau with software decode is working for me on rv350.

Decode with -vc ffmpeg12vdpau is still not working, though it did improve a bit
recently see -

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

-- 
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/20121204/63254344/attachment.html>

[Bug 36554] Amnesia game causes black screen or kernel locks

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

--- Comment #11 from Scott Moreau  ---
(In reply to comment #10)
> Do you have still the same problem with current mesa ? On my rv350 works
> good.

Can you say what distro, kernel and mesa version you're using?

-- 
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/20121204/20c8b80f/attachment.html>

Re: i915 freakout with latest 3.7 git

2012-12-04 Thread Dave Airlie

On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl h...@fancy-poultry.org wrote:
 On 03.12.2012, devendra.aaru wrote:

 Add more CC's

 Thanks!

 This is a real showstopper for me, it occurs in every session now.
 Booting with i915.i915_enable_rc6=0 doesn't help

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

intel guys are as lost as anyone.

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

Re: i915 freakout with latest 3.7 git

On Tue, Dec 4, 2012 at 10:27 AM, Dave Airlie airl...@gmail.com wrote:
 On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl h...@fancy-poultry.org wrote:
 On 03.12.2012, devendra.aaru wrote:

 Add more CC's

 Thanks!

 This is a real showstopper for me, it occurs in every session now.
 Booting with i915.i915_enable_rc6=0 doesn't help

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

 intel guys are as lost as anyone.

Yeah, if anyone can somewhat reliably reproduce this (you need to
disable rc6 on ilk to not hit another issue which seems much easier to
hit) and bisect it, this would be _very_ much appreciated - we've
pretty much tested all possible disable stuff and revert random
patch we could thing of, and we can't reproduce these hangs no matter
how hard we bang our heads against this. Atm we're trying to come up
with ways to dump more debug information, but with no clue whatsoever
what's going on that's slow-going.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39308] mplayer -vo vdpau draws incorrectly on rv350

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

--- Comment #6 from Tomasz P. son_of_the_osi...@interia.pl ---
(In reply to comment #4)
 I don't have full access to my old machine with the rv350 anymore (I gave it
 to my father), but I'll try to test vdpau on it. If I don't answer in a
 month, feel free to close this bug (assuming it works for you).

I read a title only and checked only mplayer -vo vdpau variant. I forgot that
it's only with software decoding.With -vc ffmpeg12vdpau indeed not
working.Sorry for noise.

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

[PATCH v2] drm/exynos: release fb pended by page flip

Changelog v2:
fix page fault issue.
- defer to unreference old fb to avoid page fault issue.
So with this fixup, new fb would be updated to hardware
prior to old fb unreferencing. And it removes unnecessary
patch, drm/exynos: Unreference fb in exynos_disable_plane()

Changelog v1:
This patch releases the fb pended by page flip after fbdev is
restored propely. And fixes invalid memory access when drm is
released while doing pageflip.

This patch makes fb's refcount to be increased when setcrtc and
pageflip are requested. In other words, it increases fb's refcount
only if dma is going to access memory region to fb and decreases
old fb's because the old fb isn't accessed by dma anymore.

This could guarantee releasing gem buffer to the fb after dma
access to the gem buffer has been completed.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   28 ++-
 5 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2efa4b0..b9c37eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,6 +32,7 @@
 #include exynos_drm_drv.h
 #include exynos_drm_encoder.h
 #include exynos_drm_plane.h
+#include exynos_drm_fb.h
 
 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc,\
drm_crtc)
@@ -139,8 +140,25 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
plane-crtc = crtc;
plane-fb = crtc-fb;
 
+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane-fb);
+
exynos_drm_fn_encoder(crtc, pipe, exynos_drm_encoder_crtc_pipe);
 
+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
return 0;
 }
 
@@ -169,8 +187,27 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
if (ret)
return ret;
 
+   plane-fb = crtc-fb;
+
+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane-fb);
+
exynos_drm_crtc_commit(crtc);
 
+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
return 0;
 }
 
@@ -243,7 +280,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 
crtc-fb = fb;
ret = exynos_drm_crtc_mode_set_base(crtc, crtc-x, crtc-y,
-   NULL);
+   old_fb);
if (ret) {
crtc-fb = old_fb;
 
@@ -254,6 +291,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 
goto out;
}
+
+   exynos_drm_fb_set_pending(old_fb, false);
+   exynos_drm_fb_set_pending(fb, true);
}
 out:
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 7190b64..7ed5507 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -45,11 +45,15 @@
  * @fb: drm framebuffer obejct.
  * @buf_cnt: a buffer count to drm framebuffer.
  * @exynos_gem_obj: array of exynos specific gem object containing a gem 
object.
+ * @pending: indicate whehter a fb was pended by page flip.
+ * if true, the fb should be released after fbdev is restored to avoid
+ * accessing invalid memory region.
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
unsigned intbuf_cnt;
struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
+   boolpending;
 };
 
 static int check_fb_gem_memory_type(struct drm_device *drm_dev,
@@ -278,6 +282,25 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return fb;
 }
 
+void exynos_drm_fb_set_pending(struct

Re: i915 freakout with latest 3.7 git

On 04.12.2012, Daniel Vetter wrote: 

 Yeah, if anyone can somewhat reliably reproduce this

Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing absolutely nothing.

I'll try around a little bit and see if I can find something that
triggers this hang. 

Btw: which kernel is known to be the last good one?

 (you need to disable rc6 on ilk to not hit another issue which seems much 
 easier to
 hit) 

Ilk? If this stands for Ironlake: I'm on Sandybridge.

 and bisect it, this would be _very_ much appreciated - we've
 pretty much tested all possible disable stuff and revert random
 patch we could thing of, and we can't reproduce these hangs no matter
 how hard we bang our heads against this.

Bisecting will be a pain without being able to reproduce
the hang reliably.

 Atm we're trying to come up with ways to dump more debug
 information, but with no clue whatsoever what's going on that's slow-going.

Is there anything at the moment I can do to help you to get a grip on
this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus
U45-JC). 

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

Re: i915 freakout with latest 3.7 git

On Tue, Dec 04, 2012 at 01:35:22PM +0100, Heinz Diehl wrote:
 On 04.12.2012, Daniel Vetter wrote: 
 
  Yeah, if anyone can somewhat reliably reproduce this
 
 Ok, I see. So the beginning would be to reliably reproduce the the
 hang. I have encountered it in any possbile situasjon, both when
 watching videos on Youtube and right after booting the machine and
 doing absolutely nothing.
 
 I'll try around a little bit and see if I can find something that
 triggers this hang. 
 
 Btw: which kernel is known to be the last good one?

If it's the ilk one we only know that 3.6.x series seems to be solid, and
something in 3.7-rc (probably before -rc1) broke stuff. So not too useful.

  (you need to disable rc6 on ilk to not hit another issue which seems much 
  easier to
  hit) 
 
 Ilk? If this stands for Ironlake: I'm on Sandybridge.

Hm, then it could very well be something different, so I think we need to
track this one as a separate bug. Can you please file a new one on
bugs.freedesktop.org against DRI - DRM (Intel) and attach dmesg when
booting with drm.debug=0xe (just so we know what's in your box) plus the
i915_error_state from debugfs once the gpu is hung (if you can get at that
file, reboot kills it).

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

Re: [PATCH v2] drm/exynos: release fb pended by page flip

On Tue, Dec 4, 2012 at 5:44 PM, Inki Dae inki@samsung.com wrote:

 Changelog v2:
 fix page fault issue.
 - defer to unreference old fb to avoid page fault issue.
 So with this fixup, new fb would be updated to hardware
 prior to old fb unreferencing. And it removes unnecessary
 patch, drm/exynos: Unreference fb in exynos_disable_plane()

 Changelog v1:
 This patch releases the fb pended by page flip after fbdev is
 restored propely. And fixes invalid memory access when drm is
 released while doing pageflip.

 This patch makes fb's refcount to be increased when setcrtc and
 pageflip are requested. In other words, it increases fb's refcount
 only if dma is going to access memory region to fb and decreases
 old fb's because the old fb isn't accessed by dma anymore.

 This could guarantee releasing gem buffer to the fb after dma
 access to the gem buffer has been completed.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42
 -
  drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
  drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
  drivers/gpu/drm/exynos/exynos_drm_plane.c |   28 ++-
  5 files changed, 106 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index 2efa4b0..b9c37eb 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -32,6 +32,7 @@
  #include exynos_drm_drv.h
  #include exynos_drm_encoder.h
  #include exynos_drm_plane.h
 +#include exynos_drm_fb.h

  #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc,\
 drm_crtc)
 @@ -139,8 +140,25 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
 struct drm_display_mode *mode,
 plane-crtc = crtc;
 plane-fb = crtc-fb;

 +   /*
 +* Take a reference to new fb.
 +*
 +* Taking a reference means that this plane's dma is going to
 access
 +* memory region to the new fb.
 +*/
 +   drm_framebuffer_reference(plane-fb);
 +


Hi Mr. Dae,

There is an issue with this approach.

Take this simple use case with just one crtc. (fbdev = fb0)

First, set fb1

we reference fb1 and unreference fb0.

Second, remove fb1

In this case, we are removing the current fb of the crtc
We hit the function 'drm_helper_disable_unused_functions'.
Here, we try to disable the crtc and then we set crtc-fb = NULL.
So the value of crtc-fb is lost.

After drm release, we restore fbdev mode.

Now we reference fb0 - but we fail to unreference fb1. (old_fb is NULL)

So fb1 never gets freed thus causing a memory leak.

I tested this with modetest and each time the fb/gem memory never gets
freed.

Also, another issue:

If a page flip is pending, you set the 'pending' flag and do not actually
unreference the fb.
And you are freeing that fb after fbdev is restored.

In a normal setup, we release DRM only during system shutdown i.e. we open
the drm
device during boot up and do not release drm till the end. But we keep page
flipping and removing
framebuffers all the time.

In this case, the pending fb memory does not get freed till we actually
release drm at the
very end.

I am not sure why this approach is required.
We are anyway waiting for vblank before removing a framebuffer so we can be
sure that
the dma has stopped accessing the fb. Right?

Regards,
Prathyush






 exynos_drm_fn_encoder(crtc, pipe, exynos_drm_encoder_crtc_pipe);

 +   /*
 +* If old_fb exists, unreference the fb.
 +*
 +* This means that memory region to the fb isn't accessed by the
 dma
 +* of this plane anymore.
 +*/
 +   if (old_fb)
 +   drm_framebuffer_unreference(old_fb);
 +
 return 0;
  }

 @@ -169,8 +187,27 @@ static int exynos_drm_crtc_mode_set_base(struct
 drm_crtc *crtc, int x, int y,
 if (ret)
 return ret;

 +   plane-fb = crtc-fb;
 +
 +   /*
 +* Take a reference to new fb.
 +*
 +* Taking a reference means that this plane's dma is going to
 access
 +* memory region to the new fb.
 +*/
 +   drm_framebuffer_reference(plane-fb);
 +
 exynos_drm_crtc_commit(crtc);

 +   /*
 +* If old_fb exists, unreference the fb.
 +*
 +* This means that memory region to the fb isn't accessed by the
 dma
 +* of this plane anymore.
 +*/
 +   if (old_fb)
 +   drm_framebuffer_unreference(old_fb);
 +
 return 0;
  }

 @@ -243,7 +280,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
 *crtc,

 crtc-fb = fb;
 ret = exynos_drm_crtc_mode_set_base(crtc, crtc-x, crtc-y,
 -

[Bug 57875] New: Second Life viewer bad rendering with git-ec83535

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

  Priority: medium
Bug ID: 57875
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Second Life viewer bad rendering with git-ec83535
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: andabat...@yahoo.it
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/Gallium/r300
   Product: Mesa

With git  HEAD at ec83535 automake/gallium: attempt to fix -lrt, Cool VL
Viewer a TPV for Second Life 3D world  ( the official Linden Lab viewer is from
ages blocked cause of https://bugs.freedesktop.org/show_bug.cgi?id=39251 ) can
set only basic shaders otherwise with atmospheric, water and reflections
shaders enabled, I have extensive blue triangles  during the execution.
On the contrary with graphics drivers from git-54ff536 ( HyperZ enabled by
default) all was right  with smooth rendering, lowered cpu usage and augmented
framerate ( 8-10 %).

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

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

--- Comment #1 from Piero Finizio andabat...@yahoo.it ---
Created attachment 70995
  -- https://bugs.freedesktop.org/attachment.cgi?id=70995action=edit
The blue triangles

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

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

--- Comment #2 from Marek Olšák mar...@gmail.com ---
Does reverting the commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 help?

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

[Bug 41051] Portal hard locks the machine on rv350.

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

--- Comment #2 from Scott Moreau ore...@gmail.com ---
(In reply to comment #1)
 Still you have the same problem ?

Yes, it's still the same problem with ubuntu 12.04, kernel 3.0.0, Mesa 9.1 and
wine 1.4.

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

Re: i915 freakout with latest 3.7 git

On 03.12.2012, devendra.aaru wrote: 

 Add more CC's

Thanks!

This is a real showstopper for me, it occurs in every session now. 
Booting with i915.i915_enable_rc6=0 doesn't help either..

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

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

--- Comment #3 from Piero Finizio andabat...@yahoo.it ---
Yes, reverting commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 works.

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

[PATCH 1/3] drm/exynos: modify wait for vsync functions to use wait queues

It is more optimium to use wait queues while waiting for vsync so
that the current task is put to sleep. This way, the task wont
hog the CPU while waiting. We use wait_event_timeout and not
an interruptible function since we dont want the function to exit
when a signal is pending (e.g. drm release). This patch modifies
the wait for vblank functions of both fimd and mixer.

Also, the current fimd wait_for_vblank did not work in exynos5
since VIDCON1 has to be used in addition to timing base offset
(0x2). This patch also eliminates this problem.

Signed-off-by: Prathyush K prathyus...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   14 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   21 +
 drivers/gpu/drm/exynos/exynos_mixer.c|   21 -
 3 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a4702a8..6bb8644 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -36,20 +36,6 @@
 #define MAX_FB_BUFFER  4
 #define DEFAULT_ZPOS   -1
 
-#define _wait_for(COND, MS) ({ \
-   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS);   \
-   int ret__ = 0;  \
-   while (!(COND)) {   \
-   if (time_after(jiffies, timeout__)) {   \
-   ret__ = -ETIMEDOUT; \
-   break;  \
-   }   \
-   }   \
-   ret__;  \
-})
-
-#define wait_for(COND, MS) _wait_for(COND, MS)
-
 struct drm_device;
 struct exynos_drm_overlay;
 struct drm_connector;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e2abae6..63f0d0f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -101,6 +101,8 @@ struct fimd_context {
u32 vidcon1;
boolsuspended;
struct mutexlock;
+   wait_queue_head_t   wait_vsync_queue;
+   atomic_twait_vsync_event;
 
struct exynos_drm_panel_info *panel;
 };
@@ -606,11 +608,16 @@ static void fimd_win_disable(struct device *dev, int zpos)
 static void fimd_wait_for_vblank(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
-   int ret;
 
-   ret = wait_for((__raw_readl(ctx-regs + VIDCON1) 
-   VIDCON1_VSTATUS_VSYNC), 50);
-   if (ret  0)
+   atomic_set(ctx-wait_vsync_event, 1);
+
+   /*
+* wait for FIMD to signal VSYNC interrupt or return after
+* timeout which is set to 50ms (refresh rate of 20).
+*/
+   if (!wait_event_timeout(ctx-wait_vsync_queue,
+   !atomic_read(ctx-wait_vsync_event),
+   DRM_HZ/20))
DRM_DEBUG_KMS(vblank wait timed out.\n);
 }
 
@@ -677,6 +684,10 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
drm_handle_vblank(drm_dev, manager-pipe);
fimd_finish_pageflip(drm_dev, manager-pipe);
 
+   /* set wait vsync event to zero and wake up queue. */
+   atomic_set(ctx-wait_vsync_event, 0);
+   DRM_WAKEUP(ctx-wait_vsync_queue);
+
 out:
return IRQ_HANDLED;
 }
@@ -967,6 +978,8 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
ctx-vidcon1 = pdata-vidcon1;
ctx-default_win = pdata-default_win;
ctx-panel = panel;
+   DRM_INIT_WAITQUEUE(ctx-wait_vsync_queue);
+   atomic_set(ctx-wait_vsync_event, 0);
 
subdrv = ctx-subdrv;
 
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 50100cf..972281e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -93,6 +93,8 @@ struct mixer_context {
struct hdmi_win_datawin_data[MIXER_WIN_NR];
enum mixer_version_id   mxr_ver;
void*parent_ctx;
+   wait_queue_head_t   wait_vsync_queue;
+   atomic_twait_vsync_event;
 };
 
 struct mixer_drv_data {
@@ -791,12 +793,16 @@ static void mixer_dpms(void *ctx, int mode)
 static void mixer_wait_for_vblank(void *ctx)
 {
struct mixer_context *mixer_ctx = ctx;
-   struct mixer_resources *res = mixer_ctx-mixer_res;
-   int ret;
 
-   ret = wait_for((mixer_reg_read(res, MXR_INT_STATUS) 
-   MXR_INT_STATUS_VSYNC), 50);
-   if (ret  0)
+   atomic_set(mixer_ctx-wait_vsync_event,

[PATCH 2/3] drm/exynos: move wait_for_vblank to manager_ops

Currently wait_for_vblank is set as an overlay_op which is not
correct since wait for vblank is not dependant on any particular
overlay. It should be grouped with enable/disable vblank calls
inside manager_ops.
Also if wait for vblank is a manager op, the check for DPMS_OFF
of encoder can be removed inside exynos_drm_encoder_complete_scanout.
This fixes the following issue while removing a fb.
While removing the current fb (crtc-fb == fb) the encoder
dpms off is called and then the framebuffer is removed. So in
this case, the wait for vblank is not called thus leading to a crash
(since fb might get removed before dma is finished).

Signed-off-by: Prathyush K prathyus...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |6 ++--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   34 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|   22 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   34 +-
 6 files changed, 53 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6bb8644..98597d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -60,8 +60,6 @@ enum exynos_drm_output_type {
  * @commit: apply hardware specific overlay data to registers.
  * @enable: enable hardware specific overlay.
  * @disable: disable hardware specific overlay.
- * @wait_for_vblank: wait for vblank interrupt to make sure that
- * hardware overlay is disabled.
  */
 struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -69,7 +67,6 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
-   void (*wait_for_vblank)(struct device *subdrv_dev);
 };
 
 /*
@@ -172,6 +169,8 @@ struct exynos_drm_display_ops {
  * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * hardware overlay is updated.
  */
 struct exynos_drm_manager_ops {
void (*dpms)(struct device *subdrv_dev, int mode);
@@ -186,6 +185,7 @@ struct exynos_drm_manager_ops {
void (*commit)(struct device *subdrv_dev);
int (*enable_vblank)(struct device *subdrv_dev);
void (*disable_vblank)(struct device *subdrv_dev);
+   void (*wait_for_vblank)(struct device *subdrv_dev);
 };
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index d9afb11..3014852 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -237,8 +237,7 @@ static void exynos_drm_encoder_commit(struct drm_encoder 
*encoder)
 void exynos_drm_encoder_complete_scanout(struct drm_framebuffer *fb)
 {
struct exynos_drm_encoder *exynos_encoder;
-   struct exynos_drm_overlay_ops *overlay_ops;
-   struct exynos_drm_manager *manager;
+   struct exynos_drm_manager_ops *ops;
struct drm_device *dev = fb-dev;
struct drm_encoder *encoder;
 
@@ -248,21 +247,15 @@ void exynos_drm_encoder_complete_scanout(struct 
drm_framebuffer *fb)
 */
list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
exynos_encoder = to_exynos_encoder(encoder);
-
-   /* if exynos was disabled, just ignor it. */
-   if (exynos_encoder-dpms  DRM_MODE_DPMS_ON)
-   continue;
-
-   manager = exynos_encoder-manager;
-   overlay_ops = manager-overlay_ops;
+   ops = exynos_encoder-manager-ops;
 
/*
 * wait for vblank interrupt
 * - this makes sure that overlay data are updated to
 *  real hardware.
 */
-   if (overlay_ops-wait_for_vblank)
-   overlay_ops-wait_for_vblank(manager-dev);
+   if (ops-wait_for_vblank)
+   ops-wait_for_vblank(exynos_encoder-manager-dev);
}
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 63f0d0f..020eb86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -320,12 +320,29 @@ static void fimd_disable_vblank(struct device *dev)
}
 }
 
+static void fimd_wait_for_vblank(struct device *dev)
+{
+   struct fimd_context *ctx = get_fimd_context(dev);
+
+   atomic_set(ctx-wait_vsync_event, 1);
+
+   /*
+* wait for FIMD to

[PATCH 3/3] drm/exynos: do not disable crtc if already off

The crtc disable function should not disable the overlays if the
crtc is already in DPMS_OFF as this will lead to register access
when clock is off.
Also the crtc disable function should not call DPMS OFF of the
crtc. This is required to ensure we are able to wait for vblank
before freeing any framebuffers after disabling the crtc.

Signed-off-by: Prathyush K prathyus...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2efa4b0..faa6ee0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -186,8 +186,12 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
+   if (exynos_crtc-dpms  DRM_MODE_DPMS_ON) {
+   DRM_DEBUG_KMS(crtc is already off.\n);
+   return;
+   }
+
exynos_plane_dpms(exynos_crtc-plane, DRM_MODE_DPMS_OFF);
-   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
 }
 
 static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
-- 
1.7.0.4

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

[PATCH 0/3] drm/exynos: modify usage of wait for vblank

This patchset fixes a few issues with use of wait for vblank in
exynos drm. 

Please apply these three patches without drm/exynos: release fb pended by page 
flip
patch.

Patch 1: modify wait for vsync functions to use wait queues
This modifies the wait_for_vblank functions to use wait queues
thus ensuring that the current task goes to sleep without taking
up CPU while waiting.

Patch 2: move wait_for_vblank to manager_ops
Currently, we do not call wait for vblank if encoder is in DPMS_OFF
state inside exynos_drm_encoder_complete_scanout function. This is
because wait for vblank is treated as an overlay op. This can be
modified to a manager_op thus removing the above check for DPMS_OFF.
This fixes a crash while removing a fb.
While removing the current fb (crtc-fb == fb) the encoder
dpms off is called and then the framebuffer is removed. So in
this case, the wait for vblank is not called thus leading to a crash
(since fb might get removed before dma is finished)

Patch 3: do not disable crtc if already off
We should not disable the overlay if the crtc is in DPMS_OFF state.
Also, the disable function should not call DPMS_OFF of the crtc.
This is required to ensure we are able to wait for vblank
before freeing any framebuffers after disabling the crtc.

With these three patches and without drm/exynos: release fb pended by page 
flip
I could not find any crash/page_fault in drm with fimd/hdmi during hotplug
and page flips.

Prathyush K (3):
  drm/exynos: modify wait for vsync functions to use wait queues
  drm/exynos: move wait_for_vblank to manager_ops
  drm/exynos: do not disable crtc if already off

 drivers/gpu/drm/exynos/exynos_drm_crtc.c|6 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   20 ++
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   37 ++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|   22 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   37 +-
 7 files changed, 73 insertions(+), 66 deletions(-)

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

Re: [PATCH v2] drm/exynos: release fb pended by page flip

2012/12/4 Prathyush K prathy...@chromium.org




 On Tue, Dec 4, 2012 at 5:44 PM, Inki Dae inki@samsung.com wrote:

 Changelog v2:
 fix page fault issue.
 - defer to unreference old fb to avoid page fault issue.
 So with this fixup, new fb would be updated to hardware
 prior to old fb unreferencing. And it removes unnecessary
 patch, drm/exynos: Unreference fb in exynos_disable_plane()

 Changelog v1:
 This patch releases the fb pended by page flip after fbdev is
 restored propely. And fixes invalid memory access when drm is
 released while doing pageflip.

 This patch makes fb's refcount to be increased when setcrtc and
 pageflip are requested. In other words, it increases fb's refcount
 only if dma is going to access memory region to fb and decreases
 old fb's because the old fb isn't accessed by dma anymore.

 This could guarantee releasing gem buffer to the fb after dma
 access to the gem buffer has been completed.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42
 -
  drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
  drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
  drivers/gpu/drm/exynos/exynos_drm_plane.c |   28 ++-
  5 files changed, 106 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index 2efa4b0..b9c37eb 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -32,6 +32,7 @@
  #include exynos_drm_drv.h
  #include exynos_drm_encoder.h
  #include exynos_drm_plane.h
 +#include exynos_drm_fb.h

  #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc,\
 drm_crtc)
 @@ -139,8 +140,25 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
 struct drm_display_mode *mode,
 plane-crtc = crtc;
 plane-fb = crtc-fb;

 +   /*
 +* Take a reference to new fb.
 +*
 +* Taking a reference means that this plane's dma is going to
 access
 +* memory region to the new fb.
 +*/
 +   drm_framebuffer_reference(plane-fb);
 +


 Hi Mr. Dae,

 There is an issue with this approach.

 Take this simple use case with just one crtc. (fbdev = fb0)

 First, set fb1

 we reference fb1 and unreference fb0.

 Second, remove fb1

 In this case, we are removing the current fb of the crtc
 We hit the function 'drm_helper_disable_unused_functions'.
 Here, we try to disable the crtc and then we set crtc-fb = NULL.
 So the value of crtc-fb is lost.



 After drm release, we restore fbdev mode.

 Now we reference fb0 - but we fail to unreference fb1. (old_fb is NULL)

 So fb1 never gets freed thus causing a memory leak.


No, please see drm_framebuffer_remove funtion. At this function,
drm_framebuffer_unreference(fb1) is called so the fb1 is released correctly
after the crtc to current fb1 is disabled like below,

drm_framebuffer_remove(...)
{
disable the crtc to current fb1
disable all planes to current fb1
...
drm_framebuffer_unreference(fb1);   - here
}

So unreferencing to fb1 is igonored because of NULL at fbdev restore.


 I tested this with modetest and each time the fb/gem memory never gets
 freed.


Really? is there any case that drm_framebuffer_unreference(fb1) isn't
called. I couldn't find any memory leak. Anyway, I will check it again.



 Also, another issue:

 If a page flip is pending, you set the 'pending' flag and do not actually
 unreference the fb.
 And you are freeing that fb after fbdev is restored.


Ok, I had mentioned about this before but leave it below again and also
refer to the below email threads,
http://www.spinics.net/lists/dri-devel/msg29880.html

crtc0's current fb is fb0
page flip request(crtc0, fb1)
1. drm_vblank_get call
2. vsync occurs and the dma access memory region to fb0 yet.
3. crtc0-fb = fb1
4. drm is released
5. crtc's current fb is fb1 but the dma is accessing memory region to fb0
yet because vsync doesn't occur so fb0 doesn't disable crtc and releses its
own gem buffer. At this time, page fault would be induced because dma is
still accessing the fb0 but the fb0 had already been released.

So this patch defers fb releasing until fbdev is restored by drm release to
avoid the page fault issue.


 In a normal setup, we release DRM only during system shutdown i.e. we open
 the drm
 device during boot up and do not release drm till the end. But we keep
 page flipping and removing
 framebuffers all the time.

 In this case, the pending fb memory does not get freed till we actually
 release drm at the
 very end.


For this, I mentioned above.(to defer fb releasing)


 I am not sure why this approach is required.
 We are anyway waiting for vblank before removing a framebuffer so we can
 be sure

[RFC libdrm] Add NVIDIA Tegra support

Hi,

I mentioned in a reply to Terje's patch series for 2D acceleration that
I had prototyped some libdrm support a few weeks back. I've spent a bit
of time cleaning it up and decided to post it for early review.

There's really not much interesting code here. A basic API is provided
along with two IOCTLs that can be used to create Tegra-specific GEM, as
opposed to dumb buffer objects. Given the various comments on Terje's
proposed IOCTLs I wanted to make sure that these will be safe. I've seen
that other chips use 64-bit fields for the size and offset of buffer
objects and I wonder if those are really necessary.

Linux kernel patches for the IOCTLs are also in the works and I hope to
get around to posting them this week. Obviously there will be some
overlap between this and what Terje posted in his series, but it should
be easy to synchronize.

Thierry

Thierry Reding (1):
  libdrm: Add NVIDIA Tegra support

 Makefile.am   |   6 +-
 configure.ac  |  15 ++-
 include/drm/Makefile.am   |   1 +
 include/drm/tegra_drm.h   |  48 ++
 tegra/Makefile.am |  17 
 tegra/libdrm_tegra.pc.in  |  11 +++
 tegra/tegra.c | 227 ++
 tegra/tegra.h |  51 +++
 tests/modetest/modetest.c |   2 +-
 tests/vbltest/vbltest.c   |   2 +-
 10 files changed, 376 insertions(+), 4 deletions(-)
 create mode 100644 include/drm/tegra_drm.h
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra.c
 create mode 100644 tegra/tegra.h

-- 
1.8.0.1

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

[RFC libdrm] Add NVIDIA Tegra support

Add the libdrm_tegra helper library to encapsulate Tegra-specific
interfaces to the DRM.

Furthermore, Tegra is added to the list of supported chips in the
modetest and vbltest programs.

Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
 Makefile.am   |   6 +-
 configure.ac  |  15 ++-
 include/drm/Makefile.am   |   1 +
 include/drm/tegra_drm.h   |  48 ++
 tegra/Makefile.am |  17 
 tegra/libdrm_tegra.pc.in  |  11 +++
 tegra/tegra.c | 227 ++
 tegra/tegra.h |  51 +++
 tests/modetest/modetest.c |   2 +-
 tests/vbltest/vbltest.c   |   2 +-
 10 files changed, 376 insertions(+), 4 deletions(-)
 create mode 100644 include/drm/tegra_drm.h
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/tegra.c
 create mode 100644 tegra/tegra.h

diff --git a/Makefile.am b/Makefile.am
index 8ecd9d9..e90ae43 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -49,7 +49,11 @@ if HAVE_EXYNOS
 EXYNOS_SUBDIR = exynos
 endif
 
-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include man
+if HAVE_TEGRA
+TEGRA_SUBDIR = tegra
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(TEGRA_SUBDIR) tests include 
man
 
 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 0c19929..72d6dfa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -114,6 +114,11 @@ AC_ARG_ENABLE(exynos-experimental-api,
  [Enable support for EXYNOS's experimental API (default: 
disabled)]),
  [EXYNOS=$enableval], [EXYNOS=no])
 
+AC_ARG_ENABLE(tegra-experimental-api,
+ AS_HELP_STRING([--enable-tegra-experimental-api],
+ [Enable support for Tegra's experimental API (default: 
disabled)]),
+ [TEGRA=$enableval], [TEGRA=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -222,6 +227,11 @@ if test x$EXYNOS = xyes; then
AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
 fi
 
+AM_CONDITIONAL(HAVE_TEGRA, [test x$TEGRA = xyes])
+if test x$TEGRA = xyes; then
+   AC_DEFINE(HAVE_TEGRA, 1, [Have Tegra support])
+fi
+
 AC_ARG_ENABLE([cairo-tests],
   [AS_HELP_STRING([--enable-cairo-tests],
   [Enable support for Cairo rendering in tests 
(default: auto)])],
@@ -247,7 +257,7 @@ if test x$HAVE_LIBUDEV = xyes; then
 fi
 AM_CONDITIONAL(HAVE_LIBUDEV, [test x$HAVE_LIBUDEV = xyes])
 
-if test x$INTEL != xno -o x$RADEON != xno -o x$NOUVEAU != xno -o 
x$OMAP != xno; then
+if test x$INTEL != xno -o x$RADEON != xno -o x$NOUVEAU != xno -o 
x$OMAP != xno -o x$TEGRA != xno; then
 # Check for atomic intrinsics
 AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives,
 [
@@ -358,6 +368,8 @@ AC_CONFIG_FILES([
omap/libdrm_omap.pc
exynos/Makefile
exynos/libdrm_exynos.pc
+   tegra/Makefile
+   tegra/libdrm_tegra.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -380,4 +392,5 @@ echo   Radeon API $RADEON
 echo   Nouveau API$NOUVEAU
 echo   OMAP API   $OMAP
 echo   EXYNOS API $EXYNOS
+echo   Tegra API  $TEGRA
 echo 
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 2923ab4..3e33ed0 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -35,6 +35,7 @@ klibdrminclude_HEADERS = \
radeon_drm.h \
savage_drm.h \
sis_drm.h \
+   tegra_drm.h \
via_drm.h \
mach64_drm.h
 
diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
new file mode 100644
index 000..eaec602
--- /dev/null
+++ b/include/drm/tegra_drm.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright © 2012 Thierry Reding
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ *

Re: [RFC libdrm] Add NVIDIA Tegra support

On Tue, Dec 04, 2012 at 09:28:25AM -0600, Rob Clark wrote:
 On Tue, Dec 4, 2012 at 9:13 AM, Thierry Reding
 thierry.red...@avionic-design.de wrote:
  +int drm_tegra_bo_new(struct drm_tegra *device, uint32_t flags, uint32_t 
  size,
  +struct drm_tegra_bo **bop)
  +{
  +   struct drm_tegra_gem_create args;
  +   struct drm_tegra_bo *bo;
  +   struct tegra_bo *priv;
  +   int err;
  +
  +   if (!device || size == 0 || !bop)
  +   return -EINVAL;
  +
  +   bo = calloc(1, sizeof(*bo));
  +   if (!bo)
  +   return -ENOMEM;
  +
  +   priv = tegra_bo(bo);
  +
  +   DRMLISTINITHEAD(priv-list);
  +   atomic_set(priv-ref, 1);
  +   bo-device = device;
  +   bo-flags = flags;
  +   bo-size = size;
  +
  +   memset(args, 0, sizeof(args));
  +   args.flags = flags;
  +   args.size = size;
  +
  +   err = drmCommandWriteRead(device-fd, DRM_TEGRA_GEM_CREATE, args,
  + sizeof(args));
  +   if (err  0) {
  +   err = -errno;
  +   free(bo);
  +   return err;
  +   }
  +
  +   DRMLISTADD(priv-list, device-bo_list);
  +   bo-handle = args.handle;
  +   bo-offset = args.offset;
 
 btw, x11 can rapidly create/destroy temporary pixmaps.. which don't
 necessarily need userspace access.  You might prefer to avoid creating
 mmap offset on GEM bo creation, and instead do this only if userspace
 needs to mmap the bo

Ah, so that's the reason for the MMAP IOCTL provided by other DRMs. Yes,
that might be better in the long run. For now I don't think it makes
much of a difference since the GEM objects are backed by CMA, and
therefore the offset will be created along with the GEM anyway.

With Terje's upcoming rework that handles all the allocations in host1x
this should become more important, especially when the mapping is done
through the Tegra30's IOMMU.

I'll rework that. Thanks for the quick reply.

Thierry


pgp04bfAF9t0f.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Make the HPD status updates debug logs more readable

2012-12-04 Thread Damien Lespiau

From: Damien Lespiau damien.lesp...@intel.com

Instead of just printing status updated from 1 to 2, make those enum
numbers immediately readable.

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fe719f..8b963fd 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1043,6 +1043,18 @@ void drm_kms_helper_poll_fini(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_fini);
 
+static const char *connector_status_str(enum drm_connector_status status)
+{
+   switch (status) {
+   case connector_status_connected:
+   return connected;
+   case connector_status_disconnected:
+   return disconnected;
+   default:
+   return unknown;
+   }
+}
+
 void drm_helper_hpd_irq_event(struct drm_device *dev)
 {
struct drm_connector *connector;
@@ -1062,10 +1074,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
old_status = connector-status;
 
connector-status = connector-funcs-detect(connector, false);
-   DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d to 
%d\n,
+   DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %s to 
%s\n,
  connector-base.id,
  drm_get_connector_name(connector),
- old_status, connector-status);
+ connector_status_str(old_status),
+ connector_status_str(connector-status));
if (old_status != connector-status)
changed = true;
}
-- 
1.7.11.7

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

Re: [PATCH v2] drm/exynos: release fb pended by page flip

On Tue, Dec 4, 2012 at 1:14 PM, Inki Dae inki@samsung.com wrote:
 Changelog v2:
 fix page fault issue.
 - defer to unreference old fb to avoid page fault issue.
 So with this fixup, new fb would be updated to hardware
 prior to old fb unreferencing. And it removes unnecessary
 patch, drm/exynos: Unreference fb in exynos_disable_plane()

 Changelog v1:
 This patch releases the fb pended by page flip after fbdev is
 restored propely. And fixes invalid memory access when drm is
 released while doing pageflip.

 This patch makes fb's refcount to be increased when setcrtc and
 pageflip are requested. In other words, it increases fb's refcount
 only if dma is going to access memory region to fb and decreases
 old fb's because the old fb isn't accessed by dma anymore.

 This could guarantee releasing gem buffer to the fb after dma
 access to the gem buffer has been completed.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Just an fyi, I'm looking into revamping the locking/refcounting in
this area in the drm core right now. No patches yet for public
consumption, but I hope that I can send out and rfc at the end of this
week. Might fix your problem, too, and certainly addresses the issue
Prathyush noticed, since the refcounting is done in the drm core and
should be able to catch all the cases where we need to
reference/unreference an fb.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] drm/exynos: modify usage of wait for vblank

2012/12/5 Prathyush K prathyus...@samsung.com

 This patchset fixes a few issues with use of wait for vblank in
 exynos drm.

 Please apply these three patches without drm/exynos: release fb pended by
 page flip
 patch.

 Patch 1: modify wait for vsync functions to use wait queues
 This modifies the wait_for_vblank functions to use wait queues
 thus ensuring that the current task goes to sleep without taking
 up CPU while waiting.

 Patch 2: move wait_for_vblank to manager_ops
 Currently, we do not call wait for vblank if encoder is in DPMS_OFF
 state inside exynos_drm_encoder_complete_scanout function. This is
 because wait for vblank is treated as an overlay op.

This can be
 modified to a manager_op thus removing the above check for DPMS_OFF.
 This fixes a crash while removing a fb.
 While removing the current fb (crtc-fb == fb) the encoder
 dpms off is called and then the framebuffer is removed. So in
 this case, the wait for vblank is not called thus leading to a crash
 (since fb might get removed before dma is finished)

 Patch 3: do not disable crtc if already off
 We should not disable the overlay if the crtc is in DPMS_OFF state.
 Also, the disable function should not call DPMS_OFF of the crtc.
 This is required to ensure we are able to wait for vblank
 before freeing any framebuffers after disabling the crtc.

 With these three patches and without drm/exynos: release fb pended by
 page flip
 I could not find any crash/page_fault in drm with fimd/hdmi during hotplug
 and page flips.


It seems better than old one and also including some exception codes, Patch
3 we did't consider. Ok, we will test these patches and merge them instead
of old one if no problem.

Thanks,
Inki Dae


 Prathyush K (3)
   drm/exynos: modify wait for vsync functions to use wait queues
   drm/exynos: move wait_for_vblank to manager_ops
   drm/exynos: do not disable crtc if already off

  drivers/gpu/drm/exynos/exynos_drm_crtc.c|6 +++-
  drivers/gpu/drm/exynos/exynos_drm_drv.h |   20 ++
  drivers/gpu/drm/exynos/exynos_drm_encoder.c |   15 +++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   37
 ++
  drivers/gpu/drm/exynos/exynos_drm_hdmi.c|   22 
  drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
  drivers/gpu/drm/exynos/exynos_mixer.c   |   37
 +-
  7 files changed, 73 insertions(+), 66 deletions(-)

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

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

[Bug 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

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

--- Comment #5 from Tomasz P. son_of_the_osi...@interia.pl ---
(In reply to comment #4)
 I compiled latest mesa (git-51d0892) on my other, desktop computer with ATI
 Technologies Inc RV350 AR [Radeon 9600] and it has the same problem. Xorg
 server is 1.10.2, Linux kernel is 2.6.38.4 and KDE us also 4.6.3

Also have rv350/radeon 9600.I am using kde 4.9.80, kernel 3.6.9, mesa-git from
today xorg-server-git from today . It look like the problem is gone.I changing
gl-screensavers without any screen blanking / flashing.I have kwin effects
enabled.

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

[Bug 51301] [-next-20121129] memory leak/page allocator fragmentation?

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





--- Comment #4 from Peter Hurley pe...@hurleysoftware.com  2012-12-04 
16:48:22 ---
Not sure why I picked kvm/nouveau for this OOM ;)

Could be any number of apps over a 3.5 period...

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching someone on the CC list of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms gallium

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

--- Comment #17 from Tomasz P. son_of_the_osi...@interia.pl ---
I just instaled xscreensaver and run crackberg on rv350 / radeon 9600
agp.Normal memory usage nothing special.No warnings in logs. Animation works
without any artefacts or screen flashing.

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

[Bug 37485] Noise in some tracks in SuperTuxKart (HyperZ related)

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

--- Comment #2 from Tomasz P. son_of_the_osi...@interia.pl ---
(In reply to comment #1)
 Is this still an issue with current Mesa git?

I playing with supertuxcart today.The game is boring so I don't test all
tracks,but I cannot see any rendering errors with hyperz on. I run it on full
details in 1600x1200 and it looks good for me.

mesa-git (today)
xorg-server-git
kernel 3.6.9
kde 4.9.80 (kwin effects enabled)

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

Re: [PATCH] drm: Make the HPD status updates debug logs more readable

On Tue, Dec 04, 2012 at 04:00:17PM +, Damien Lespiau wrote:
 From: Damien Lespiau damien.lesp...@intel.com
 
 Instead of just printing status updated from 1 to 2, make those enum
 numbers immediately readable.
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com

I like, stupid me can never remember the magic values. For the patch
itself, can you please also patch the connector updates in
drm_helper_probe_single_connector_modes (which is required to avoid losing
hpd events when doing a manual probe cycle) and output_poll_execute. For
completeness maybe also throw in a debug output in
drm_helper_disable_unused_functions, but that's only relevant for drivers
that use the modeset helpers (i.e. not for drm/i915).

Thanks, Daniel

 ---
  drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
  1 file changed, 15 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
 b/drivers/gpu/drm/drm_crtc_helper.c
 index 1fe719f..8b963fd 100644
 --- a/drivers/gpu/drm/drm_crtc_helper.c
 +++ b/drivers/gpu/drm/drm_crtc_helper.c
 @@ -1043,6 +1043,18 @@ void drm_kms_helper_poll_fini(struct drm_device *dev)
  }
  EXPORT_SYMBOL(drm_kms_helper_poll_fini);
  
 +static const char *connector_status_str(enum drm_connector_status status)
 +{
 + switch (status) {
 + case connector_status_connected:
 + return connected;
 + case connector_status_disconnected:
 + return disconnected;
 + default:
 + return unknown;
 + }
 +}
 +
  void drm_helper_hpd_irq_event(struct drm_device *dev)
  {
   struct drm_connector *connector;
 @@ -1062,10 +1074,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
   old_status = connector-status;
  
   connector-status = connector-funcs-detect(connector, false);
 - DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d to 
 %d\n,
 + DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %s to 
 %s\n,
 connector-base.id,
 drm_get_connector_name(connector),
 -   old_status, connector-status);
 +   connector_status_str(old_status),
 +   connector_status_str(connector-status));
   if (old_status != connector-status)
   changed = true;
   }
 -- 
 1.7.11.7
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 57888] New: Amnesia shader compiler errors on RV350

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

  Priority: medium
Bug ID: 57888
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Amnesia shader compiler errors on RV350
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: ore...@gmail.com
  Hardware: x86 (IA32)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r300
   Product: Mesa

Created attachment 71005
  -- https://bugs.freedesktop.org/attachment.cgi?id=71005action=edit
side-by-side comparison

Running the game Amnesia with minimal graphics settings and resolution causes
the following error:

r300 FP: Compiler Error:
Too many hardware temporaries used.
Using a dummy shader instead.

With all graphics settings highest, this message is output additionally:

r300 FP: Compiler Error:
compiler/r300_fragprog_emit.c::emit_alu(): Too many ALU instructions


Here is some additional information:

Distro: Xubuntu 12.04 32bit
Kernel: 3.5.0-18-generic
Mesa: ec83535c83c748b067ecf4548e5396fef8719725
libtxc_dxtn.so installed


The game runs but most of the textures are black, except light sources such as
the torches and windows. On Intel Sandybridge, the textures render correctly.
I've attached an image to demonstrate the difference. The left is i965, the
right is r300g. On intel, there are no errors output.

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

[Bug 57888] Amnesia shader compiler errors on RV350

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

Scott Moreau ore...@gmail.com changed:

   What|Removed |Added

  Attachment #71005|0   |1
is obsolete||

--- Comment #1 from Scott Moreau ore...@gmail.com ---
Created attachment 71006
  -- https://bugs.freedesktop.org/attachment.cgi?id=71006action=edit
side-by-side comparison

Correctly set type for image attachment.

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

[Bug 57888] Amnesia shader compiler errors on RV350

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

--- Comment #2 from Alex Deucher ag...@yahoo.com ---
If the game uses compressed textures, you may need to install libtxc_dxtn.

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

[Bug 57888] Amnesia shader compiler errors on RV350

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

--- Comment #3 from Tom Stellard tstel...@gmail.com ---
Could you run the program with the environment variable RADEON_DEBUG=fp and
then post the output.

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

[Bug 34097] Screen clearing issues in Minecraft and Blender

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

--- Comment #6 from Tomasz P. son_of_the_osi...@interia.pl ---
on rv350 rendering in blender looks normal with mesa-git, is the situation
changed with current mesa ?

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

[Bug 40554] r200 falls back to software when clearing FBOs

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

--- Comment #3 from Roland Scheidegger srol...@vmware.com ---
FWIW the relevant commit fixing this bug was
de694b6b10b7ce23a00cd7296a955f162704ee62.

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

[Bug 57888] Amnesia shader compiler errors on RV350