[PATCH 2/2] libdrm: add prime fd->handle and handle->fd interfaces
These are just basic ioctl wrappers around the prime ioctls,
along with the capability reporting.
Signed-off-by: Dave Airlie
---
include/drm/drm.h | 10 +++---
xf86drm.c | 31 +++
xf86drm.h |3 +++
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 42133bc..a847689 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -685,6 +685,9 @@ struct drm_prime_handle {
#define DRM_IOCTL_UNLOCK DRM_IOW( 0x2b, struct drm_lock)
#define DRM_IOCTL_FINISH DRM_IOW( 0x2c, struct drm_lock)
+#define DRM_IOCTL_PRIME_HANDLE_TO_FDDRM_IOWR(0x2d, struct drm_prime_handle)
+#define DRM_IOCTL_PRIME_FD_TO_HANDLEDRM_IOWR(0x2e, struct drm_prime_handle)
+
#define DRM_IOCTL_AGP_ACQUIRE DRM_IO( 0x30)
#define DRM_IOCTL_AGP_RELEASE DRM_IO( 0x31)
#define DRM_IOCTL_AGP_ENABLE DRM_IOW( 0x32, struct drm_agp_mode)
@@ -697,9 +700,6 @@ struct drm_prime_handle {
#define DRM_IOCTL_SG_ALLOC DRM_IOWR(0x38, struct
drm_scatter_gather)
#define DRM_IOCTL_SG_FREE DRM_IOW( 0x39, struct
drm_scatter_gather)
-#define DRM_IOCTL_PRIME_HANDLE_TO_FDDRM_IOWR(0x2d, struct drm_prime_handle)
-#define DRM_IOCTL_PRIME_FD_TO_HANDLEDRM_IOWR(0x2e, struct drm_prime_handle)
-
#define DRM_IOCTL_WAIT_VBLANK DRM_IOWR(0x3a, union drm_wait_vblank)
#define DRM_IOCTL_UPDATE_DRAW DRM_IOW(0x3f, struct drm_update_draw)
@@ -778,6 +778,10 @@ struct drm_event_vblank {
#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
+#define DRM_CAP_PRIME 0x5
+
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2
/* typedef area */
typedef struct drm_clip_rect drm_clip_rect_t;
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..2a74c80 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2542,3 +2542,34 @@ char *drmGetDeviceNameFromFd(int fd)
return strdup(name);
}
+
+int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int *prime_fd)
+{
+ struct drm_prime_handle args;
+ int ret;
+
+ args.handle = handle;
+ args.flags = flags;
+ ret = drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, );
+ if (ret)
+ return ret;
+
+ *prime_fd = args.fd;
+ return 0;
+}
+
+int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t *handle)
+{
+ struct drm_prime_handle args;
+ int ret;
+
+ args.fd = prime_fd;
+ args.flags = 0;
+ ret = drmIoctl(fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, );
+ if (ret)
+ return ret;
+
+ *handle = args.handle;
+ return 0;
+}
+
diff --git a/xf86drm.h b/xf86drm.h
index 76eb94e..5ecb284 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -727,6 +727,9 @@ extern int drmHandleEvent(int fd, drmEventContextPtr evctx);
extern char *drmGetDeviceNameFromFd(int fd);
+extern int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int
*prime_fd);
+extern int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t *handle);
+
#if defined(__cplusplus) || defined(c_plusplus)
}
#endif
--
1.7.10.4
[PATCH 1/2] libdrm: add missing caps from kernel to drm.h
This just moves over some missing caps from the kernel.
Signed-off-by: Dave Airlie
---
include/drm/drm.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 5e6cd29..42133bc 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -776,6 +776,8 @@ struct drm_event_vblank {
#define DRM_CAP_DUMB_BUFFER 0x1
#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
/* typedef area */
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.7.10.4
[Bug 51652] [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=51652 --- Comment #1 from okias 2012-07-14 09:36:38 PDT --- 1a) I tested switched (so Asus on DVI and LG on VGA - switched) and it booted 1b) secondary I tested only Asus on DVI and it had same problem... only in this line numbers (13 => 12 etc.) is little bit changing: radeon :00:01.0: GPU lockup (waiting for 0x0016 last fence id 0x0013) 1c) tested only LG on VGA and it failed. (same errors) 2) of fly was tested: VGA only, DVI only, both vga+dvi, both dvi+vga, seems ok sometimes it start rebooting, but it takes a some time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
dma-buf/fbdev: one-to-many support
Hi I am currently working on fblog [1] (a replacement for fbcon without VT dependencies) but this questions does also apply to other fbdev users. Is there a way to share framebuffers between fbdev devices? I was thinking especially of USB devices like DisplayLink. If they share the same screen dimensions it would increase performance a lot if I could display a single buffer on all the devices instead of copying it into each framebuffer. I was told to have a look at the dma-buf framework to implement this. However, looking at the fbdev dma-buf support I think that this isn't currently possible. Each fbdev device takes the exporter-role and provides a single dma-buf object. However, if I wanted to share the buffers, I would need to be the exporter. Or there needs to be a way for the fbdev devices to import a dma-buf from other fbdev devices. I also took a short look at DRM prime support and noticed that it is capable of importing buffers (or at least it looks like it is). Therefore, I was wondering whether it does make sense to add an "import dma-buf" callback to fbdev devices and if the fbdev driver supports this, I can simply draw to a single dma-buf from one fbdev device and push it to all other fbdev devices that share the same dimensions. It would also be nice to allow multiple buffer-owners or a way to transfer ownership. That is, if the owner/exporter of the dma-buf vanishes, I would pass it to another fbdev device which would pick it up so I don't have to create a new one. I think this is only interesting for DisplayLink-devices as they are currently the only way to get a bunch of displays connected to a single machine. Anyway, if you think that this isn't worth it, I will probably drop this idea. Regards David [1] fblog kernel driver: http://lwn.net/Articles/505965/
[PATCH] nouveau: Add irq waiting as alternative to busywait
Hey, Op 14-07-12 00:56, Maarten Maathuis schreef: > On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst > wrote: >> A way to trigger an irq will be needed for optimus support since >> cpu-waiting isn't always viable there. This could also be nice for >> power saving on since cpu would no longer have to spin, and >> performance might improve slightly on cpu-limited workloads. >> >> Some way to quantify these effects would be nice, even if the >> end result would be 'no performance regression'. An earlier >> version always emitted an interrupt, resulting in glxgears going >> from 8k fps to 7k. However this is no longer the case, as I'm >> using the kernel submission channel for generating irqs as >> needed now. >> >> On nv84 I'm using NOTIFY_INTR, but that might have been >> removed on fermi, so instead I'm using invalid command >> 0x0058 now as a way to signal completion. > Out of curiosity, isn't this like a handcoded version of software > methods? If so, why handcoded? Or are software methods not supported > on NVC0? > I don't think there is a software engine, and if you look at the code only the kernel hardware channel will be allowed to raise a wake-up interrupt. On normal channels you'll get a invalid command in dmesg. On nv84 the interrupt will be eaten unless it originated from the kernel hw channel in which case things will be woken up, since it's a valid fifo command there. Either nvc0 and later dropped the support or I wasn't able to activate it during testing. ~Maarten
general protection fault on ttm_init()
Can you try this patch on top of the previous one? I think it should fix it. Dave. -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-set-drm_class-to-NULL-after-removing-it.patch Type: application/octet-stream Size: 818 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120714/75e20e3a/attachment.obj>
general protection fault on ttm_init()
Hi Dave, On Sat, Jul 14, 2012 at 01:33:45PM +1000, Dave Airlie wrote: > Can you try this patch on top of the previous one? > > I think it should fix it. You are right, it works! Thank you very much! :-) Thanks, Fengguang
[Bug 52081] New: X hangs on AMD A10-4600M (Radeon HD 7660G) running 3.4 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=52081 Bug #: 52081 Summary: X hangs on AMD A10-4600M (Radeon HD 7660G) running 3.4 kernel Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: gunkilatur at gmail.com Created attachment 64202 --> https://bugs.freedesktop.org/attachment.cgi?id=64202 files for troubleshooting problem X hangs on AMD A10-4600M (Radeon HD 7660G) running 3.4 kernel This is a brand new HP Pavilion dv6 laptop. Running prebuilt kernel from debian experimental, xorg drivers from debian testing/unstable (they're the same in this case) Included in attachment: dmesg output, Xorg log, ls of loaded modules, and ps of X when in "hung" (interruptible sleep) state -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/2] libdrm: add missing caps from kernel to drm.h
On Sat, Jul 14, 2012 at 5:52 AM, Dave Airlie wrote:
> This just moves over some missing caps from the kernel.
>
> Signed-off-by: Dave Airlie
For both patches:
Reviewed-by: Alex Deucher
> ---
> include/drm/drm.h |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index 5e6cd29..42133bc 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -776,6 +776,8 @@ struct drm_event_vblank {
>
> #define DRM_CAP_DUMB_BUFFER 0x1
> #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
> +#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
> +#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
>
> /* typedef area */
> typedef struct drm_clip_rect drm_clip_rect_t;
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nouveau: Add irq waiting as alternative to busywait
On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst
wrote:
> A way to trigger an irq will be needed for optimus support since
> cpu-waiting isn't always viable there. This could also be nice for
> power saving on since cpu would no longer have to spin, and
> performance might improve slightly on cpu-limited workloads.
>
> Some way to quantify these effects would be nice, even if the
> end result would be 'no performance regression'. An earlier
> version always emitted an interrupt, resulting in glxgears going
> from 8k fps to 7k. However this is no longer the case, as I'm
> using the kernel submission channel for generating irqs as
> needed now.
>
> On nv84 I'm using NOTIFY_INTR, but that might have been
> removed on fermi, so instead I'm using invalid command
> 0x0058 now as a way to signal completion.
Out of curiosity, isn't this like a handcoded version of software
methods? If so, why handcoded? Or are software methods not supported
on NVC0?
>
> Signed-off-by: Maarten Lankhorst
>
> ---
> drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
> drivers/gpu/drm/nouveau/nouveau_fence.c | 49
> ---
> drivers/gpu/drm/nouveau/nouveau_fifo.h |1 +
> drivers/gpu/drm/nouveau/nouveau_state.c |1 +
> drivers/gpu/drm/nouveau/nv04_fifo.c | 25
> drivers/gpu/drm/nouveau/nv84_fence.c| 18 +--
> drivers/gpu/drm/nouveau/nvc0_fence.c| 12 ++--
> drivers/gpu/drm/nouveau/nvc0_fifo.c |3 +-
> drivers/gpu/drm/nouveau/nve0_fifo.c | 15 +++--
> 9 files changed, 110 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index f97a1a7..d9d274d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -707,6 +707,7 @@ struct drm_nouveau_private {
> struct drm_mm heap;
> struct nouveau_bo *bo;
> } fence;
> + wait_queue_head_t fence_wq;
>
> struct {
> spinlock_t lock;
> @@ -1656,6 +1657,7 @@ nv44_graph_class(struct drm_device *dev)
> #define NV84_SUBCHAN_WRCACHE_FLUSH
> 0x0024
> #define NV10_SUBCHAN_REF_CNT
> 0x0050
> #define NVSW_SUBCHAN_PAGE_FLIP
> 0x0054
> +#define NVSW_SUBCHAN_FENCE_WAKE
> 0x0058
> #define NV11_SUBCHAN_DMA_SEMAPHORE
> 0x0060
> #define NV11_SUBCHAN_SEMAPHORE_OFFSET
> 0x0064
> #define NV11_SUBCHAN_SEMAPHORE_ACQUIRE
> 0x0068
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
> b/drivers/gpu/drm/nouveau/nouveau_fence.c
> index 3c18049..3ba8dee 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> @@ -68,7 +68,7 @@ nouveau_fence_update(struct nouveau_channel *chan)
>
> spin_lock(>lock);
> list_for_each_entry_safe(fence, fnext, >pending, head) {
> - if (priv->read(chan) < fence->sequence)
> + if (priv->read(chan) - fence->sequence >= 0x8000U)
> break;
>
> if (fence->work)
> @@ -111,11 +111,9 @@ nouveau_fence_done(struct nouveau_fence *fence)
> return !fence->channel;
> }
>
> -int
> -nouveau_fence_wait(struct nouveau_fence *fence, bool lazy, bool intr)
> +static int nouveau_fence_wait_busy(struct nouveau_fence *fence, bool lazy,
> bool intr)
> {
> unsigned long sleep_time = NSEC_PER_MSEC / 1000;
> - ktime_t t;
> int ret = 0;
>
> while (!nouveau_fence_done(fence)) {
> @@ -127,7 +125,7 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool
> lazy, bool intr)
> __set_current_state(intr ? TASK_INTERRUPTIBLE :
>TASK_UNINTERRUPTIBLE);
> if (lazy) {
> - t = ktime_set(0, sleep_time);
> + ktime_t t = ktime_set(0, sleep_time);
> schedule_hrtimeout(, HRTIMER_MODE_REL);
> sleep_time *= 2;
> if (sleep_time > NSEC_PER_MSEC)
> @@ -144,6 +142,47 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool
> lazy, bool intr)
> return ret;
> }
>
> +static int nouveau_fence_wait_event(struct nouveau_fence *fence, bool intr)
> +{
> + struct drm_nouveau_private *dev_priv =
> fence->channel->dev->dev_private;
> + unsigned long timeout = fence->timeout;
> + int ret = 0;
> + struct nouveau_channel *chan = dev_priv->channel;
> + struct nouveau_channel *prev = fence->channel;
> + struct nouveau_fence_priv *priv = nv_engine(chan->dev,
> NVOBJ_ENGINE_FENCE);
> +
> + if (nouveau_fence_done(fence))
> + return 0;
> +
> + if (!timeout)
>
[RFC] dma-fence: dma-buf synchronization (v2)
Hey, Op 13-07-12 20:52, Rob Clark schreef: > On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey wrote: >> My other thought is around atomicity. Could this be extended to >> (safely) allow for hardware devices which might want to access >> multiple buffers simultaneously? I think it probably can with >> some tweaks to the interface? An atomic function which does >> something like "give me all the fences for all these buffers >> and add this fence to each instead/as-well-as"? > fwiw, what I'm leaning towards right now is combining dma-fence w/ > Maarten's idea of dma-buf-mgr (not sure if you saw his patches?). And > let dmabufmgr handle the multi-buffer reservation stuff. And possibly > the read vs write access, although this I'm not 100% sure on... the > other option being the concept of read vs write (or > exclusive/non-exclusive) fences. Agreed, dmabufmgr is meant for reserving multiple buffers without deadlocks. The underlying mechanism for synchronization can be dma-fences, it wouldn't really change dmabufmgr much. > In the current state, the fence is quite simple, and doesn't care > *what* it is fencing, which seems advantageous when you get into > trying to deal with combinations of devices sharing buffers, some of > whom can do hw sync, and some who can't. So having a bit of > partitioning from the code dealing w/ sequencing who can access the > buffers when and for what purpose seems like it might not be a bad > idea. Although I'm still working through the different alternatives. > Yeah, I managed to get nouveau hooked up with generating irqs on completion today using an invalid command. It's also no longer a performance regression, so software syncing is no longer a problem for nouveau. i915 already generates irqs and r600 presumably too. Monday I'll take a better look at your patch, end of day now. :) ~Maarten
[PATCH] nouveau: Add irq waiting as alternative to busywait
A way to trigger an irq will be needed for optimus support since
cpu-waiting isn't always viable there. This could also be nice for
power saving on since cpu would no longer have to spin, and
performance might improve slightly on cpu-limited workloads.
Some way to quantify these effects would be nice, even if the
end result would be 'no performance regression'. An earlier
version always emitted an interrupt, resulting in glxgears going
from 8k fps to 7k. However this is no longer the case, as I'm
using the kernel submission channel for generating irqs as
needed now.
On nv84 I'm using NOTIFY_INTR, but that might have been
removed on fermi, so instead I'm using invalid command
0x0058 now as a way to signal completion.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 49 ---
drivers/gpu/drm/nouveau/nouveau_fifo.h |1 +
drivers/gpu/drm/nouveau/nouveau_state.c |1 +
drivers/gpu/drm/nouveau/nv04_fifo.c | 25
drivers/gpu/drm/nouveau/nv84_fence.c| 18 +--
drivers/gpu/drm/nouveau/nvc0_fence.c| 12 ++--
drivers/gpu/drm/nouveau/nvc0_fifo.c |3 +-
drivers/gpu/drm/nouveau/nve0_fifo.c | 15 +++--
9 files changed, 110 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index f97a1a7..d9d274d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -707,6 +707,7 @@ struct drm_nouveau_private {
struct drm_mm heap;
struct nouveau_bo *bo;
} fence;
+ wait_queue_head_t fence_wq;
struct {
spinlock_t lock;
@@ -1656,6 +1657,7 @@ nv44_graph_class(struct drm_device *dev)
#define NV84_SUBCHAN_WRCACHE_FLUSH 0x0024
#define NV10_SUBCHAN_REF_CNT 0x0050
#define NVSW_SUBCHAN_PAGE_FLIP 0x0054
+#define NVSW_SUBCHAN_FENCE_WAKE 0x0058
#define NV11_SUBCHAN_DMA_SEMAPHORE 0x0060
#define NV11_SUBCHAN_SEMAPHORE_OFFSET0x0064
#define NV11_SUBCHAN_SEMAPHORE_ACQUIRE 0x0068
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 3c18049..3ba8dee 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -68,7 +68,7 @@ nouveau_fence_update(struct nouveau_channel *chan)
spin_lock(>lock);
list_for_each_entry_safe(fence, fnext, >pending, head) {
- if (priv->read(chan) < fence->sequence)
+ if (priv->read(chan) - fence->sequence >= 0x8000U)
break;
if (fence->work)
@@ -111,11 +111,9 @@ nouveau_fence_done(struct nouveau_fence *fence)
return !fence->channel;
}
-int
-nouveau_fence_wait(struct nouveau_fence *fence, bool lazy, bool intr)
+static int nouveau_fence_wait_busy(struct nouveau_fence *fence, bool lazy,
bool intr)
{
unsigned long sleep_time = NSEC_PER_MSEC / 1000;
- ktime_t t;
int ret = 0;
while (!nouveau_fence_done(fence)) {
@@ -127,7 +125,7 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool lazy,
bool intr)
__set_current_state(intr ? TASK_INTERRUPTIBLE :
TASK_UNINTERRUPTIBLE);
if (lazy) {
- t = ktime_set(0, sleep_time);
+ ktime_t t = ktime_set(0, sleep_time);
schedule_hrtimeout(, HRTIMER_MODE_REL);
sleep_time *= 2;
if (sleep_time > NSEC_PER_MSEC)
@@ -144,6 +142,47 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool lazy,
bool intr)
return ret;
}
+static int nouveau_fence_wait_event(struct nouveau_fence *fence, bool intr)
+{
+ struct drm_nouveau_private *dev_priv = fence->channel->dev->dev_private;
+ unsigned long timeout = fence->timeout;
+ int ret = 0;
+ struct nouveau_channel *chan = dev_priv->channel;
+ struct nouveau_channel *prev = fence->channel;
+ struct nouveau_fence_priv *priv = nv_engine(chan->dev,
NVOBJ_ENGINE_FENCE);
+
+ if (nouveau_fence_done(fence))
+ return 0;
+
+ if (!timeout)
+ timeout = jiffies + 3 * DRM_HZ;
+
+ if (prev != chan)
+ ret = priv->sync(fence, prev, chan);
+ if (ret)
+ goto busy;
+
+ if (intr)
+ ret = wait_event_interruptible_timeout(dev_priv->fence_wq,
nouveau_fence_done(fence), timeout);
+ else
+ ret = wait_event_timeout(dev_priv->fence_wq,
nouveau_fence_done(fence), timeout);
+
+ return ret;
[Bug 51652] [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=51652 --- Comment #1 from okias d.ok...@gmail.com 2012-07-14 09:36:38 PDT --- 1a) I tested switched (so Asus on DVI and LG on VGA - switched) and it booted 1b) secondary I tested only Asus on DVI and it had same problem... only in this line numbers (13 = 12 etc.) is little bit changing: radeon :00:01.0: GPU lockup (waiting for 0x0016 last fence id 0x0013) 1c) tested only LG on VGA and it failed. (same errors) 2) of fly was tested: VGA only, DVI only, both vga+dvi, both dvi+vga, seems ok sometimes it start rebooting, but it takes a some time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] libdrm: add missing caps from kernel to drm.h
This just moves over some missing caps from the kernel.
Signed-off-by: Dave Airlie airl...@redhat.com
---
include/drm/drm.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 5e6cd29..42133bc 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -776,6 +776,8 @@ struct drm_event_vblank {
#define DRM_CAP_DUMB_BUFFER 0x1
#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
/* typedef area */
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] libdrm: add prime fd-handle and handle-fd interfaces
These are just basic ioctl wrappers around the prime ioctls,
along with the capability reporting.
Signed-off-by: Dave Airlie airl...@redhat.com
---
include/drm/drm.h | 10 +++---
xf86drm.c | 31 +++
xf86drm.h |3 +++
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 42133bc..a847689 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -685,6 +685,9 @@ struct drm_prime_handle {
#define DRM_IOCTL_UNLOCK DRM_IOW( 0x2b, struct drm_lock)
#define DRM_IOCTL_FINISH DRM_IOW( 0x2c, struct drm_lock)
+#define DRM_IOCTL_PRIME_HANDLE_TO_FDDRM_IOWR(0x2d, struct drm_prime_handle)
+#define DRM_IOCTL_PRIME_FD_TO_HANDLEDRM_IOWR(0x2e, struct drm_prime_handle)
+
#define DRM_IOCTL_AGP_ACQUIRE DRM_IO( 0x30)
#define DRM_IOCTL_AGP_RELEASE DRM_IO( 0x31)
#define DRM_IOCTL_AGP_ENABLE DRM_IOW( 0x32, struct drm_agp_mode)
@@ -697,9 +700,6 @@ struct drm_prime_handle {
#define DRM_IOCTL_SG_ALLOC DRM_IOWR(0x38, struct
drm_scatter_gather)
#define DRM_IOCTL_SG_FREE DRM_IOW( 0x39, struct
drm_scatter_gather)
-#define DRM_IOCTL_PRIME_HANDLE_TO_FDDRM_IOWR(0x2d, struct drm_prime_handle)
-#define DRM_IOCTL_PRIME_FD_TO_HANDLEDRM_IOWR(0x2e, struct drm_prime_handle)
-
#define DRM_IOCTL_WAIT_VBLANK DRM_IOWR(0x3a, union drm_wait_vblank)
#define DRM_IOCTL_UPDATE_DRAW DRM_IOW(0x3f, struct drm_update_draw)
@@ -778,6 +778,10 @@ struct drm_event_vblank {
#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
+#define DRM_CAP_PRIME 0x5
+
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2
/* typedef area */
typedef struct drm_clip_rect drm_clip_rect_t;
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..2a74c80 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2542,3 +2542,34 @@ char *drmGetDeviceNameFromFd(int fd)
return strdup(name);
}
+
+int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int *prime_fd)
+{
+ struct drm_prime_handle args;
+ int ret;
+
+ args.handle = handle;
+ args.flags = flags;
+ ret = drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, args);
+ if (ret)
+ return ret;
+
+ *prime_fd = args.fd;
+ return 0;
+}
+
+int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t *handle)
+{
+ struct drm_prime_handle args;
+ int ret;
+
+ args.fd = prime_fd;
+ args.flags = 0;
+ ret = drmIoctl(fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, args);
+ if (ret)
+ return ret;
+
+ *handle = args.handle;
+ return 0;
+}
+
diff --git a/xf86drm.h b/xf86drm.h
index 76eb94e..5ecb284 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -727,6 +727,9 @@ extern int drmHandleEvent(int fd, drmEventContextPtr evctx);
extern char *drmGetDeviceNameFromFd(int fd);
+extern int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int
*prime_fd);
+extern int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t *handle);
+
#if defined(__cplusplus) || defined(c_plusplus)
}
#endif
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52081] New: X hangs on AMD A10-4600M (Radeon HD 7660G) running 3.4 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=52081 Bug #: 52081 Summary: X hangs on AMD A10-4600M (Radeon HD 7660G) running 3.4 kernel Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: gunkila...@gmail.com Created attachment 64202 -- https://bugs.freedesktop.org/attachment.cgi?id=64202 files for troubleshooting problem X hangs on AMD A10-4600M (Radeon HD 7660G) running 3.4 kernel This is a brand new HP Pavilion dv6 laptop. Running prebuilt kernel from debian experimental, xorg drivers from debian testing/unstable (they're the same in this case) Included in attachment: dmesg output, Xorg log, ls of loaded modules, and ps of X when in hung (interruptible sleep) state -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] libdrm: add missing caps from kernel to drm.h
On Sat, Jul 14, 2012 at 5:52 AM, Dave Airlie airl...@gmail.com wrote:
This just moves over some missing caps from the kernel.
Signed-off-by: Dave Airlie airl...@redhat.com
For both patches:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
include/drm/drm.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 5e6cd29..42133bc 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -776,6 +776,8 @@ struct drm_event_vblank {
#define DRM_CAP_DUMB_BUFFER 0x1
#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
/* typedef area */
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau: Add irq waiting as alternative to busywait
Hey, Op 14-07-12 00:56, Maarten Maathuis schreef: On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: A way to trigger an irq will be needed for optimus support since cpu-waiting isn't always viable there. This could also be nice for power saving on since cpu would no longer have to spin, and performance might improve slightly on cpu-limited workloads. Some way to quantify these effects would be nice, even if the end result would be 'no performance regression'. An earlier version always emitted an interrupt, resulting in glxgears going from 8k fps to 7k. However this is no longer the case, as I'm using the kernel submission channel for generating irqs as needed now. On nv84 I'm using NOTIFY_INTR, but that might have been removed on fermi, so instead I'm using invalid command 0x0058 now as a way to signal completion. Out of curiosity, isn't this like a handcoded version of software methods? If so, why handcoded? Or are software methods not supported on NVC0? I don't think there is a software engine, and if you look at the code only the kernel hardware channel will be allowed to raise a wake-up interrupt. On normal channels you'll get a invalid command in dmesg. On nv84 the interrupt will be eaten unless it originated from the kernel hw channel in which case things will be woken up, since it's a valid fifo command there. Either nvc0 and later dropped the support or I wasn't able to activate it during testing. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dma-buf/fbdev: one-to-many support
Hi I am currently working on fblog [1] (a replacement for fbcon without VT dependencies) but this questions does also apply to other fbdev users. Is there a way to share framebuffers between fbdev devices? I was thinking especially of USB devices like DisplayLink. If they share the same screen dimensions it would increase performance a lot if I could display a single buffer on all the devices instead of copying it into each framebuffer. I was told to have a look at the dma-buf framework to implement this. However, looking at the fbdev dma-buf support I think that this isn't currently possible. Each fbdev device takes the exporter-role and provides a single dma-buf object. However, if I wanted to share the buffers, I would need to be the exporter. Or there needs to be a way for the fbdev devices to import a dma-buf from other fbdev devices. I also took a short look at DRM prime support and noticed that it is capable of importing buffers (or at least it looks like it is). Therefore, I was wondering whether it does make sense to add an import dma-buf callback to fbdev devices and if the fbdev driver supports this, I can simply draw to a single dma-buf from one fbdev device and push it to all other fbdev devices that share the same dimensions. It would also be nice to allow multiple buffer-owners or a way to transfer ownership. That is, if the owner/exporter of the dma-buf vanishes, I would pass it to another fbdev device which would pick it up so I don't have to create a new one. I think this is only interesting for DisplayLink-devices as they are currently the only way to get a bunch of displays connected to a single machine. Anyway, if you think that this isn't worth it, I will probably drop this idea. Regards David [1] fblog kernel driver: http://lwn.net/Articles/505965/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 12097] NULL pointer dereference in viaXMesaWindowMoved
https://bugs.freedesktop.org/show_bug.cgi?id=12097 Olivier Blin freedesk...@blino.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #4 from Olivier Blin freedesk...@blino.org 2012-07-14 20:02:52 PDT --- Closing as wontfix, since unichrome (DRI1) has been dropped. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
quirk for Samsung 2443BW
Hello David,
Samsung 2443BW is 1920x1200 but reports 1920x1080 in the EDID. Attached
is a proof-of-concept implementation of a quirk. It works on my i686 PC.
The patch is against the latest linux-2.6. An attempt to clone
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git (as
listed in MAINTAINERS) resulted in fatal: The remote end hung up
unexpectedly.
This implementation matches the wrong mode by size. Other approaches are
possible.
I'd appreciate feedback.
With kind regards,
Baurzhan.
From b6c7a43e8b8fa0b6b39ed4a99c463071269d1a50 Mon Sep 17 00:00:00 2001
From: Baurzhan Ismagulov i...@radix50.net
Date: Sat, 14 Jul 2012 22:27:18 +0200
Subject: [PATCH 1/2] drm: Make edid_quirk_list const
Signed-off-by: Baurzhan Ismagulov i...@radix50.net
---
drivers/gpu/drm/drm_edid.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..09ff2bb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -86,7 +86,7 @@ static struct edid_quirk {
char vendor[4];
int product_id;
u32 quirks;
-} edid_quirk_list[] = {
+} const edid_quirk_list[] = {
/* Acer AL1706 */
{ ACR, 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
@@ -415,7 +415,7 @@ EXPORT_SYMBOL(drm_get_edid);
*
* Returns true if @vendor is in @edid, false otherwise
*/
-static bool edid_vendor(struct edid *edid, char *vendor)
+static bool edid_vendor(struct edid *edid, const char *vendor)
{
char edid_vendor[3];
@@ -435,7 +435,7 @@ static bool edid_vendor(struct edid *edid, char *vendor)
*/
static u32 edid_get_quirks(struct edid *edid)
{
- struct edid_quirk *quirk;
+ const struct edid_quirk *quirk;
int i;
for (i = 0; i ARRAY_SIZE(edid_quirk_list); i++) {
--
1.7.2.5
From ea4ca18f607c3829239ad602b0cb8d319fbcd75e Mon Sep 17 00:00:00 2001
From: Baurzhan Ismagulov i...@radix50.net
Date: Sat, 14 Jul 2012 22:23:33 +0200
Subject: [PATCH 2/2] drm: Add quirk for Samsung SyncMaster 2443BW
Signed-off-by: Baurzhan Ismagulov i...@radix50.net
---
drivers/gpu/drm/drm_edid.c | 64 ++-
1 files changed, 44 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 09ff2bb..73dda54 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -68,12 +68,14 @@
#define EDID_QUIRK_DETAILED_SYNC_PP (1 6)
/* Force reduced-blanking timings for detailed modes */
#define EDID_QUIRK_FORCE_REDUCED_BLANKING (1 7)
+/* Force size */
+#define EDID_QUIRK_FORCE_SIZE (1 8)
struct detailed_mode_closure {
struct drm_connector *connector;
struct edid *edid;
bool preferred;
- u32 quirks;
+ const struct edid_quirk *quirk;
int modes;
};
@@ -82,10 +84,23 @@ struct detailed_mode_closure {
#define LEVEL_GTF2 2
#define LEVEL_CVT 3
+struct size {
+ int x;
+ int y;
+};
+
+struct force_size {
+ struct size bad;
+ struct size good;
+};
+
static struct edid_quirk {
char vendor[4];
int product_id;
u32 quirks;
+ union {
+ struct force_size size;
+ } u;
} const edid_quirk_list[] = {
/* Acer AL1706 */
{ ACR, 44358, EDID_QUIRK_PREFER_LARGE_60 },
@@ -122,6 +137,9 @@ static struct edid_quirk {
/* Samsung SyncMaster 22[5-6]BW */
{ SAM, 596, EDID_QUIRK_PREFER_LARGE_60 },
{ SAM, 638, EDID_QUIRK_PREFER_LARGE_60 },
+ /* Samsung SyncMaster 2443BW */
+ { SAM, 0x06b0, EDID_QUIRK_FORCE_SIZE,
+ .u.size = { { 1920, 1080 }, { 1920, 1200 } } },
/* ViewSonic VA2026w */
{ VSC, 5020, EDID_QUIRK_FORCE_REDUCED_BLANKING },
@@ -428,12 +446,12 @@ static bool edid_vendor(struct edid *edid, const char *vendor)
}
/**
- * edid_get_quirks - return quirk flags for a given EDID
+ * edid_get_quirk - return quirk data for a given EDID
* @edid: EDID to process
*
* This tells subsequent routines what fixes they need to apply.
*/
-static u32 edid_get_quirks(struct edid *edid)
+static const struct edid_quirk *edid_get_quirk(struct edid *edid)
{
const struct edid_quirk *quirk;
int i;
@@ -443,10 +461,10 @@ static u32 edid_get_quirks(struct edid *edid)
if (edid_vendor(edid, quirk-vendor)
(EDID_PRODUCT_ID(edid) == quirk-product_id))
- return quirk-quirks;
+ return quirk;
}
- return 0;
+ return NULL;
}
#define MODE_SIZE(m) ((m)-hdisplay * (m)-vdisplay)
@@ -866,7 +884,7 @@ drm_mode_do_interlace_quirk(struct drm_display_mode *mode,
static struct drm_display_mode *drm_mode_detailed(struct drm_device *dev,
struct edid *edid,
struct detailed_timing *timing,
- u32 quirks)
+ const struct edid_quirk *quirk)
{
struct drm_display_mode *mode;
struct detailed_pixel_timing *pt = timing-data.pixel_data;
@@ -898,7 +916,7 @@ static struct drm_display_mode *drm_mode_detailed(struct drm_device *dev,
return NULL;
}
- if (quirks EDID_QUIRK_FORCE_REDUCED_BLANKING) {
+ if (quirk quirk-quirks EDID_QUIRK_FORCE_REDUCED_BLANKING) {
mode = drm_cvt_mode(dev, hactive, vactive,
[PATCH] intel: add prime interface for getting/setting a prime bo.
This adds interfaces for the X driver to use to create a
prime handle from a buffer, and create a bo from a handle.
Signed-off-by: Dave Airlie airl...@redhat.com
---
intel/intel_bufmgr.h |4
intel/intel_bufmgr_gem.c | 46 ++
2 files changed, 50 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 9b3a483..bf9ad5c 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -192,6 +192,10 @@ void drm_intel_gem_context_destroy(drm_intel_context *ctx);
int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
int used, unsigned int flags);
+int drm_intel_bufmgr_gem_set_bo_prime(drm_intel_bo *bo, int *prime_fd);
+drm_intel_bo *drm_intel_bufmgr_gem_get_bo_prime(drm_intel_bufmgr *bufmgr,
+ int prime_fd, int size);
+
/* drm_intel_bufmgr_fake.c */
drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
unsigned long low_offset,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 12a3197..dfba4e4 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2413,6 +2413,52 @@ drm_intel_gem_bo_get_tiling(drm_intel_bo *bo, uint32_t *
tiling_mode,
return 0;
}
+drm_intel_bo *
+drm_intel_bufmgr_gem_get_bo_prime(drm_intel_bufmgr *bufmgr, int prime_fd, int
size)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
+ int ret;
+ uint32_t handle;
+ drm_intel_bo_gem *bo_gem;
+ ret = drmPrimeFDToHandle(bufmgr_gem-fd, prime_fd, handle);
+ if (ret) {
+ fprintf(stderr,ret is %d %d\n, ret, errno);
+ return NULL;
+ }
+
+ bo_gem = calloc(1, sizeof(*bo_gem));
+ if (!bo_gem)
+ return NULL;
+
+ bo_gem-bo.size = size;
+ bo_gem-name = prime;
+ atomic_set(bo_gem-refcount, 1);
+ bo_gem-validate_index = -1;
+ bo_gem-reloc_tree_fences = 0;
+ bo_gem-used_as_reloc_target = false;
+ bo_gem-has_error = false;
+ bo_gem-reusable = false;
+
+ bo_gem-bo.handle = handle;
+ bo_gem-bo.bufmgr = bufmgr;
+
+ DRMINITLISTHEAD(bo_gem-name_list);
+ DRMINITLISTHEAD(bo_gem-vma_list);
+
+ bo_gem-gem_handle = handle;
+
+ return bo_gem-bo;
+}
+
+int
+drm_intel_bufmgr_gem_set_bo_prime(drm_intel_bo *bo, int *prime_fd)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
+ drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+
+ return drmPrimeHandleToFD(bufmgr_gem-fd, bo_gem-gem_handle,
DRM_CLOEXEC, prime_fd);
+}
+
static int
drm_intel_gem_bo_flink(drm_intel_bo *bo, uint32_t * name)
{
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
