[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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

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

--- Comment #19 from Wolfgang Rupprecht  ---
(In reply to comment #18)
> Is this still an issue with a newer kernel?

I haven't seen this problem in years.  The bug went away with a newer gnome
desktop.  I assume there was a way for a user app to take responsibility for
the power save state and also to drop the ball.

-- 
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/20140409/8ac8445f/attachment.html>

[PATCH] drm/nouveau/bios: fix bug introduced in 457e77b2

[Andreas Noever]

457e77b2 effectively replaces (... & 0xff00) << 8 with (... >> 8) << 8.
Which does not do the same and breaks boot on my machine.

Restore the old behaviour and remove the unnecessary cast.

Signed-off-by: Andreas Noever 
---
 drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index e9df94f..2885b7c 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -109,7 +109,7 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
return;
}

-   addr = (u64)(addr >> 8) << 8;
+   addr = (addr >> 8) << 16;
if (!addr) {
addr  = (u64)nv_rd32(bios, 0x001700) << 16;
addr += 0xf;
-- 
1.9.1

[Bug 77244] UVD microcode fails to load on HD 8970M (Neptune XT -- PITCAIRN)

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

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

--- Comment #9 from Nathan Schulte  ---
Created attachment 97157
  --> https://bugs.freedesktop.org/attachment.cgi?id=97157=edit
Linux kernel log -- radeon.runpm=0

-- 
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/20140409/13c2bfe5/attachment.html>

[Bug 77244] UVD microcode fails to load on HD 8970M (Neptune XT -- PITCAIRN)

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

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

--- Comment #8 from Nathan Schulte  ---
Booting with radeon.runpm=0 produces slightly different results.  The card
doesn't power down ("dGPU LED" is on now), and I still have the UVD error
logging, but just once this time; switching vttys does not cause the logging
again.  As well, the "hang" is much reduced or completely gone when switching
vttys: switching from a "graphic" (not sure of the proper terms) vtty to any
console-vtty has a very small delay, but switching to a "graphic" vtty does
not.

As well, I tried render offload with radeon.runpm=0, and that still crashes X,
but there is no radeon/UVD/DRM logging from the kernel like the was prior.

-- 
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/20140409/e2f781a5/attachment.html>

WARNING ... drivers/gpu/drm/ttm/ttm_bo_vm.c...

[Thomas Hellstrom]

Hi, David!

Thanks for the reply.

Actually I just got CC'd on the Fedora Bug. I haven't seen this either,
so I can't provide more info...

What I was thinking was that maybe after a fork, vma->vm_file->f_mapping
of the child process wasn't set to the same value as the
parent...

/Thomas



On 04/09/2014 08:54 PM, David Herrmann wrote:
> Hi Thomas
>
> On Tue, Apr 8, 2014 at 7:11 AM, Thomas Hellstrom  
> wrote:
>> Hi, David,
>>
>> Are there any dev_mapping changes in 3.15 that could cause this?
>> Do we know what happens to vma->vm_file->f_mapping during fork?
> Sorry, I was traveling. Yes, there have been changes, but I converted
> all drivers properly. We now set file->f_mapping in drm_fops.c to
> dev->anon_inode->i_mapping during open(). All the ttm stuff now sets
> ttm->dev_mapping to the same during ttm init so I have no idea why
> that assertion fails. The vmwgfx driver sets it correctly in
> vmw_driver_load() and I cannot find any code changing it.
>
> I also cannot reproduce it. Can you provide some more information?
> Like what is vma->vm_file set to? What is ttm->dev_mapping? What is
> drm_device->anon_inode->i_mapping? What is
> _device->anon_inode->i_data? All these should _always_ be the
> same.
>
> Btw., grep'ping for '_mapping' usually shows all related code, which I
> reviewed and all looks good.
>
> Thanks
> David

[Bug 77244] UVD microcode fails to load on HD 8970M (Neptune XT -- PITCAIRN)

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

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

--- Comment #7 from Alex Deucher  ---
(In reply to comment #6)
> It is definitely the duplicate of this bug
> https://bugs.freedesktop.org/show_bug.cgi?id=75234 .

I'm not so sure.  On bug 75234, the UVD initialization only fails after a
runtime power management event, while in this case, it fails right from the
start.

For this bug, does disabling runtime power management help?  Try appending
radeon.runpm=0 to the kernel command line in grub.

-- 
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/20140409/6b56a160/attachment-0001.html>

WARNING ... drivers/gpu/drm/ttm/ttm_bo_vm.c...

[David Herrmann]

Hi Thomas

On Tue, Apr 8, 2014 at 7:11 AM, Thomas Hellstrom  
wrote:
> Hi, David,
>
> Are there any dev_mapping changes in 3.15 that could cause this?
> Do we know what happens to vma->vm_file->f_mapping during fork?

Sorry, I was traveling. Yes, there have been changes, but I converted
all drivers properly. We now set file->f_mapping in drm_fops.c to
dev->anon_inode->i_mapping during open(). All the ttm stuff now sets
ttm->dev_mapping to the same during ttm init so I have no idea why
that assertion fails. The vmwgfx driver sets it correctly in
vmw_driver_load() and I cannot find any code changing it.

I also cannot reproduce it. Can you provide some more information?
Like what is vma->vm_file set to? What is ttm->dev_mapping? What is
drm_device->anon_inode->i_mapping? What is
_device->anon_inode->i_data? All these should _always_ be the
same.

Btw., grep'ping for '_mapping' usually shows all related code, which I
reviewed and all looks good.

Thanks
David

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #29 from Alex Deucher  ---
Created attachment 131821
  --> https://bugzilla.kernel.org/attachment.cgi?id=131821=edit
reverse hpd polarity

It sounds like your board by have the hpd pin polarity reversed (so plug events
looks like unplug and vice versa).  Please attach a copy of your vbios:

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

Can you also try the attached patch which reverses the hpd polarity?

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

[Bug 77244] UVD microcode fails to load on HD 8970M (Neptune XT -- PITCAIRN)

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

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

--- Comment #6 from Hohahiu  ---
(In reply to comment #0)
> Created attachment 97143 [details]
> Linux kernel log
> 
> I have a Clevo P150SM based laptop with an Intel HD 4600 iGPU and an AMD
> Radeon HD 8970M dGPU.  I receive the following errors when the Radeon
> DRI/DRM implementation attempts to initialize the card:
> 
> [   65.525470] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   66.537637] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   67.549797] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   68.561967] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   69.574142] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   70.586334] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   71.598533] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   72.610705] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   73.622877] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   74.635068] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   74.654938] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!!
> [   74.654955] [drm:si_startup] *ERROR* radeon: failed initializing UVD (-1).
> 
> 
> This appears to happen on video mode changes or vtty changes, I'm not
> quite sure really what triggers it other than initial loading.  When it
> does occur, the system appears to hang for a short time (15 seconds or
> so) while the dGPU is active, and then "comes back" after the dGPU is
> disabled.  The Clevo P150SM has an LED showing the dGPU power state,
> and debugfs/vgaswitcheroo seems to corroborate this.
> 
> I'm also experiencing issues with PRIME (and e.g. xserver seg-faults when
> building from source to try new code), but this issue exists out of the box
> on Debian Sid, and seems to persist even with newer Mesa and DRM.  I have a
> bug report for the PRIME/hybrid graphics issue as well, and it may end up
> that these are related: https://bugs.freedesktop.org/show_bug.cgi?id=77094
> 
> Finally, this bug looks similar to mine, though I am not messing with PRIME
> (at least explicitly; no xrandr --setprovider* calls and no DRI_PRIME env.
> var. is set): https://bugs.freedesktop.org/show_bug.cgi?id=75234


It is definitely the duplicate of this bug
https://bugs.freedesktop.org/show_bug.cgi?id=75234 .
These error messages appear even without using dGPU just after its
initialization. And firmware is also up-to-date.
> There is a downstream bug report here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743659

-- 
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/20140409/c4981724/attachment.html>

[Bug 46711] vmwgfx does not work in qemu/kvm

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

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

Thomas Hellstrom  changed:

   What|Removed |Added

 CC||thellstrom at vmware.com

--- Comment #3 from Thomas Hellstrom  ---
Hi!

The vmwgfx kernel module does not support devices without the pitchlock
capability. Sorry. In that case you need to use the xf86-video-vmware driver
standalone without kernel modesetting.

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

[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors

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

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

--- Comment #6 from nfxjfg at gmail.com ---
Shouldn't this be responsibility of the code that implements the vdpau API?
Maybe it should attempt to remap the MSC counters to system time, and smooth
out the differences. (Sorry I don't know anything about Mesa internals.)

IMO this issue does make the Mesa vdpau implementation very unreliable, and at
least for me it has caused a lot of problems.

-- 
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/20140409/754833ab/attachment.html>

[Bug 46711] vmwgfx does not work in qemu/kvm

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

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

Michal Suchanek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|OBSOLETE|---

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

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #28 from Tom Yan  ---
(In reply to Alex Deucher from comment #24)
> In your case we need to find out why it's not working properly for you.  You
> mentioned that it works properly in the console but not in X.  That sounds
> like maybe your desktop environment is trying to do something special which
> causes the problem.  Does it work properly with a bare X server?  E.g., just
> run Xorg without a desktop environment.

I tried running i3 with startx, same thing happens.

But I just find that since power off works without the code, I can therefore
get back display after the reconnection by pressing the button before or
afterwards. I guess I'll be removing the code myself on every update since it's
still much more convenient. Is it possible to rebuild this module only?

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

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

Tom Yan  changed:

   What|Removed |Added

 Kernel Version|3.13.5  |3.13.8

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

[patch] drm/panel: s6e8aa0: silence array overflow warning

[Dan Carpenter]

Smatch complains that we are reading beyond the end of the array here:

drivers/gpu/drm/panel/panel-s6e8aa0.c:852 s6e8aa0_read_mtp_id()
warn: buffer overflow 's6e8aa0_variants' 4 <= 4

We set the error code, so it's not harmful but it looks like a return
was intended here so lets add that and silence the warning.

Signed-off-by: Dan Carpenter 
---
Compile tested only.

diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-s6e8aa0.c
index 35941d2..06e57a2 100644
--- a/drivers/gpu/drm/panel/panel-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -847,6 +847,7 @@ static void s6e8aa0_read_mtp_id(struct s6e8aa0 *ctx)
if (i >= ARRAY_SIZE(s6e8aa0_variants)) {
dev_err(ctx->dev, "unsupported display version %d\n", id[1]);
ctx->error = -EINVAL;
+   return;
}

ctx->variant = _variants[i];

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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

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

--- Comment #18 from Alex Deucher  ---
Is this still an issue with a newer kernel?

-- 
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/20140409/f26d2c37/attachment-0001.html>

[Bug 77247] Suspend/Hibernate S3 Defect Fusion E350

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

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

--- Comment #1 from schumi2004 at gmail.com ---
Created attachment 97145
  --> https://bugs.freedesktop.org/attachment.cgi?id=97145=edit
journalctl

-- 
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/20140409/c03c7dc5/attachment.html>

[Bug 77247] New: Suspend/Hibernate S3 Defect Fusion E350

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

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

  Priority: medium
Bug ID: 77247
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Suspend/Hibernate S3 Defect Fusion E350
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: schumi2004 at gmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 97144
  --> https://bugs.freedesktop.org/attachment.cgi?id=97144=edit
dmesg with drm.debug=0xe

My first bug ticket so bare with me.

System: AD02 E350
OS: OpenELEC Beta - Generic x86_64 3.95.5

System won't wakeup from Hibernate/Suspend, symptoms are:
- Blackscreen
- No SSH access to system possible at all.
- Disconnect power to get it working again.

The symptoms are only noticeable after a long period of suspend/hibernate (1
hour and up) If you suspend/hibernate system and directly waking it up again
then you won't have it.

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

[Bug 77244] UVD microcode fails to load on HD 8970M (Neptune XT -- PITCAIRN)

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

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

--- Comment #3 from Christian K?nig  ---
What is the output of "md5sum /lib/firmware/radeon/PITCAIRN_rlc.bin"?

-- 
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/20140409/3396cd2a/attachment.html>

[PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu

[Maarten Lankhorst]

This adds 3 more functions to deal with rcu.

reservation_object_wait_timeout_rcu() will wait on all fences of the
reservation_object, without obtaining the ww_mutex.

reservation_object_test_signaled_rcu() will test if all fences of the
reservation_object are signaled without using the ww_mutex.

reservation_object_get_excl() is added because touching the fence_excl
member directly will trigger a sparse warning.

Signed-off-by: Maarten Lankhorst 
---
 drivers/base/dma-buf.c  |   46 +++--
 drivers/base/reservation.c  |  147 +--
 include/linux/fence.h   |   22 ++
 include/linux/reservation.h |   40 
 4 files changed, 224 insertions(+), 31 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index d89a98d2c37b..fc2d7546b8b0 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -151,14 +151,22 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
if (!events)
return 0;

-   ww_mutex_lock(>lock, NULL);
+   rcu_read_lock();

-   fobj = resv->fence;
-   if (!fobj)
-   goto out;
+   fobj = rcu_dereference(resv->fence);
+   if (fobj) {
+   shared_count = ACCESS_ONCE(fobj->shared_count);
+   smp_mb(); /* shared_count needs transitivity wrt fence_excl */
+   } else
+   shared_count = 0;
+   fence_excl = rcu_dereference(resv->fence_excl);

-   shared_count = fobj->shared_count;
-   fence_excl = resv->fence_excl;
+   /*
+* This would have needed a smp_read_barrier_depends()
+* because shared_count needs to be read before shared[i], but
+* spin_lock_irq and spin_unlock_irq provide even stronger
+* guarantees.
+*/

if (fence_excl && (!(events & POLLOUT) || shared_count == 0)) {
struct dma_buf_poll_cb_t *dcb = >cb_excl;
@@ -176,14 +184,20 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
spin_unlock_irq(>poll.lock);

if (events & pevents) {
-   if (!fence_add_callback(fence_excl, >cb,
+   if (!fence_get_rcu(fence_excl)) {
+   /* force a recheck */
+   events &= ~pevents;
+   dma_buf_poll_cb(NULL, >cb);
+   } else if (!fence_add_callback(fence_excl, >cb,
   dma_buf_poll_cb)) {
events &= ~pevents;
+   fence_put(fence_excl);
} else {
/*
 * No callback queued, wake up any additional
 * waiters.
 */
+   fence_put(fence_excl);
dma_buf_poll_cb(NULL, >cb);
}
}
@@ -205,13 +219,25 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
goto out;

for (i = 0; i < shared_count; ++i) {
-   struct fence *fence = fobj->shared[i];
-
+   struct fence *fence = fence_get_rcu(fobj->shared[i]);
+   if (!fence) {
+   /*
+* fence refcount dropped to zero, this means
+* that fobj has been freed
+*
+* call dma_buf_poll_cb and force a recheck!
+*/
+   events &= ~POLLOUT;
+   dma_buf_poll_cb(NULL, >cb);
+   break;
+   }
if (!fence_add_callback(fence, >cb,
dma_buf_poll_cb)) {
+   fence_put(fence);
events &= ~POLLOUT;
break;
}
+   fence_put(fence);
}

/* No callback queued, wake up any additional waiters. */
@@ -220,7 +246,7 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
}

 out:
-   ww_mutex_unlock(>lock);
+   rcu_read_unlock();
return events;
 }

diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
index b82a5b630a8e..4cdce63140b8 100644
--- a/drivers/base/reservation.c
+++ b/drivers/base/reservation.c
@@ -87,9 +87,13 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
struct fence *old_fence = fobj->shared[i];

fence_get(fence);
+   /* for the fence_get() */
+   

[PATCH 1/2] reservation: update api and add some helpers

[Maarten Lankhorst]

Move the list of shared fences to a struct, and return it in
reservation_object_get_list().

Add reservation_object_reserve_shared(), which reserves space
in the reservation_object for 1 more shared fence.

reservation_object_add_shared_fence() and
reservation_object_add_excl_fence() are used to assign a new
fence to a reservation_object pointer, to complete a reservation.

Signed-off-by: Maarten Lankhorst 
---
 drivers/base/dma-buf.c  |   35 +++---
 drivers/base/fence.c|4 +
 drivers/base/reservation.c  |  154 +++
 include/linux/fence.h   |6 ++
 include/linux/reservation.h |   48 +++--
 kernel/sched/core.c |1 
 6 files changed, 228 insertions(+), 20 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 96338bf7f457..d89a98d2c37b 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -134,7 +134,10 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
 {
struct dma_buf *dmabuf;
struct reservation_object *resv;
+   struct reservation_object_list *fobj;
+   struct fence *fence_excl;
unsigned long events;
+   unsigned shared_count;

dmabuf = file->private_data;
if (!dmabuf || !dmabuf->resv)
@@ -150,12 +153,18 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)

ww_mutex_lock(>lock, NULL);

-   if (resv->fence_excl && (!(events & POLLOUT) ||
-resv->fence_shared_count == 0)) {
+   fobj = resv->fence;
+   if (!fobj)
+   goto out;
+
+   shared_count = fobj->shared_count;
+   fence_excl = resv->fence_excl;
+
+   if (fence_excl && (!(events & POLLOUT) || shared_count == 0)) {
struct dma_buf_poll_cb_t *dcb = >cb_excl;
unsigned long pevents = POLLIN;

-   if (resv->fence_shared_count == 0)
+   if (shared_count == 0)
pevents |= POLLOUT;

spin_lock_irq(>poll.lock);
@@ -167,19 +176,20 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
spin_unlock_irq(>poll.lock);

if (events & pevents) {
-   if (!fence_add_callback(resv->fence_excl,
-   >cb, dma_buf_poll_cb))
+   if (!fence_add_callback(fence_excl, >cb,
+  dma_buf_poll_cb)) {
events &= ~pevents;
-   else
+   } else {
/*
 * No callback queued, wake up any additional
 * waiters.
 */
dma_buf_poll_cb(NULL, >cb);
+   }
}
}

-   if ((events & POLLOUT) && resv->fence_shared_count > 0) {
+   if ((events & POLLOUT) && shared_count > 0) {
struct dma_buf_poll_cb_t *dcb = >cb_shared;
int i;

@@ -194,15 +204,18 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
if (!(events & POLLOUT))
goto out;

-   for (i = 0; i < resv->fence_shared_count; ++i)
-   if (!fence_add_callback(resv->fence_shared[i],
-   >cb, dma_buf_poll_cb)) {
+   for (i = 0; i < shared_count; ++i) {
+   struct fence *fence = fobj->shared[i];
+
+   if (!fence_add_callback(fence, >cb,
+   dma_buf_poll_cb)) {
events &= ~POLLOUT;
break;
}
+   }

/* No callback queued, wake up any additional waiters. */
-   if (i == resv->fence_shared_count)
+   if (i == shared_count)
dma_buf_poll_cb(NULL, >cb);
}

diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index 8fff13fb86cf..f780f9b3d418 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -170,7 +170,7 @@ void release_fence(struct kref *kref)
if (fence->ops->release)
fence->ops->release(fence);
else
-   kfree(fence);
+   free_fence(fence);
 }
 EXPORT_SYMBOL(release_fence);

@@ -448,7 +448,7 @@ static void seqno_release(struct fence *fence)
if (f->ops->release)
f->ops->release(fence);
else
-   kfree(f);
+   free_fence(fence);
 }

 static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
index a73fbf3b8e56..b82a5b630a8e 100644
--- a/drivers/base/reservation.c
+++ 

[PATCH 0/2] Updates to fence api

[Maarten Lankhorst]

The following series implements small updates to the fence api.
I've found them useful when implementing the fence API in ttm and i915.

The last patch enables RCU on top of the api. I've found this less
useful, but it was the condition on which Thomas Hellstrom was ok
with converting TTM to fence, so I had to keep it in.

If nobody objects I'll probably merge that patch through drm, because
some care is needed in ttm before it can flip the switch on rcu.

---

Maarten Lankhorst (2):
  reservation: update api and add some helpers
  [RFC] reservation: add suppport for read-only access using rcu

[Bug 77244] New: UVD microcode fails to load on HD 8970M (Neptune XT -- PITCAIRN)

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

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

  Priority: medium
Bug ID: 77244
  Assignee: dri-devel at lists.freedesktop.org
   Summary: UVD microcode fails to load on HD 8970M (Neptune XT --
PITCAIRN)
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: nmschulte at gmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 97143
  --> https://bugs.freedesktop.org/attachment.cgi?id=97143=edit
Linux kernel log

I have a Clevo P150SM based laptop with an Intel HD 4600 iGPU and an AMD
Radeon HD 8970M dGPU.  I receive the following errors when the Radeon
DRI/DRM implementation attempts to initialize the card:

[   65.525470] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   66.537637] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   67.549797] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   68.561967] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   69.574142] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   70.586334] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   71.598533] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   72.610705] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   73.622877] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   74.635068] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   74.654938] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!!
[   74.654955] [drm:si_startup] *ERROR* radeon: failed initializing UVD (-1).


This appears to happen on video mode changes or vtty changes, I'm not
quite sure really what triggers it other than initial loading.  When it
does occur, the system appears to hang for a short time (15 seconds or
so) while the dGPU is active, and then "comes back" after the dGPU is
disabled.  The Clevo P150SM has an LED showing the dGPU power state,
and debugfs/vgaswitcheroo seems to corroborate this.

I'm also experiencing issues with PRIME (and e.g. xserver seg-faults when
building from source to try new code), but this issue exists out of the box on
Debian Sid, and seems to persist even with newer Mesa and DRM.  I have a bug
report for the PRIME/hybrid graphics issue as well, and it may end up that
these are related: https://bugs.freedesktop.org/show_bug.cgi?id=77094

Finally, this bug looks similar to mine, though I am not messing with PRIME (at
least explicitly; no xrandr --setprovider* calls and no DRI_PRIME env. var. is
set): https://bugs.freedesktop.org/show_bug.cgi?id=75234

There is a downstream bug report here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743659

-- 
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/20140409/e71c7432/attachment-0001.html>

[Intel-gfx] [PATCH] drm/mm: Don't WARN if drm_mm_reserve_node

[Ben Widawsky]

On Wed, Apr 09, 2014 at 07:25:37AM +0100, Chris Wilson wrote:
> On Tue, Apr 08, 2014 at 10:21:44AM -0700, Ben Widawsky wrote:
> > I am not convinced this is the correct solution. At least the way we
> > used this interface, it isn't meant to ever fail.  I also didn't look
> > into exactly why we depend an ENOSPC return. That sounds fragile to me,
> > especially for a public interface.
> 
> Eh? This interface is explicitly used to check that the requested range
> is available.
> -Chris
> 

What I mean is, the node is already initialized, and we always expect it
to be available - at least with all the callers prior to the fastboot.

I didn't look very closely at how we get the fb objects from the
existing stolen memory, but my drive-by review would suggest it's much
better to deal with the redundancy at that level (or make this an i915
private function).

Removing the WARN is fine with me though, it's:
Tested-by: Ben Widawsky 

My complaint was more with how we solved the problem initially, and not
with this patch itself.

-- 
Ben Widawsky, Intel Open Source Technology Center

[PATCHv2 2/3] drm: exynos: hdmi: use hdmiphy as PHY

[Rahul Sharma]

Hi Andrzej,

On 9 April 2014 16:00, Andrzej Hajda  wrote:
> Hi Tomasz,
>
> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>> The HDMIPHY (physical interface) is controlled by a single
>> bit in a power controller's regiter. It was implemented
>> as clock. It was a simple but effective hack.
>
> This power controller register has also bits to control HDMI clock
> divider ratio. I guess current drivers do not change it, but how do you
> want to implement access to it if some HDMI driver in the future will
> need to change ratio. I guess in case of clk it would be easier.

If it is really required to change this divider, it should be registered as
a clock provider in clock driver exposing single divider clock.

Regards,
Rahul Sharma

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

[Bug 77002] hdmi audio problems with 3.14

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

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

--- Comment #33 from bgunteriv at gmail.com ---
Garrett,
the part about reverting and patching was actually meant for Peter.



Peter,

It sounds like Takashi Iwai (comment #23)
is looking to go another direction to fix the problem with the kernel commit
(7546abfb8e1f9933b549f05898377e9444ee4cb2), as opposed to just patching it.

hopefully he can shed more light on this subject...

as I said. the patch works... but also reverting the commit on the original
kernel also 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/20140409/4c17fe73/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

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

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

--- Comment #32 from Garrett  ---
Yes I am gfisher.  

Peter.  OK. I renamed/saved the old pull.  I git pulled new.  I will rebuild
overnight.  Thx.

The logs that I upload- I applied this patch
https://bugs.freedesktop.org/attachment.cgi?id=97049=edit to kernel 3.14
in the oe build.  According to the messages it patched ...hda just fine.  It
did not appear to change anything (bug wise).  I did the logs in #29 over SSH
while the sounds were distorted.

I saw the revert commit comment.  But I am not sure that I can do that on an OE
system (I managed to get patches to work).  I am using OE because breakage and
testing across PC is so much easier.

I will rebuild the latest OE 4.0 branch from new, then report back.  Let me
know if anything else is needed.

-- 
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/20140409/6658cb0b/attachment.html>

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

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

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

--- Comment #71 from Hristo Venev  ---
rb_config&=0b1100; does not work(=run glxgears) anymore

-- 
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/20140409/c9bb53fd/attachment.html>

[PATCH] drm/tegra: Remove gratuitous pad field

[Thierry Reding]

On Wed, Apr 09, 2014 at 02:44:42PM +0200, Daniel Vetter wrote:
> cc: stable to make sure that even once you release userspace you won't
> get angry bug reports?

Yes, good point. I was just pondering whether doing that would be smart
or not. But I came to the same conclusion.

Thierry

> -Daniel
> 
> On Wed, Apr 9, 2014 at 2:39 PM, Thierry Reding  
> wrote:
> > From: Thierry Reding 
> >
> > The version of the drm_tegra_submit structure that was merged all the
> > way back in 3.10 contains a pad field that was originally intended to
> > properly pad the following __u64 field. Unfortunately it seems like a
> > different field was dropped during review that caused this padding to
> > become unnecessary, but the pad field wasn't removed at that time.
> >
> > One possible side-effect of this is that since the __u64 following the
> > pad is now no longer properly aligned, the compiler may (or may not)
> > introduce padding itself, which results in no predictable ABI.
> >
> > Rectify this by removing the pad field so that all fields are again
> > naturally aligned. Technically this is breaking existing userspace ABI,
> > but given that there aren't any (released) userspace drivers that make
> > use of this yet, the fallout should be minimal.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> >  include/uapi/drm/tegra_drm.h | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> > index b042b48495d9..b75482112428 100644
> > --- a/include/uapi/drm/tegra_drm.h
> > +++ b/include/uapi/drm/tegra_drm.h
> > @@ -120,7 +120,6 @@ struct drm_tegra_submit {
> > __u32 num_waitchks;
> > __u32 waitchk_mask;
> > __u32 timeout;
> > -   __u32 pad;
> > __u64 syncpts;
> > __u64 cmdbufs;
> > __u64 relocs;
> > --
> > 1.9.1
> >
> > ___
> > 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
-- 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/20140409/87e6dc23/attachment.sig>

[PATCH] drm/tegra: Remove gratuitous pad field

[Daniel Vetter]

cc: stable to make sure that even once you release userspace you won't
get angry bug reports?
-Daniel

On Wed, Apr 9, 2014 at 2:39 PM, Thierry Reding  
wrote:
> From: Thierry Reding 
>
> The version of the drm_tegra_submit structure that was merged all the
> way back in 3.10 contains a pad field that was originally intended to
> properly pad the following __u64 field. Unfortunately it seems like a
> different field was dropped during review that caused this padding to
> become unnecessary, but the pad field wasn't removed at that time.
>
> One possible side-effect of this is that since the __u64 following the
> pad is now no longer properly aligned, the compiler may (or may not)
> introduce padding itself, which results in no predictable ABI.
>
> Rectify this by removing the pad field so that all fields are again
> naturally aligned. Technically this is breaking existing userspace ABI,
> but given that there aren't any (released) userspace drivers that make
> use of this yet, the fallout should be minimal.
>
> Signed-off-by: Thierry Reding 
> ---
>  include/uapi/drm/tegra_drm.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index b042b48495d9..b75482112428 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -120,7 +120,6 @@ struct drm_tegra_submit {
> __u32 num_waitchks;
> __u32 waitchk_mask;
> __u32 timeout;
> -   __u32 pad;
> __u64 syncpts;
> __u64 cmdbufs;
> __u64 relocs;
> --
> 1.9.1
>
> ___
> 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

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Rahul Sharma]

Hi Tomasz,

On 9 April 2014 14:07, Andrzej Hajda  wrote:
> Hi Tomasz,
>
> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>> Add exynos-simple-phy driver to support a single register
>> PHY interfaces present on Exynos4 SoC.
>>
>> Signed-off-by: Tomasz Stanislawski 
>> ---
>>  .../devicetree/bindings/phy/samsung-phy.txt|   24 +++
>>  drivers/phy/Kconfig|5 +
>>  drivers/phy/Makefile   |1 +
>>  drivers/phy/exynos-simple-phy.c|  154 
>> 
>>  4 files changed, 184 insertions(+)
>>  create mode 100644 drivers/phy/exynos-simple-phy.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index b422e38..f97c4c3 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -114,3 +114,27 @@ Example:
>>   compatible = "samsung,exynos-sataphy-i2c";
>>   reg = <0x38>;
>>   };
>> +
>> +Samsung S5P/EXYNOS SoC series SIMPLE PHY
>> +-
>> +
>> +Required properties:
>> +- compatible : should be one of the listed compatibles:
>> + - "samsung,exynos4210-simple-phy"
>> + - "samsung,exynos4412-simple-phy"
>> +- reg : offset and length of the register set;
>> +- #phy-cells : from the generic phy bindings, must be 1;
>> +
>> +For "samsung,exynos4210-simple-phy" compatible PHYs the second cell in
>> +the PHY specifier identifies the PHY and its meaning is as follows:
>> +  0 - HDMI PHY,
>> +  1 - DAC PHY,
>> +  2 - ADC PHY,
>> +  3 - PCIE PHY.
>> +  4 - SATA PHY.
>> +
>> +For "samsung,exynos4412-simple-phy" compatible PHYs the second cell in
>> +the PHY specifier identifies the PHY and its meaning is as follows:
>> +  0 - HDMI PHY,
>> +  1 - ADC PHY,
>
> What about using preprocessor macros?
>
>> +
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 3bb05f1..65ab783 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -166,4 +166,9 @@ config PHY_XGENE
>>   help
>> This option enables support for APM X-Gene SoC multi-purpose PHY.
>>
>> +config EXYNOS_SIMPLE_PHY
>> + tristate "Exynos Simple PHY driver"
>> + help
>> +   Support for 1-bit PHY controllers on SoCs from Exynos family.
>> +
>>  endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 2faf78e..88c5b60 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2)   += 
>> phy-exynos4210-usb2.o
>>  obj-$(CONFIG_PHY_EXYNOS4X12_USB2)+= phy-exynos4x12-usb2.o
>>  obj-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o
>>  obj-$(CONFIG_PHY_XGENE)  += phy-xgene.o
>> +obj-$(CONFIG_EXYNOS_SIMPLE_PHY)  += exynos-simple-phy.o
>> diff --git a/drivers/phy/exynos-simple-phy.c 
>> b/drivers/phy/exynos-simple-phy.c
>> new file mode 100644
>> index 000..57ad338
>> --- /dev/null
>> +++ b/drivers/phy/exynos-simple-phy.c
>> @@ -0,0 +1,154 @@
>> +/*
>> + * Exynos Simple PHY driver
>> + *
>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Tomasz Stanislawski 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define EXYNOS_PHY_ENABLE(1 << 0)
>> +
>> +static int exynos_phy_power_on(struct phy *phy)
>> +{
>> + void __iomem *reg = phy_get_drvdata(phy);
>> + u32 val;
>> +
>> + val = readl(reg);
>> + val |= EXYNOS_PHY_ENABLE;
>> + writel(val, reg);
>> +
>> + return 0;
>> +}
>> +
>> +static int exynos_phy_power_off(struct phy *phy)
>> +{
>> + void __iomem *reg = phy_get_drvdata(phy);
>> + u32 val;
>> +
>> + val = readl(reg);
>> + val &= ~EXYNOS_PHY_ENABLE;
>> + writel(val, reg);
>> +
>> + return 0;
>> +}
>> +
>> +static struct phy_ops exynos_phy_ops = {
>> + .power_on   = exynos_phy_power_on,
>> + .power_off  = exynos_phy_power_off,
>> + .owner  = THIS_MODULE,
>> +};
>> +
>> +static const u32 exynos4210_offsets[] = {
>> + 0x0700, /* HDMI_PHY */
>> + 0x070C, /* DAC_PHY */
>> + 0x0718, /* ADC_PHY */
>> + 0x071C, /* PCIE_PHY */
>> + 0x0720, /* SATA_PHY */
>> + ~0, /* end mark */
>> +};
>> +
>> +static const u32 exynos4412_offsets[] = {
>> + 0x0700, /* HDMI_PHY */
>> + 0x0718, /* ADC_PHY */
>> + ~0, /* end mark */
>> +};
>
> Why have you selected only these registers?
> According to specs Exynos 4210 has 9 and 4412 has 7 control registers
> with 'phy-enable' functionality.
> I guess MIPI would require little more work as it has also reset bits,
> but it will be still 

[Bug 77002] hdmi audio problems with 3.14

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

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

--- Comment #31 from bgunteriv at gmail.com ---
(In reply to comment #29)
> Garret,
> 
> make sure your tree is in sync. The patch done by Anssi has already been
> included. It's here:
> https://github.com/OpenELEC/OpenELEC.tv/commit/
> a333166f7d6fda668cc2184797d302fe89288c9d

make sure you read the comments about what Takashi Iwa wrote (comment #23)
i'm not sure how this will change things.
--quote-
I'd rather revert the commit in this case.  Changing the assignment order has a
significant risk of breakage with other weird controllers.

Could you confirm that just reverting the commit fixes the problem?  Once after
it's confirmed, I'll submit a fix revert patch for 3.14.x.  Thanks.
---quote

@Garrett, are you @gfisher on the XBMC forums?
if so, I'm not sure if this is the same issue. I was having problems with the
new kernel working with my OS. this did not solve my problem. I think we'll
have to create a new bug report for that one.
let me know on the XBMC forum if this did clear your problem... would be very
interesting.

-- 
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/20140409/a570e042/attachment.html>

[PATCH] drm/tegra: Remove gratuitous pad field

[Thierry Reding]

From: Thierry Reding 

The version of the drm_tegra_submit structure that was merged all the
way back in 3.10 contains a pad field that was originally intended to
properly pad the following __u64 field. Unfortunately it seems like a
different field was dropped during review that caused this padding to
become unnecessary, but the pad field wasn't removed at that time.

One possible side-effect of this is that since the __u64 following the
pad is now no longer properly aligned, the compiler may (or may not)
introduce padding itself, which results in no predictable ABI.

Rectify this by removing the pad field so that all fields are again
naturally aligned. Technically this is breaking existing userspace ABI,
but given that there aren't any (released) userspace drivers that make
use of this yet, the fallout should be minimal.

Signed-off-by: Thierry Reding 
---
 include/uapi/drm/tegra_drm.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index b042b48495d9..b75482112428 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -120,7 +120,6 @@ struct drm_tegra_submit {
__u32 num_waitchks;
__u32 waitchk_mask;
__u32 timeout;
-   __u32 pad;
__u64 syncpts;
__u64 cmdbufs;
__u64 relocs;
-- 
1.9.1

[Bug 77002] hdmi audio problems with 3.14

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

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

--- Comment #30 from Garrett  ---
Created attachment 97138
  --> https://bugs.freedesktop.org/attachment.cgi?id=97138=edit
mp3 of distorted HDMI sounds

mp3 of playing a video with the HDMI sound distortion from TV speakers.

-- 
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/20140409/2343d443/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

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

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

--- Comment #29 from Peter Fr?hberger  ---
Garret,

make sure your tree is in sync. The patch done by Anssi has already been
included. It's here:
https://github.com/OpenELEC/OpenELEC.tv/commit/a333166f7d6fda668cc2184797d302fe89288c9d

-- 
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/20140409/a32f25af/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

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

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

--- Comment #28 from Garrett  ---
Created attachment 97137
  --> https://bugs.freedesktop.org/attachment.cgi?id=97137=edit
debug logs of hdmi audio distortion with reverse order patch

Hi,
Hope that this is the correct place.  Let me know if you wish for me to open a
new bug report.

I'm using an Openelec git pulled local build- so that I can test patches (w/wo
reverse order patch from this thread): 

My dedicated Radeon 7750 card only outputs cyclical sounds, quiet voices like
wrong channel, and echos. Setup PC to TV directly HDMI (2.0 audio selected). I
have had the same issue when cpu was an AMD 955BE, and now Intel i7 4770.

Windows 7 plays hdmi audio just fine on the same exact PC/Panasonic
plasma/setup.  

TIA.
Garrett

-- 
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/20140409/f04fba03/attachment.html>

[PATCH v12][ 09/12] drm/panel: Add Eukrea mbimxsd51 displays.

[Thierry Reding]

On Mon, Apr 07, 2014 at 02:44:48PM +0200, Denis Carikli wrote:
[...]
> +static const struct panel_desc eukrea_mbimxsd51_dvisvga = {
> + .modes = _mbimxsd51_dvisvga_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 0,
> + .height = 0,
> + },
> +};
[...]
> +static const struct panel_desc eukrea_mbimxsd51_dvivga = {
> + .modes = _mbimxsd51_dvivga_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 0,
> + .height = 0,
> + },
> +};

Surely these two panels have a physical size?

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/20140409/1168cba1/attachment-0001.sig>

[PATCH] fix memory leak

[Micah Richert]

Signed-off-by: Micah Richert 
---
 drivers/gpu/drm/msm/msm_gem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 16f643a..885cf56 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -118,8 +118,10 @@ static void put_pages(struct drm_gem_object *obj)

if (iommu_present(_bus_type))
drm_gem_put_pages(obj, msm_obj->pages, true, false);
-   else
+   else {
drm_mm_remove_node(msm_obj->vram_node);
+   drm_free_large(msm_obj->pages);
+   }

msm_obj->pages = NULL;
}
-- 
1.8.3.2

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Andreas Oberritter]

Hello Andrzej,

On 09.04.2014 10:37, Andrzej Hajda wrote:
>> +static int exynos_phy_probe(struct platform_device *pdev)
>> +{
>> +const struct of_device_id *of_id = of_match_device(
>> +of_match_ptr(exynos_phy_of_match), >dev);
>> +const u32 *offsets = of_id->data;
>> +int count;
>> +struct device *dev = >dev;
>> +struct phy **phys;
>> +struct resource *res;
>> +void __iomem *regs;
>> +int i;
>> +struct phy_provider *phy_provider;
>> +
>> +/* count number of phys to create */
>> +for (count = 0; offsets[count] != ~0; ++count)
>> +;
> 
> count = ARRAY_SIZE(offsets) - 1;

u32 *offsets is not an array.

Regards,
Andreas

[Bug 76559] screen corruption after going from VT to X

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

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

Fabio Pedretti  changed:

   What|Removed |Added

  Component|DRM/Radeon  |General

--- Comment #3 from Fabio Pedretti  ---
This issue is still reproducible with Ubuntu 14.04 kernel (3.13.0-23.45),
before I was using 3.11.0-18.32 (Ubuntu 13.10 kernel).

This annoying issue is possibly not specific to radeon module. The following
dmesg ERROR is interesting and may be of help. Maybe it needs a monitor quirk?

[3.398641] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 58
[3.398646] Raw EDID:
[3.398652]  00 ff ff ff ff ff ff 00 06 10 56 9c 00 00 00 00
[3.398656]  04 10 01 03 80 22 16 78 0a 87 f5 94 57 4f 8c 27
[3.398660]  27 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[3.398664]  01 98 03 a2 01 01 9f 25 a0 40 51 84 0c 30 40 20
[3.398669]  33 00 4b cf 10 00 00 19 00 00 00 01 00 06 10 30
[3.398673]  00 00 00 00 00 00 00 00 0a 20 00 00 00 fe 00 4c
[3.398677]  54 4e 31 35 34 58 37 00 00 00 0a 20 00 00 00 fc
[3.398681]  00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20 00 d5
[3.427467] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 58
[3.427471] Raw EDID:
[3.427475]  00 ff ff ff ff ff ff 00 06 10 56 9c 00 00 00 00
[3.427479]  04 10 01 03 80 22 16 78 0a 87 f5 94 57 4f 8c 27
[3.427483]  27 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[3.427487]  01 98 03 a2 01 01 9f 25 a0 40 51 84 0c 30 40 20
[3.427491]  33 00 4b cf 10 00 00 19 00 00 00 01 00 06 10 30
[3.427495]  00 00 00 00 00 00 00 00 0a 20 00 00 00 fe 00 4c
[3.427499]  54 4e 31 35 34 58 37 00 00 00 0a 20 00 00 00 fc
[3.427503]  00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20 00 d5
[3.456273] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 58
[3.456278] Raw EDID:
[3.456283]  00 ff ff ff ff ff ff 00 06 10 56 9c 00 00 00 00
[3.456287]  04 10 01 03 80 22 16 78 0a 87 f5 94 57 4f 8c 27
[3.456292]  27 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[3.456296]  01 98 03 a2 01 01 9f 25 a0 40 51 84 0c 30 40 20
[3.456300]  33 00 4b cf 10 00 00 19 00 00 00 01 00 06 10 30
[3.456304]  00 00 00 00 00 00 00 00 0a 20 00 00 00 fe 00 4c
[3.456308]  54 4e 31 35 34 58 37 00 00 00 0a 20 00 00 00 fc
[3.456312]  00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20 00 d5
[3.484997] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 58
[3.485001] Raw EDID:
[3.485005]  00 ff ff ff ff ff ff 00 06 10 56 9c 00 00 00 00
[3.485009]  04 10 01 03 80 22 16 78 0a 87 f5 94 57 4f 8c 27
[3.485013]  27 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
[3.485017]  01 98 03 a2 01 01 9f 25 a0 40 51 84 0c 30 40 20
[3.485021]  33 00 4b cf 10 00 00 19 00 00 00 01 00 06 10 30
[3.485025]  00 00 00 00 00 00 00 00 0a 20 00 00 00 fe 00 4c
[3.485029]  54 4e 31 35 34 58 37 00 00 00 0a 20 00 00 00 fc
[3.485033]  00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20 00 d5
[3.485041] radeon :01:00.0: LVDS-1: EDID block 0 invalid.

-- 
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/20140409/72374c56/attachment-0001.html>

[PATCH v2 libdrm 7/7] libdrm: valgrind-clear a few more IOCTL arguments

[Thierry Reding]

From: Thierry Reding 

Fixes a few complaints raised by valgrind when running the Tegra tests.

Signed-off-by: Thierry Reding 
---
 xf86drmMode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index a6bb2ee44576..861248b7c2fc 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -282,6 +282,7 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
struct drm_mode_fb_cmd2 f;
int ret;

+   VG_CLEAR(f);
f.width  = width;
f.height = height;
f.pixel_format = pixel_format;
@@ -309,6 +310,7 @@ drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
struct drm_mode_fb_cmd info;
drmModeFBPtr r;

+   VG_CLEAR(info);
info.fb_id = buf;

if (drmIoctl(fd, DRM_IOCTL_MODE_GETFB, ))
-- 
1.9.1

[PATCH v2 libdrm 6/7] tegra: Add gr2d-fill test

[Thierry Reding]

From: Thierry Reding 

This test uses the IOCTLs for job submission and fences to fill a sub-
region of the screen to a specific color using gr2d.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- free framebuffer when done

 tests/tegra/.gitignore  |   1 +
 tests/tegra/Makefile.am |   1 +
 tests/tegra/gr2d-fill.c | 146 
 3 files changed, 148 insertions(+)
 create mode 100644 tests/tegra/gr2d-fill.c

diff --git a/tests/tegra/.gitignore b/tests/tegra/.gitignore
index 5c5216c5c5e6..5e0b5c601dd1 100644
--- a/tests/tegra/.gitignore
+++ b/tests/tegra/.gitignore
@@ -1 +1,2 @@
+gr2d-fill
 openclose
diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am
index e468029d152e..286af4b4d706 100644
--- a/tests/tegra/Makefile.am
+++ b/tests/tegra/Makefile.am
@@ -19,6 +19,7 @@ LDADD = \

 TESTS = \
openclose \
+   gr2d-fill

 if HAVE_INSTALL_TESTS
 testdir = $(libexecdir)/libdrm/tests/tegra
diff --git a/tests/tegra/gr2d-fill.c b/tests/tegra/gr2d-fill.c
new file mode 100644
index ..b6ba35a9d668
--- /dev/null
+++ b/tests/tegra/gr2d-fill.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright ? 2014 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#  include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "xf86drm.h"
+#include "xf86drmMode.h"
+#include "drm_fourcc.h"
+
+#include "drm-test-tegra.h"
+#include "tegra.h"
+
+int main(int argc, char *argv[])
+{
+   uint32_t format = DRM_FORMAT_XRGB;
+   struct drm_tegra_gr2d *gr2d;
+   struct drm_framebuffer *fb;
+   struct drm_screen *screen;
+   unsigned int pitch, size;
+   struct drm_tegra_bo *bo;
+   struct drm_tegra *drm;
+   uint32_t handle;
+   int fd, err;
+   void *ptr;
+
+   fd = drm_open(argv[1]);
+   if (fd < 0) {
+   fprintf(stderr, "failed to open DRM device %s: %s\n", argv[1],
+   strerror(errno));
+   return 1;
+   }
+
+   err = drm_screen_open(, fd);
+   if (err < 0) {
+   fprintf(stderr, "failed to open screen: %s\n", strerror(-err));
+   return 1;
+   }
+
+   err = drm_tegra_new(, fd);
+   if (err < 0) {
+   fprintf(stderr, "failed to create Tegra DRM context: %s\n",
+   strerror(-err));
+   return 1;
+   }
+
+   err = drm_tegra_gr2d_open(, drm);
+   if (err < 0) {
+   fprintf(stderr, "failed to open gr2d channel: %s\n",
+   strerror(-err));
+   return 1;
+   }
+
+   pitch = screen->width * screen->bpp / 8;
+   size = pitch * screen->height;
+
+   err = drm_tegra_bo_new(, drm, 0, size);
+   if (err < 0) {
+   fprintf(stderr, "failed to create buffer object: %s\n",
+   strerror(-err));
+   return 1;
+   }
+
+   err = drm_tegra_bo_get_handle(bo, );
+   if (err < 0) {
+   fprintf(stderr, "failed to get handle to buffer object: %s\n",
+   strerror(-err));
+   return 1;
+   }
+
+   err = drm_tegra_bo_map(bo, );
+   if (err < 0) {
+   fprintf(stderr, "failed to map buffer object: %s\n",
+   strerror(-err));
+   return 1;
+   }
+
+   memset(ptr, 0xff, size);
+
+   err = drm_framebuffer_new(, screen, handle, screen->width,
+ screen->height, pitch, format, bo);
+   if (err < 0) {
+   fprintf(stderr, "failed to create framebuffer: %s\n",
+   strerror(-err));
+   return 1;
+   }
+
+   err = drm_screen_set_framebuffer(screen, fb);
+   if (err < 0) {
+   fprintf(stderr, "failed to display framebuffer: 

[PATCH v2 libdrm 5/7] tegra: Add helper library for tests

[Thierry Reding]

From: Thierry Reding 

This library provides helpers for common functionality needed by test
programs.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- fix a couple of memory leaks and get rid of some unneeded code

 tests/tegra/Makefile.am  |  10 +-
 tests/tegra/drm-test-tegra.c | 137 
 tests/tegra/drm-test-tegra.h |  55 ++
 tests/tegra/drm-test.c   | 248 +++
 tests/tegra/drm-test.h   |  72 +
 5 files changed, 521 insertions(+), 1 deletion(-)
 create mode 100644 tests/tegra/drm-test-tegra.c
 create mode 100644 tests/tegra/drm-test-tegra.h
 create mode 100644 tests/tegra/drm-test.c
 create mode 100644 tests/tegra/drm-test.h

diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am
index 8b481bde4f11..e468029d152e 100644
--- a/tests/tegra/Makefile.am
+++ b/tests/tegra/Makefile.am
@@ -5,9 +5,17 @@ AM_CPPFLAGS = \

 AM_CFLAGS = -Wall -Werror

+noinst_LTLIBRARIES = libdrm-test.la
+libdrm_test_la_SOURCES = \
+   drm-test.c \
+   drm-test.h \
+   drm-test-tegra.c \
+   drm-test-tegra.h
+
 LDADD = \
../../tegra/libdrm_tegra.la \
-   ../../libdrm.la
+   ../../libdrm.la \
+   libdrm-test.la

 TESTS = \
openclose \
diff --git a/tests/tegra/drm-test-tegra.c b/tests/tegra/drm-test-tegra.c
new file mode 100644
index ..aed353af739b
--- /dev/null
+++ b/tests/tegra/drm-test-tegra.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright ? 2014 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#  include "config.h"
+#endif
+
+#include 
+#include 
+
+#include "drm-test-tegra.h"
+#include "tegra.h"
+
+int drm_tegra_gr2d_open(struct drm_tegra_gr2d **gr2dp, struct drm_tegra *drm)
+{
+   struct drm_tegra_gr2d *gr2d;
+   int err;
+
+   gr2d = calloc(1, sizeof(*gr2d));
+   if (!gr2d)
+   return -ENOMEM;
+
+   gr2d->drm = drm;
+
+   err = drm_tegra_channel_open(>channel, drm, DRM_TEGRA_GR2D);
+   if (err < 0) {
+   free(gr2d);
+   return err;
+   }
+
+   *gr2dp = gr2d;
+
+   return 0;
+}
+
+int drm_tegra_gr2d_close(struct drm_tegra_gr2d *gr2d)
+{
+   if (!gr2d)
+   return -EINVAL;
+
+   drm_tegra_channel_close(gr2d->channel);
+   free(gr2d);
+
+   return 0;
+}
+
+int drm_tegra_gr2d_fill(struct drm_tegra_gr2d *gr2d, struct drm_framebuffer 
*fb,
+   unsigned int x, unsigned int y, unsigned int width,
+   unsigned int height, uint32_t color)
+{
+   struct drm_tegra_bo *fbo = fb->data;
+   struct drm_tegra_pushbuf *pushbuf;
+   struct drm_tegra_fence *fence;
+   struct drm_tegra_job *job;
+   int err;
+
+   err = drm_tegra_job_new(, gr2d->channel);
+   if (err < 0)
+   return err;
+
+   err = drm_tegra_pushbuf_new(, job);
+   if (err < 0)
+   return err;
+
+   err = drm_tegra_pushbuf_prepare(pushbuf, 32);
+   if (err < 0)
+   return err;
+
+   *pushbuf->ptr++ = HOST1X_OPCODE_SETCL(0, HOST1X_CLASS_GR2D, 0);
+
+   *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x9, 0x9);
+   *pushbuf->ptr++ = 0x003a;
+   *pushbuf->ptr++ = 0x;
+
+   *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x1e, 0x7);
+   *pushbuf->ptr++ = 0x;
+   *pushbuf->ptr++ = (2 << 16) | (1 << 6) | (1 << 2);
+   *pushbuf->ptr++ = 0x00cc;
+
+   *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x2b, 0x9);
+
+   /* relocate destination buffer */
+   err = drm_tegra_pushbuf_relocate(pushbuf, fbo, 0, 0);
+   if (err < 0) {
+   fprintf(stderr, "failed to relocate buffer object: %d\n", err);
+   return err;
+   }
+
+   *pushbuf->ptr++ = fb->pitch;
+
+   *pushbuf->ptr++ = HOST1X_OPCODE_NONINCR(0x35, 1);
+   *pushbuf->ptr++ = color;
+
+   

[PATCH v2 libdrm 4/7] tegra: Add channel, job, pushbuf and fence APIs

[Thierry Reding]

From: Thierry Reding 

These functions can be used to open channels to engines, manage job
submissions, create push buffers to store command streams in and wait
until jobs have been completed.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- automatically allocate buffer objects as required by pushbuffers
- pushbuffers can now have more than one associated buffer object
- add drm_tegra_pushbuf_prepare() function

 tegra/Makefile.am |   4 ++
 tegra/channel.c   | 127 +
 tegra/fence.c |  71 +++
 tegra/job.c   | 180 +++
 tegra/private.h   |  72 +++
 tegra/pushbuf.c   | 205 ++
 tegra/tegra.c |   2 +
 tegra/tegra.h |  52 ++
 8 files changed, 713 insertions(+)
 create mode 100644 tegra/channel.c
 create mode 100644 tegra/fence.c
 create mode 100644 tegra/job.c
 create mode 100644 tegra/pushbuf.c

diff --git a/tegra/Makefile.am b/tegra/Makefile.am
index 1b83145b120d..c73587e8661e 100644
--- a/tegra/Makefile.am
+++ b/tegra/Makefile.am
@@ -11,6 +11,10 @@ libdrm_tegra_la_LDFLAGS = -version-number 0:0:0 -no-undefined
 libdrm_tegra_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@

 libdrm_tegra_la_SOURCES = \
+   channel.c \
+   fence.c \
+   job.c \
+   pushbuf.c \
tegra.c

 libdrm_tegraincludedir = ${includedir}/libdrm
diff --git a/tegra/channel.c b/tegra/channel.c
new file mode 100644
index ..3ab1d578f8e5
--- /dev/null
+++ b/tegra/channel.c
@@ -0,0 +1,127 @@
+/*
+ * Copyright ? 2012, 2013 Thierry Reding
+ * Copyright ? 2013 Erik Faye-Lund
+ * Copyright ? 2014 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#  include "config.h"
+#endif
+
+#include 
+#include 
+
+#include "private.h"
+
+static int drm_tegra_channel_setup(struct drm_tegra_channel *channel)
+{
+   struct drm_tegra *drm = channel->drm;
+   struct drm_tegra_get_syncpt args;
+   int err;
+
+   memset(, 0, sizeof(args));
+   args.context = channel->context;
+   args.index = 0;
+
+   err = ioctl(drm->fd, DRM_IOCTL_TEGRA_GET_SYNCPT, );
+   if (err < 0)
+   return -errno;
+
+   channel->syncpt = args.id;
+
+   return 0;
+}
+
+drm_public
+int drm_tegra_channel_open(struct drm_tegra_channel **channelp,
+  struct drm_tegra *drm,
+  enum drm_tegra_class client)
+{
+   struct drm_tegra_open_channel args;
+   struct drm_tegra_channel *channel;
+   enum host1x_class class;
+   int err;
+
+   switch (client) {
+   case DRM_TEGRA_GR2D:
+   class = HOST1X_CLASS_GR2D;
+   break;
+
+   case DRM_TEGRA_GR3D:
+   class = HOST1X_CLASS_GR3D;
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
+   channel = calloc(1, sizeof(*channel));
+   if (!channel)
+   return -ENOMEM;
+
+   channel->drm = drm;
+
+   memset(, 0, sizeof(args));
+   args.client = class;
+
+   err = ioctl(drm->fd, DRM_IOCTL_TEGRA_OPEN_CHANNEL, );
+   if (err < 0) {
+   free(channel);
+   return -errno;
+   }
+
+   channel->context = args.context;
+   channel->class = class;
+
+   err = drm_tegra_channel_setup(channel);
+   if (err < 0) {
+   free(channel);
+   return err;
+   }
+
+   *channelp = channel;
+
+   return 0;
+}
+
+drm_public
+int drm_tegra_channel_close(struct drm_tegra_channel *channel)
+{
+   struct drm_tegra_close_channel args;
+   struct drm_tegra *drm;
+   int err;
+
+   if (!channel)
+   return -EINVAL;
+
+   drm = channel->drm;
+
+   memset(, 0, sizeof(args));
+   args.context = channel->context;
+
+   err = 

[PATCH v2 libdrm 3/7] tegra: Add simple test for drm_tegra_open()

[Thierry Reding]

From: Thierry Reding 

This test opens a device, dumps the version information and checks that
a Tegra DRM context can be opened on it.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- fix in-tree build failure

 configure.ac|  1 +
 tests/Makefile.am   |  4 
 tests/tegra/.gitignore  |  1 +
 tests/tegra/Makefile.am | 22 +
 tests/tegra/openclose.c | 63 +
 5 files changed, 91 insertions(+)
 create mode 100644 tests/tegra/.gitignore
 create mode 100644 tests/tegra/Makefile.am
 create mode 100644 tests/tegra/openclose.c

diff --git a/configure.ac b/configure.ac
index 4cb6810bd6a8..e4cf70b1520b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -422,6 +422,7 @@ AC_CONFIG_FILES([
tests/radeon/Makefile
tests/vbltest/Makefile
tests/exynos/Makefile
+   tests/tegra/Makefile
include/Makefile
include/drm/Makefile
man/Makefile
diff --git a/tests/Makefile.am b/tests/Makefile.am
index cd1149130214..0a3d21f2d99f 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -24,6 +24,10 @@ if HAVE_EXYNOS
 SUBDIRS += exynos
 endif

+if HAVE_TEGRA
+SUBDIRS += tegra
+endif
+
 if HAVE_LIBUDEV

 check_LTLIBRARIES = libdrmtest.la
diff --git a/tests/tegra/.gitignore b/tests/tegra/.gitignore
new file mode 100644
index ..5c5216c5c5e6
--- /dev/null
+++ b/tests/tegra/.gitignore
@@ -0,0 +1 @@
+openclose
diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am
new file mode 100644
index ..8b481bde4f11
--- /dev/null
+++ b/tests/tegra/Makefile.am
@@ -0,0 +1,22 @@
+AM_CPPFLAGS = \
+   -I$(top_srcdir)/include/drm \
+   -I$(top_srcdir)/tegra \
+   -I$(top_srcdir)
+
+AM_CFLAGS = -Wall -Werror
+
+LDADD = \
+   ../../tegra/libdrm_tegra.la \
+   ../../libdrm.la
+
+TESTS = \
+   openclose \
+
+if HAVE_INSTALL_TESTS
+testdir = $(libexecdir)/libdrm/tests/tegra
+test_PROGRAMS = \
+   $(TESTS)
+else
+noinst_PROGRAMS = $(TESTS)
+check_PROGRAMS = $(TESTS)
+endif
diff --git a/tests/tegra/openclose.c b/tests/tegra/openclose.c
new file mode 100644
index ..5b4230c774f6
--- /dev/null
+++ b/tests/tegra/openclose.c
@@ -0,0 +1,63 @@
+/*
+ * Copyright ? 2014 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#  include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+#include "xf86drm.h"
+#include "tegra.h"
+
+int main(int argc, char *argv[])
+{
+   struct drm_tegra *tegra;
+   drmVersionPtr version;
+   int err, fd;
+
+   fd = open(argv[1], O_RDWR);
+   if (fd < 0)
+   return 1;
+
+   version = drmGetVersion(fd);
+   if (version) {
+   printf("Version: %d.%d.%d\n", version->version_major,
+  version->version_minor, version->version_patchlevel);
+   printf("  Name: %s\n", version->name);
+   printf("  Date: %s\n", version->date);
+   printf("  Description: %s\n", version->desc);
+
+   drmFreeVersion(version);
+   }
+
+   err = drm_tegra_new(, fd);
+   if (err < 0)
+   return 1;
+
+   drm_tegra_close(tegra);
+   close(fd);
+
+   return 0;
+}
-- 
1.9.1

[PATCH v2 libdrm 2/7] libdrm: Add NVIDIA Tegra support

[Thierry Reding]

From: Thierry Reding 

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 
Signed-off-by: Erik Faye-Lund 
Signed-off-by: Thierry Reding 
---
 Makefile.am   |   6 +-
 configure.ac  |  15 ++-
 include/drm/Makefile.am   |   1 +
 include/drm/tegra_drm.h   | 155 
 tegra/.gitignore  |   1 +
 tegra/Makefile.am |  20 
 tegra/libdrm_tegra.pc.in  |  11 ++
 tegra/private.h   |  51 ++
 tegra/tegra.c | 253 ++
 tegra/tegra.h |  47 +
 tests/modetest/modetest.c |   2 +-
 tests/vbltest/vbltest.c   |   2 +-
 12 files changed, 560 insertions(+), 4 deletions(-)
 create mode 100644 include/drm/tegra_drm.h
 create mode 100644 tegra/.gitignore
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/private.h
 create mode 100644 tegra/tegra.c
 create mode 100644 tegra/tegra.h

diff --git a/Makefile.am b/Makefile.am
index 826c30d0c0d9..14c402dce74f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -51,7 +51,11 @@ if HAVE_FREEDRENO
 FREEDRENO_SUBDIR = freedreno
 endif

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

 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 22b45cc7560d..4cb6810bd6a8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -98,6 +98,11 @@ AC_ARG_ENABLE(freedreno-experimental-api,
  [Enable support for freedreno's experimental API (default: 
disabled)]),
  [FREEDRENO=$enableval], [FREEDRENO=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])
+
 AC_ARG_ENABLE(install-test-programs,
  AS_HELP_STRING([--enable-install-test-programs],
  [Install test programs (default: no)]),
@@ -219,6 +224,11 @@ if test "x$FREEDRENO" = xyes; then
AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno 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
+
 AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes])
 if test "x$INSTALL_TESTS" = xyes; then
AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs])
@@ -270,7 +280,7 @@ else
 fi
 AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test "x$HAVE_MANPAGES_STYLESHEET" 
= "xyes"])

-if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o 
"x$OMAP" != "xno" -o "x$FREEDRENO" != "xno"; then
+if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o 
"x$OMAP" != "xno" -o "x$FREEDRENO" != "xno" -o "x$TEGRA" != "xno"; then
 # Check for atomic intrinsics
 AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives,
 [
@@ -403,6 +413,8 @@ AC_CONFIG_FILES([
exynos/libdrm_exynos.pc
freedreno/Makefile
freedreno/libdrm_freedreno.pc
+   tegra/Makefile
+   tegra/libdrm_tegra.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -427,4 +439,5 @@ echo "  Nouveau API$NOUVEAU"
 echo "  OMAP API   $OMAP"
 echo "  EXYNOS API $EXYNOS"
 echo "  Freedreno API  $FREEDRENO"
+echo "  Tegra API  $TEGRA"
 echo ""
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 2bc34d2ffd9f..f591abc45152 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 \
qxl_drm.h
diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
new file mode 100644
index ..1b8b7c1edef7
--- /dev/null
+++ b/include/drm/tegra_drm.h
@@ -0,0 +1,155 @@
+/*
+ * Copyright (c) 2012-2013, NVIDIA CORPORATION.  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, 

[PATCH v2 libdrm 1/7] configure: Support symbol visibility when available

[Thierry Reding]

From: Thierry Reding 

Checks whether or not the compiler supports the -fvisibility option. If
so it sets the VISIBILITY_CFLAGS variable which can be added to the per
directory AM_CFLAGS where appropriate.

By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
drm_public macro can be used to mark symbols that should be exported.

Signed-off-by: Thierry Reding 
---
 configure.ac | 20 
 libdrm.h | 34 ++
 2 files changed, 54 insertions(+)
 create mode 100644 libdrm.h

diff --git a/configure.ac b/configure.ac
index b7eef9673a20..22b45cc7560d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -366,6 +366,26 @@ AC_ARG_WITH([kernel-source],
[kernel_source="$with_kernel_source"])
 AC_SUBST(kernel_source)

+dnl Add flags for gcc and g++
+if test "x$GCC" = xyes; then
+# Enable -fvisibility=hidden if using a gcc that supports it
+save_CFLAGS="$CFLAGS"
+AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
+VISIBILITY_CFLAGS="-fvisibility=hidden"
+CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
+AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
+   [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
+
+# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
+CFLAGS=$save_CFLAGS
+
+if test "x$VISIBILITY_CFLAGS" != x; then
+AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler has -fvisibility support])
+fi
+
+AC_SUBST([VISIBILITY_CFLAGS])
+fi
+
 AC_SUBST(WARN_CFLAGS)
 AC_CONFIG_FILES([
Makefile
diff --git a/libdrm.h b/libdrm.h
new file mode 100644
index ..23926e6f6741
--- /dev/null
+++ b/libdrm.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright ? 2014 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef LIBDRM_LIBDRM_H
+#define LIBDRM_LIBDRM_H
+
+#if defined(HAVE_VISIBILITY)
+#  define drm_private __attribute__((visibility("hidden")))
+#  define drm_public __attribute__((visibility("default")))
+#else
+#  define drm_private
+#  define drm_public
+#endif
+
+#endif
-- 
1.9.1

[PATCH v2 libdrm 0/7] Add NVIDIA Tegra support

[Thierry Reding]

From: Thierry Reding 

Hi,

This series adds libdrm-tegra with a very lightweight API on top of the
kernel interfaces. Most of the functions provided here have been in use
in various driver efforts in different incarnations. This is an attempt
to consolidate, so I'm looking for review comments especially by Erik
to ensure it can be used by grate.

I've used these to implement basic EXA support in xf86-video-opentegra,
which I've pushed to a repository here[0]. The libdrm patches are also
available in a repository[1] for convenience.

Patch 1 adds support for symbol visibility if GCC supports it. This is
used by later patches to make only the public symbols visible in the
libdrm-tegra shared object.

Patch 2 adds support for managing a Tegra DRM object (which doesn't do
a whole lot more than wrap a file descriptor) and buffer objects.

A small test program is added in patch 3 to check that a Tegra DRM
object can be created on top of a DRM device.

Patch 4 adds functions to open a channel to an engine (gr2d or gr3d),
create and manage a job as well as compose command streams in a push
buffer and wait for a fence.

To make it easier to write further tests, patch 5 introduces some DRM
helpers to setup a screen and attach framebuffers to it. A very basic
interface is also provided for the gr2d unit, which can be used to do
a solid rectangle fill.

The helpers introduced in patch 5 are used in patch 6 to fill a sub-
region of the screen with a solid color.

Finally patch 7 clears two IOCTL argument buffers when compiled with
valgrind support to eliminate some complaints raised by valgrind when
running the newly introduced Tegra tests.

Thierry

[0]: http://cgit.freedesktop.org/~tagr/xf86-video-opentegra/
[1]: http://cgit.freedesktop.org/~tagr/drm/

Thierry Reding (7):
  configure: Support symbol visibility when available
  libdrm: Add NVIDIA Tegra support
  tegra: Add simple test for drm_tegra_open()
  tegra: Add channel, job, pushbuf and fence APIs
  tegra: Add helper library for tests
  tegra: Add gr2d-fill test
  libdrm: valgrind-clear a few more IOCTL arguments

 Makefile.am  |   6 +-
 configure.ac |  36 +-
 include/drm/Makefile.am  |   1 +
 include/drm/tegra_drm.h  | 155 ++
 libdrm.h |  34 ++
 tegra/.gitignore |   1 +
 tegra/Makefile.am|  24 
 tegra/channel.c  | 127 +
 tegra/fence.c|  71 
 tegra/job.c  | 180 ++
 tegra/libdrm_tegra.pc.in |  11 ++
 tegra/private.h  | 123 +
 tegra/pushbuf.c  | 205 ++
 tegra/tegra.c| 255 +++
 tegra/tegra.h|  99 +
 tests/Makefile.am|   4 +
 tests/modetest/modetest.c|   2 +-
 tests/tegra/.gitignore   |   2 +
 tests/tegra/Makefile.am  |  31 ++
 tests/tegra/drm-test-tegra.c | 137 +++
 tests/tegra/drm-test-tegra.h |  55 ++
 tests/tegra/drm-test.c   | 248 +
 tests/tegra/drm-test.h   |  72 
 tests/tegra/gr2d-fill.c  | 146 +
 tests/tegra/openclose.c  |  63 +++
 tests/vbltest/vbltest.c  |   2 +-
 xf86drmMode.c|   2 +
 27 files changed, 2088 insertions(+), 4 deletions(-)
 create mode 100644 include/drm/tegra_drm.h
 create mode 100644 libdrm.h
 create mode 100644 tegra/.gitignore
 create mode 100644 tegra/Makefile.am
 create mode 100644 tegra/channel.c
 create mode 100644 tegra/fence.c
 create mode 100644 tegra/job.c
 create mode 100644 tegra/libdrm_tegra.pc.in
 create mode 100644 tegra/private.h
 create mode 100644 tegra/pushbuf.c
 create mode 100644 tegra/tegra.c
 create mode 100644 tegra/tegra.h
 create mode 100644 tests/tegra/.gitignore
 create mode 100644 tests/tegra/Makefile.am
 create mode 100644 tests/tegra/drm-test-tegra.c
 create mode 100644 tests/tegra/drm-test-tegra.h
 create mode 100644 tests/tegra/drm-test.c
 create mode 100644 tests/tegra/drm-test.h
 create mode 100644 tests/tegra/gr2d-fill.c
 create mode 100644 tests/tegra/openclose.c

-- 
1.9.1

[Bug 76558] [radeon] GPU lockup: radeon: wait for empty RBBM fifo failed ! when playing sauerbraten

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

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

Fabio Pedretti  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME
Summary|GPU lockup: radeon: wait|[radeon] GPU lockup:
   |for empty RBBM fifo failed  |radeon: wait for empty RBBM
   |! when playing sauerbraten  |fifo failed ! when playing
   ||sauerbraten

--- Comment #1 from Fabio Pedretti  ---
After upgrading to Ubuntu 14.04 I cannot reproduce this issue. Note that I was
using current git of mesa/ati/libdrm with both 13.10 and 14.04. What changed
was the kernel and sauerbraten get updated. I also tried with the 13.10 kernel,
but the issue is no more reproducible.

It could be that the updated sauerbraten has a different path that doesn't
trigger this issue. Closing since I cannot reproduce it anymore anyway.

-- 
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/20140409/3721b89e/attachment.html>

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Tomasz Stanislawski]

Hi Rahul,

On 04/09/2014 11:12 AM, Rahul Sharma wrote:
> Hi Tomasz,
> 
> On 9 April 2014 14:07, Andrzej Hajda  wrote:
>> Hi Tomasz,
>>
>> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>>> Add exynos-simple-phy driver to support a single register
>>> PHY interfaces present on Exynos4 SoC.
>>>
>>> Signed-off-by: Tomasz Stanislawski 

[snip]

>>> +
>>> + regs = devm_ioremap(dev, res->start, res->end - res->start);
>>> + if (!regs) {
>>> + dev_err(dev, "failed to ioremap registers\n");
>>> + return -EFAULT;
>>> + }
>>
>> Why not devm_ioremap_resource? If not, resource_size function calculates
>> length of resource correctly.
>>
>> Anyway I like the idea of implementing multiple phys in one driver.
>> The only drawback I see is that some phys will be created even there are
>> no consumers for them. To avoid such situation you can try to use
>> lazy approach - create phy only if there is request for it,
>> exynos_phy_xlate callback should allow this.
>>
>> Regards
>> Andrzej
>>
> 
> Idea looks good. How about keeping compatible which is independent
> of SoC, something like "samsung,exynos-simple-phy" and provide Reg
> and Bit through phy provider node. This way we can avoid SoC specific
> hardcoding in phy driver and don't need to look into dt bindings for
> each new SoC.

A very nice idea BUT there is a very strong pressure from DT guys
to avoid adding any bit fields/offsets/masks in DT nodes.

Hopefully, as long as driver name starts with "exynos-" prefix
one can hide SoCs specific tricks deep inside driver code.

The idea behind this driver was not to create a generic phy for 1-bit
devices but rather to hide SoC-specific issues from client drivers
like DRM-HDMI.

> 
> We can use syscon interface to access PMU bits like USB phy.
> PMU is already registered as system controller
> 

Ok. I will try to use it in PATCHv3.

> Regards,
> Rahul Sharma.
> 

Regards,
Tomasz Stanislawski

[PATCHv2 2/3] drm: exynos: hdmi: use hdmiphy as PHY

[Tomasz Stanislawski]

Hi Andrzej,
This issue could be solved by exporting a regmap from PMU driver
or Exynos clock provider for the usage by exynos-simple-phy.
The operations on PHYs from exynos-simple-phy provider would
be chained to PMU driver and protected by a spinlock in the regmap.

Luckily, the divider is not used as far as I know.

Regards,
Tomasz Stanislawski

On 04/09/2014 12:30 PM, Andrzej Hajda wrote:
> Hi Tomasz,
> 
> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>> The HDMIPHY (physical interface) is controlled by a single
>> bit in a power controller's regiter. It was implemented
>> as clock. It was a simple but effective hack.
> 
> This power controller register has also bits to control HDMI clock
> divider ratio. I guess current drivers do not change it, but how do you
> want to implement access to it if some HDMI driver in the future will
> need to change ratio. I guess in case of clk it would be easier.
> 
> Regards
> Andrzej
> 
> 

[PATCHv2 2/3] drm: exynos: hdmi: use hdmiphy as PHY

[Andrzej Hajda]

Hi Tomasz,

On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
> The HDMIPHY (physical interface) is controlled by a single
> bit in a power controller's regiter. It was implemented
> as clock. It was a simple but effective hack.

This power controller register has also bits to control HDMI clock
divider ratio. I guess current drivers do not change it, but how do you
want to implement access to it if some HDMI driver in the future will
need to change ratio. I guess in case of clk it would be easier.

Regards
Andrzej

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #28 from Christian K?nig  ---
(In reply to comment #27)
> "the signal gets more unstable"
> 
> So it is the gpu that varies its freq. at higher divs (multipliers) and my
> set is not tolerant of signal freq. fluctuations to keep data in sync? 

Yes.

> If I understand this correctly- This is like in a micro-controller where
> deviations in baud rate (a pll generated clock) leads to serial transmission
> errors when > 5% deviation, for example. In micro-controllers: high
> multipliers * internal pll = less stable freq >> less stable baud rate.

Yes that's exactly the same problem just a completely different use case.

Depending on the details of their electrical implementation all PLLs behave
more or less like this. The trick is to know how to find the right numbers
without violating the contrains.

-- 
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/20140409/d0e70840/attachment.html>

[ 3.14.0-12041-g75ff24f ] regression: drm warning

[Jörg Otte]

Kernel 3.14.0-12041-g75ff24f from 9.4.2014 introduces the following
on the console (driver is i915):

[drm:ivb_err_int_handler] *ERROR* Pipe B FIFO underrun
[drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun
[drm:cpt_serr_int_handler] *ERROR* PCH transcoder B FIFO underrun

In syslog I find:

[ cut here ]
WARNING: CPU: 1 PID: 1 at
/data/kernel/linux/drivers/gpu/drm/drm_mm.c:211 0xb22a70fa()
no hole found for node 0x0 + 0x30
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-12041-g75ff24f #45
Hardware name: FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012
  b2967138 b262ae5d 8802160d5a58
 b20391ad 880214994000 0030 
 880214952800  b2039255 b2967190
Call Trace:
 [] ? 0xb262ae5d
 [] ? 0xb20391ad
 [] ? 0xb2039255
 [] ? 0xb22a70fa
 [] ? 0xb22d4b11
 [] ? 0xb2300f92
 [] ? 0xb232af7b
 [] ? 0xb232f675
 [] ? 0xb21fa38c
 [] ? 0xb232ec04
 [] ? 0xb2622997
 [] ? 0xb232ee62
 [] ? 0xb22a6a5b
 [] ? 0xb22a3994
 [] ? 0xb22a5a38
 [] ? 0xb221a019
 [] ? 0xb23327b8
 [] ? 0xb2332a03
 [] ? 0xb2332970
 [] ? 0xb2330c45
 [] ? 0xb2331534
 [] ? 0xb2332fce
 [] ? 0xb2aa2cc5
 [] ? 0xb2a7fe45
 [] ? 0xb2052100
 [] ? 0xb2a7ffe2
 [] ? 0xb2a7f79e
 [] ? 0xb2624d20
 [] ? 0xb2624d29
 [] ? 0xb263223c
 [] ? 0xb2624d20
---[ end trace 0d3f14b61bc31dab ]---

This does not happen in 3.14.0-11030-ga7963eb from 8.4.2014 and never
before.

Suppose merge
12024   e9f37d3 Merge branch 'drm-next' of
git://people.freedesktop.org/~airlied/linux
produces this problem.

J?rg

[Bug 46711] vmwgfx does not work in qemu/kvm

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

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

--- Comment #2 from Valentin Popa  ---
Can someone reopen this bug since the issue still reproduces.

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

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Sylwester Nawrocki]

Hi,

On 09/04/14 11:12, Rahul Sharma wrote:
> Idea looks good. How about keeping compatible which is independent
> of SoC, something like "samsung,exynos-simple-phy" and provide Reg
> and Bit through phy provider node. This way we can avoid SoC specific
> hardcoding in phy driver and don't need to look into dt bindings for
> each new SoC.

I believe it is a not recommended approach.

> We can use syscon interface to access PMU bits like USB phy.
> PMU is already registered as system controller

Yes, that sounds good. This way we could avoid overlapping memory
mapped register regions specified in 'reg' properties in the device
tree.

-- 
Thanks,
Sylwester

[pull] radeon drm-next-3.15

[Christian König]

Hi Dave,

this is the fives pull request for radeon changes. I thought number four 
would be the last one with new stuff, but it turned out that Alex has 
other things in mind.

So this request contains Alex's update to send bare addresses to 
properly reset the I2C over DP AUX bus as well as the necessary changes 
to i915 and tegra to handle this gracefully. Apart from that we also 
have a fix for HDMI audio pins and an improvement of documentation.

The following changes since commit c39b06951f1dc2e384650288676c5b7dcc0ec92c:

   DRM: armada: fix corruption while loading cursors (2014-04-08 
10:51:03 +1000)

are available in the git repository at:

   git://people.freedesktop.org/~deathsimple/linux drm-next-3.15-wip

for you to fetch changes up to 8902e6f2b832e00e10c6f9e9532f6f63feb4972f:

   drm/radeon: Improve vramlimit module param documentation (2014-04-08 
17:44:15 +0200)


Alex Deucher (5):
   drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
   drm/dp/i2c: send bare addresses to properly reset i2c connections 
(v4)
   drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
   drm/radeon/dp: switch to the common i2c over aux code
   drm/radeon: fix audio pin counts for DCE6+ (v2)

Jani Nikula (1):
   drm/i915: support address only i2c-over-aux transactions

Lauri Kasanen (1):
   drm/radeon: Improve vramlimit module param documentation

Thierry Reding (1):
   drm/tegra: dp: Support address-only I2C-over-AUX transactions

  drivers/gpu/drm/drm_dp_helper.c|  55 
+++--
  drivers/gpu/drm/i915/intel_dp.c|   7 +++--
  drivers/gpu/drm/radeon/atombios_dp.c   | 140 
--
  drivers/gpu/drm/radeon/dce6_afmt.c |  14 +++---
  drivers/gpu/drm/radeon/radeon.h|   5 +++-
  drivers/gpu/drm/radeon/radeon_connectors.c |  44 
+-
  drivers/gpu/drm/radeon/radeon_display.c|  11 
  drivers/gpu/drm/radeon/radeon_drv.c|   2 +-
  drivers/gpu/drm/radeon/radeon_i2c.c|  60 
+---
  drivers/gpu/drm/radeon/radeon_mode.h   |  12 ++--
  drivers/gpu/drm/tegra/dpaux.c  |  44 
+-
  drivers/gpu/drm/tegra/dpaux.h  |   1 +
  include/drm/drm_dp_helper.h|   4 +++
  13 files changed, 152 insertions(+), 247 deletions(-)

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #7 from forumbox33 at hotmail.com ---
I can confirm this bug. I am currently using an MSI Radeon R9 270X, and fan
speeds are indeed at around 40% with no ability to make adjustments.

-- 
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/20140409/b46163db/attachment.html>

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Andrzej Hajda]

Hi Tomasz,

On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
> Add exynos-simple-phy driver to support a single register
> PHY interfaces present on Exynos4 SoC.
> 
> Signed-off-by: Tomasz Stanislawski 
> ---
>  .../devicetree/bindings/phy/samsung-phy.txt|   24 +++
>  drivers/phy/Kconfig|5 +
>  drivers/phy/Makefile   |1 +
>  drivers/phy/exynos-simple-phy.c|  154 
> 
>  4 files changed, 184 insertions(+)
>  create mode 100644 drivers/phy/exynos-simple-phy.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index b422e38..f97c4c3 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -114,3 +114,27 @@ Example:
>   compatible = "samsung,exynos-sataphy-i2c";
>   reg = <0x38>;
>   };
> +
> +Samsung S5P/EXYNOS SoC series SIMPLE PHY
> +-
> +
> +Required properties:
> +- compatible : should be one of the listed compatibles:
> + - "samsung,exynos4210-simple-phy"
> + - "samsung,exynos4412-simple-phy"
> +- reg : offset and length of the register set;
> +- #phy-cells : from the generic phy bindings, must be 1;
> +
> +For "samsung,exynos4210-simple-phy" compatible PHYs the second cell in
> +the PHY specifier identifies the PHY and its meaning is as follows:
> +  0 - HDMI PHY,
> +  1 - DAC PHY,
> +  2 - ADC PHY,
> +  3 - PCIE PHY.
> +  4 - SATA PHY.
> +
> +For "samsung,exynos4412-simple-phy" compatible PHYs the second cell in
> +the PHY specifier identifies the PHY and its meaning is as follows:
> +  0 - HDMI PHY,
> +  1 - ADC PHY,

What about using preprocessor macros?

> +
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 3bb05f1..65ab783 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -166,4 +166,9 @@ config PHY_XGENE
>   help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>  
> +config EXYNOS_SIMPLE_PHY
> + tristate "Exynos Simple PHY driver"
> + help
> +   Support for 1-bit PHY controllers on SoCs from Exynos family.
> +
>  endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 2faf78e..88c5b60 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2)   += phy-exynos4210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS4X12_USB2)+= phy-exynos4x12-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o
>  obj-$(CONFIG_PHY_XGENE)  += phy-xgene.o
> +obj-$(CONFIG_EXYNOS_SIMPLE_PHY)  += exynos-simple-phy.o
> diff --git a/drivers/phy/exynos-simple-phy.c b/drivers/phy/exynos-simple-phy.c
> new file mode 100644
> index 000..57ad338
> --- /dev/null
> +++ b/drivers/phy/exynos-simple-phy.c
> @@ -0,0 +1,154 @@
> +/*
> + * Exynos Simple PHY driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Tomasz Stanislawski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define EXYNOS_PHY_ENABLE(1 << 0)
> +
> +static int exynos_phy_power_on(struct phy *phy)
> +{
> + void __iomem *reg = phy_get_drvdata(phy);
> + u32 val;
> +
> + val = readl(reg);
> + val |= EXYNOS_PHY_ENABLE;
> + writel(val, reg);
> +
> + return 0;
> +}
> +
> +static int exynos_phy_power_off(struct phy *phy)
> +{
> + void __iomem *reg = phy_get_drvdata(phy);
> + u32 val;
> +
> + val = readl(reg);
> + val &= ~EXYNOS_PHY_ENABLE;
> + writel(val, reg);
> +
> + return 0;
> +}
> +
> +static struct phy_ops exynos_phy_ops = {
> + .power_on   = exynos_phy_power_on,
> + .power_off  = exynos_phy_power_off,
> + .owner  = THIS_MODULE,
> +};
> +
> +static const u32 exynos4210_offsets[] = {
> + 0x0700, /* HDMI_PHY */
> + 0x070C, /* DAC_PHY */
> + 0x0718, /* ADC_PHY */
> + 0x071C, /* PCIE_PHY */
> + 0x0720, /* SATA_PHY */
> + ~0, /* end mark */
> +};
> +
> +static const u32 exynos4412_offsets[] = {
> + 0x0700, /* HDMI_PHY */
> + 0x0718, /* ADC_PHY */
> + ~0, /* end mark */
> +};

Why have you selected only these registers?
According to specs Exynos 4210 has 9 and 4412 has 7 control registers
with 'phy-enable' functionality.
I guess MIPI would require little more work as it has also reset bits,
but it will be still better than separate driver.

> +
> +static const struct of_device_id exynos_phy_of_match[] = {
> + { .compatible = "samsung,exynos4210-simple-phy",
> +   .data = exynos4210_offsets},
> + { .compatible = 

[PATCH libdrm 0/4] Minor cleanups

[Thierry Reding]

On Tue, Apr 08, 2014 at 02:38:22PM -0700, Eric Anholt wrote:
> Thierry Reding  writes:
> 
> > From: Thierry Reding 
> >
> > These four patches clean up some minor issues in libdrm. Patch 1 makes
> > gcc aware of various functions (such as drmMsg(), drm_debug_print(),
> > etc) being printf-like and patches 2 and 3 fix up a number of warnings
> > flagged as a result of that.
> >
> > Patch 4 uses drmFreeVersion() instead of drmFree() to free a drmVersion
> > structure to prevent memory leaks.
> 
> These are:
> 
> Reviewed-by: Eric Anholt 

Thanks. I don't have the necessary permissions to push this, can
somebody else help out here?

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/20140409/06581a8f/attachment-0001.sig>

[PATCH v12][ 06/12] ARM: dts: imx5*, imx6*: correct display-timings nodes.

[Lothar Waßmann]

Hi,

Shawn Guo wrote:
> On Mon, Apr 07, 2014 at 02:44:45PM +0200, Denis Carikli wrote:
> > The imx-drm driver can't use the de-active and
> > pixelclk-active display-timings properties yet.
> > 
> > Instead the data-enable and the pixel data clock
> > polarity are hardcoded in the imx-drm driver.
> > 
> > So theses properties are now set to keep
> > the same behaviour when imx-drm will start
> > using them.
> > 
> > Signed-off-by: Denis Carikli 
> > ---
> > ChangeLog v9->v10:
> > - New patch that was splitted out of:
> >   "staging imx-drm: Use de-active and pixelclk-active
> >   display-timings."
> > ---
> >  arch/arm/boot/dts/imx51-babbage.dts   |2 ++
> >  arch/arm/boot/dts/imx53-m53evk.dts|2 ++
> >  arch/arm/boot/dts/imx53-tx53-x03x.dts |2 +-
> >  arch/arm/boot/dts/imx6qdl-gw53xx.dtsi |2 ++
> >  arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |2 ++
> >  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi |2 ++
> >  arch/arm/boot/dts/imx6qdl-sabreauto.dtsi  |2 ++
> >  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi  |2 ++
> >  arch/arm/boot/dts/imx6qdl-sabresd.dtsi|2 ++
> >  9 files changed, 17 insertions(+), 1 deletion(-)
> 
> ...
> 
> > diff --git a/arch/arm/boot/dts/imx53-tx53-x03x.dts 
> > b/arch/arm/boot/dts/imx53-tx53-x03x.dts
> > index 0217dde3..4092a81 100644
> > --- a/arch/arm/boot/dts/imx53-tx53-x03x.dts
> > +++ b/arch/arm/boot/dts/imx53-tx53-x03x.dts
> > @@ -93,7 +93,7 @@
> > hsync-active = <0>;
> > vsync-active = <0>;
> > de-active = <1>;
> > -   pixelclk-active = <1>;
> > +   pixelclk-active = <0>;
> 
> @Lothar, is this change correct?
> 
No, the ET0430 display which is affected by this patch actually has an
inverted clock wrt the other displays of the family.

'pixelclk-active = <1>' is the correct setting for this display!

Thanks, Shawn for the reminder.


Lothar Wa?mann
-- 
___

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___

[Bug 41086] Screen update problems when scrolling to the right in many (any?) java apps

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

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

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |xorg-team at lists.x.org
   |.org|
 QA Contact||xorg-team at lists.x.org
Product|DRI |xorg
Version|XOrg CVS|unspecified
  Component|libdrm  |Server/General

--- Comment #17 from Michel D?nzer  ---
If the same problem happens with the nvidia driver as well as with open source
drivers, the problem must be either in generic X code used in both cases, or in
the Java code.

-- 
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/20140409/e30db3e5/attachment.html>

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

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

--- Comment #27 from Chris Rankin  ---
Thanks, I'll give it a try. Was Mesa leaking memory for *all* failed shaders,
or just failed geometry shaders?

> I tried booting up Diablo III a few days back to see the new geometry shaders
> in action on my 4890...

AFAIK, the 4890 needs a 3.14+ kernel to get geometry shader support.

-- 
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/20140409/87ae3888/attachment.html>

[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors

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

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

Christian K?nig  changed:

   What|Removed |Added

 CC||nfxjfg at gmail.com

--- Comment #5 from Christian K?nig  ---
*** Bug 77208 has been marked as a duplicate of this bug. ***

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

[Intel-gfx] [PATCH] drm/mm: Don't WARN if drm_mm_reserve_node

[Chris Wilson]

On Tue, Apr 08, 2014 at 10:21:44AM -0700, Ben Widawsky wrote:
> I am not convinced this is the correct solution. At least the way we
> used this interface, it isn't meant to ever fail.  I also didn't look
> into exactly why we depend an ENOSPC return. That sounds fragile to me,
> especially for a public interface.

Eh? This interface is explicitly used to check that the requested range
is available.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #27 from Tom Yan  ---
(In reply to Alex Deucher from comment #25)
> (In reply to Tom Yan from comment #23)
> > Btw, is it something not implemented yet or a bug, that it won't do the
> > modesetting later if no device plugged before boot? Why does it have to go
> > 1024x768? I mean, why does it require a device to initialize "dynamic"
> > modesetting?
> 
> It's a bug that seems to be specific to your board.  The vast majority of
> cards work fine (i.e., you can dynamically change monitors on the fly).

I can dynamically change monitors, just that the prequisite is something has to
be connected (and turned on unless it's DVI) before boot.

I have two different cards sharing the same problem, though they are both from
Sapphire. I'll see if I can test one from others.

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

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #26 from Tom Yan  ---
(In reply to Alex Deucher from comment #24)
> It works for the vast majority of users and removing it would break unplug
> and replug of DP displays.  Without that code you would have to manually
> disable and re-enable the display using xrandr every time you connect or
> disconnect a DP display.  It would also break disconnect and reconnect of dp
> displays for the console.


In my case removing it breaks nothing. So there's a chance my board has a
non-standard dp?

> In your case we need to find out why it's not working properly for you.  You
> mentioned that it works properly in the console but not in X.  That sounds
> like maybe your desktop environment is trying to do something special which
> causes the problem.  Does it work properly with a bare X server?  E.g., just
> run Xorg without a desktop environment.

Indeed with or without the code it works the same in console. I am with GNOME
and I may try a wm with startx later, but I doubt it has anything to do with
the problem. Some have same experiences test it already:
https://bugs.freedesktop.org/show_bug.cgi?id=46711

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

[Bug 74868] r600g: Diablo III Crashes After a few minutes

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

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

--- Comment #20 from Michel D?nzer  ---
(In reply to comment #17)
> The error spamming to stdout is still occurring, so I'm not sure whether that
> should be another bug report/left open in this one with a new name or 
> anything.

Please file separate bugs for the shader compile failures.

-- 
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/20140409/a4fc5253/attachment.html>

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

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

--- Comment #26 from Michel D?nzer  ---
Does the patch from bug 74868 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/20140409/3c85421d/attachment.html>

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #25 from Alex Deucher  ---
(In reply to Tom Yan from comment #23)
> Btw, is it something not implemented yet or a bug, that it won't do the
> modesetting later if no device plugged before boot? Why does it have to go
> 1024x768? I mean, why does it require a device to initialize "dynamic"
> modesetting?

It's a bug that seems to be specific to your board.  The vast majority of cards
work fine (i.e., you can dynamically change monitors on the fly).

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

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #24 from Alex Deucher  ---
(In reply to Tom Yan from comment #22)
> Do you have any case that the code would do something positive? Or
> ultimately, would you consider removing the code upstream?

It works for the vast majority of users and removing it would break unplug and
replug of DP displays.  Without that code you would have to manually disable
and re-enable the display using xrandr every time you connect or disconnect a
DP display.  It would also break disconnect and reconnect of dp displays for
the console.

In your case we need to find out why it's not working properly for you.  You
mentioned that it works properly in the console but not in X.  That sounds like
maybe your desktop environment is trying to do something special which causes
the problem.  Does it work properly with a bare X server?  E.g., just run Xorg
without a desktop environment.

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

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #23 from Tom Yan  ---
Btw, is it something not implemented yet or a bug, that it won't do the
modesetting later if no device plugged before boot? Why does it have to go
1024x768? I mean, why does it require a device to initialize "dynamic"
modesetting?

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

[Bug 42960] Display does not work when resuming from suspend

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

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

--- Comment #31 from SpacemanSpiff  ---
(In reply to comment #29)
> Unfortunately, the "fix" is just a workaround that just calls the legacy
> vbios post at resume time.  This is normally disabled for KMS because it
> doesn't always work on all systems and also doesn't work with UEFI.

Any possibility of a proper fix? Is this a bios bug? 
Workaround works on my machine but many people would probably work without
using sleep as it doesnt work oob.
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/20140409/8283d720/attachment-0001.html>

[Bug 71461] monitor doesn't get detected after boot or disconnection

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

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

--- Comment #22 from Tom Yan  ---
Do you have any case that the code would do something positive? Or ultimately,
would you consider removing the code upstream?

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

[Bug 72701] Screen freeze when using radeon driver

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #131741|0   |1
is obsolete||

--- Comment #14 from Alex Deucher  ---
Created attachment 131781
  --> https://bugzilla.kernel.org/attachment.cgi?id=131781=edit
possible fix

fix a stupid typo.

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

[Bug 75127] runpm hang with PowerXpress/hybrid laptop

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #97099|0   |1
is obsolete||

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

fix a stupid typo.

-- 
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/20140409/0c4ee8fd/attachment.html>

[Bug 75127] runpm hang with PowerXpress/hybrid laptop

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

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

--- Comment #28 from Sandeep  ---
No, unfortunately GPU reset still occurs on startup, suspend, resume and
shutdown.

The laptop did suspend faster than earlier cases though, maybe the GPU was able
to break out of the reset cycle earlier.

-- 
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/20140409/ed7c5e1e/attachment.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #27 from Garrett  ---
(In reply to comment #24)
> (In reply to comment #22)
> > I am trying to understand the plls.
> 
> Well how deep are you interested in getting into this? PLLs can be
> complicated, but are also one of the very basic building blocks of
> electronics.
> 

No need to dig too deep.  I work with embedded firmware.  PLL clocks/timing are
fine (I understand basics).  In reference to video this is new stuff.  I
sincerely appreciate your time educating me.

> > I read the org. bug report 76564.  I
> > assumed increasing the max would allow higher pll vals.  But it does go down
> > with some.  Does that make sense?  
> 
> More or less yes. See your numbers for example, without the limit patch you
> had the params like this:
> 
> 148340 - 14834, pll dividers - fb: 741.7 ref: 50, post 10
> 
> This means with a feedback divider of 741.7, a referenz divider of 50 and a
> post divider of 10 you have an exact match for the frequency.
> 
> There is just the little problem that as the divider numbers get higher the
> signal gets more unstable. So in reality you don't get 148.340 MHz, but
> instead something that fluctuates between 148.339 MHz and 148.341 MHz (for
> example).

"the signal gets more unstable"

So it is the gpu that varies its freq. at higher divs (multipliers) and my set
is not tolerant of signal freq. fluctuations to keep data in sync? 

If I understand this correctly- This is like in a micro-controller where
deviations in baud rate (a pll generated clock) leads to serial transmission
errors when > 5% deviation, for example. In micro-controllers: high multipliers
* internal pll = less stable freq >> less stable baud rate.

> 
> The overall match for the average frequency is still better than with lower
> numbers, but your TV/Monitor can't deal with such high fluctuations in it.
> 
> > Your patch does wonders for this A4-3400.  I am trying to understand it
> > better.
> > 
> > Here your max is 100.  ref: 10, post 10  >>>> 10 * 10 = 100 max.
> 
> Yes correct.

Thanks for explaining this so clearly.  
Garrett

-- 
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/20140409/7719241c/attachment.html>

[Bug 72701] Screen freeze when using radeon driver

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #131601|0   |1
is obsolete||

--- Comment #13 from Alex Deucher  ---
Created attachment 131741
  --> https://bugzilla.kernel.org/attachment.cgi?id=131741=edit
possible fix

updated patch.

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

[Bug 75127] runpm hang with PowerXpress/hybrid laptop

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #97007|0   |1
is obsolete||

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

Updated patch.

-- 
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/20140409/4413163d/attachment-0001.html>

[Bug 75127] runpm hang with PowerXpress/hybrid laptop

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

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

--- Comment #26 from Sandeep  ---
Unfortunately, the problem still occurs even with the new patches. I applied
them against the latest source code of the kernel from git, after this commit:
18a1a7a1d862ae0794a0179473d08a414dd49234

I still get GPU reset messages even on startup.

-- 
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/20140409/9f906829/attachment-0001.html>

[Bug 72701] Screen freeze when using radeon driver

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

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

--- Comment #12 from klod  ---
I'm sorry, I'm very busy these days. I will try that when I have time

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