RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM

> -Original Message- > From: Prathyush K [mailto:prathyus...@samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel@lists.freedesktop.org > Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; > subash.ramasw...@linaro.org > Subject: [PATCH 0/7] [RFC]

RE: [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd

> -Original Message- > From: Prathyush K [mailto:prathyus...@samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel@lists.freedesktop.org > Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; > subash.ramasw...@linaro.org > Subject: [PATCH 3/7] drm/e

RE: [PATCH 5/7] drm/exynos: attach drm device with common drm mapping

> -Original Message- > From: Prathyush K [mailto:prathyus...@samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel@lists.freedesktop.org > Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; > subash.ramasw...@linaro.org > Subject: [PATCH 5/7] drm/e

RE: [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function

> -Original Message- > From: Prathyush K [mailto:prathyus...@samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel@lists.freedesktop.org > Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; > subash.ramasw...@linaro.org > Subject: [PATCH 6/7] drm/e

RE: [PATCH 7/7] drm/exynos: Add IOMMU support for mapping gem object

> -Original Message- > From: Prathyush K [mailto:prathyus...@samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel@lists.freedesktop.org > Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; > subash.ramasw...@linaro.org > Subject: [PATCH 7/7] drm/e

Re: [PATCH] drm/radeon: fix bo creation retry path

On 13.07.2012 00:23, j.gli...@gmail.com wrote: From: Jerome Glisse Retry label was at wrong place in function leading to memory leak. Cc: Signed-off-by: Jerome Glisse Reviewed-by: Christian König --- drivers/gpu/drm/radeon/radeon_object.c |3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On 12.07.2012 18:36, Alex Deucher wrote: On Thu, Jul 12, 2012 at 12:12 PM, Christian König wrote: Before emitting any indirect buffer, emit the offset of the next valid ring content if any. This allow code that want to resume ring to resume ring right after ib that caused GPU lockup. v2: use s

Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM

On 07/13/2012 12:09 PM, Inki Dae wrote: -Original Message- From: Prathyush K [mailto:prathyus...@samsung.com] Sent: Wednesday, July 11, 2012 6:40 PM To: dri-devel@lists.freedesktop.org Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; subash.ramasw...@linaro.

Re: [PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On Fri, Jul 13, 2012 at 5:09 AM, Christian König wrote: > On 12.07.2012 18:36, Alex Deucher wrote: >> >> On Thu, Jul 12, 2012 at 12:12 PM, Christian König >> wrote: >>> >>> Before emitting any indirect buffer, emit the offset of the next >>> valid ring content if any. This allow code that want to

Re: [PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On 13.07.2012 14:27, Alex Deucher wrote: On Fri, Jul 13, 2012 at 5:09 AM, Christian König wrote: On 12.07.2012 18:36, Alex Deucher wrote: On Thu, Jul 12, 2012 at 12:12 PM, Christian König wrote: Before emitting any indirect buffer, emit the offset of the next valid ring content if any. This

Re: [PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On Fri, Jul 13, 2012 at 9:46 AM, Christian König wrote: > On 13.07.2012 14:27, Alex Deucher wrote: >> >> On Fri, Jul 13, 2012 at 5:09 AM, Christian König >> wrote: >>> >>> On 12.07.2012 18:36, Alex Deucher wrote: On Thu, Jul 12, 2012 at 12:12 PM, Christian König wrote: > >

[PATCH 1/3] drm/radeon: return an error if there is nothing to wait for

Otherwise the sa managers out of memory handling doesn't work. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_fence.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 76c5

[PATCH 2/3] drm/radeon: let sa manager block for fences to wait for

Otherwise we can encounter out of memory situations under extreme load. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon.h|2 +- drivers/gpu/drm/radeon/radeon_sa.c | 72 +--- 2 files changed, 51 insertions(+), 23 deletions(-) diff --git

[PATCH 3/3] drm/radeon: fix const IB handling

Const IBs are executed on the CE not the CP, so we can't fence them in the normal way. So submit them directly before the IB instead, just as the documentation says. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/r100.c|2 +- drivers/gpu/drm/radeon/r600.c|2 +-

Re: [PATCH 2/3] drm/radeon: let sa manager block for fences to wait for

On Fri, Jul 13, 2012 at 04:08:14PM +0200, Christian König wrote: > Otherwise we can encounter out of memory situations under extreme load. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/radeon/radeon.h|2 +- > drivers/gpu/drm/radeon/radeon_sa.c | 72 > +

Re: [PATCH 3/3] drm/radeon: fix const IB handling

On Fri, Jul 13, 2012 at 04:08:15PM +0200, Christian König wrote: > Const IBs are executed on the CE not the CP, so we can't > fence them in the normal way. > > So submit them directly before the IB instead, just as > the documentation says. > > Signed-off-by: Christian König > --- > drivers/gpu

Re: [PATCH 3/3] drm/radeon: fix const IB handling

On Fri, Jul 13, 2012 at 10:08 AM, Christian König wrote: > Const IBs are executed on the CE not the CP, so we can't > fence them in the normal way. > > So submit them directly before the IB instead, just as > the documentation says. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/rade

[Bug 52054] New: gallium/opencl doesnt support includes for opencl kernels

https://bugs.freedesktop.org/show_bug.cgi?id=52054 Bug #: 52054 Summary: gallium/opencl doesnt support includes for opencl kernels Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64)

[RFC] dma-fence: dma-buf synchronization (v2)

From: Rob Clark A dma-fence can be attached to a buffer which is being filled or consumed by hw, to allow userspace to pass the buffer without waiting to another device. For example, userspace can call page_flip ioctl to display the next frame of graphics after kicking the GPU but while the GPU

libdrm: Fix some warnings reported by clang's scan-build tool

Patches 1 to 4 were sent to mesa-dev. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] libkms/nouveau.c: Fix a memory leak and cleanup code a bit.

--- libkms/nouveau.c | 20 +++- 1 files changed, 11 insertions(+), 9 deletions(-) diff --git a/libkms/nouveau.c b/libkms/nouveau.c index 0e24a15..4cbca96 100644 --- a/libkms/nouveau.c +++ b/libkms/nouveau.c @@ -94,14 +94,18 @@ nouveau_bo_create(struct kms_driver *kms, if

[PATCH 1/5] libkms/intel.c: Fix a memory leak and a dead assignment as well as cleanup code a bit.

--- libkms/intel.c | 25 ++--- 1 files changed, 14 insertions(+), 11 deletions(-) diff --git a/libkms/intel.c b/libkms/intel.c index 8b8249b..b8ac343 100644 --- a/libkms/intel.c +++ b/libkms/intel.c @@ -93,14 +93,18 @@ intel_bo_create(struct kms_driver *kms, if (!bo)

[PATCH 3/5] nouveau/nouveau.c: Fix two memory leaks.

--- nouveau/nouveau.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c index 5aa4107..e91287f 100644 --- a/nouveau/nouveau.c +++ b/nouveau/nouveau.c @@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev

[PATCH 4/5] xf86drm.c: Make more code UDEV unrelevant and fix a memory leak.

--- xf86drm.c | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 6ea068f..e3789c8 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2, int pci_domain_ok) return 0; }

[PATCH 5/5] modetest.c: Add return 0 in bit_name_fn(res) macro.

--- tests/modetest/modetest.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index ec3121e..00129fa 100644 --- a/tests/modetest/modetest.c +++ b/tests/modetest/modetest.c @@ -128,6 +128,7 @@ char * res##_str(int type)

Re: libdrm: Fix some warnings reported by clang's scan-build tool

On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote: > > Patches 1 to 4 were sent to mesa-dev. And you chose to ignore most of my comments. Fine. Don't expect further reviews from me. Marcin ___ dri-devel mailing list dri-devel@lists.free

RE: [RFC] dma-fence: dma-buf synchronization (v2)

Hi Rob, Yes, sorry we've been a bit slack progressing KDS publicly. Your approach looks interesting and seems like it could enable both implicit and explicit synchronization. A good compromise. > From: Rob Clark > > A dma-fence can be attached to a buffer which is being filled or > consumed by

libdrm: Fix some warnings reported by clang's scan-build tool [try 2]

Am Freitag, 13. Juli 2012, 18:47:50 schrieb Marcin Slusarz: > On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote: > > > > Patches 1 to 4 were sent to mesa-dev. > > And you chose to ignore most of my comments. > Fine. Don't expect further reviews from me. > > Marcin Patch 1 and 2

[PATCH 1/6] libkms/intel.c: Fix a memory leak and a dead assignment as well as make some code easier to read.

--- libkms/intel.c | 32 +--- 1 files changed, 17 insertions(+), 15 deletions(-) diff --git a/libkms/intel.c b/libkms/intel.c index 8b8249b..12175b0 100644 --- a/libkms/intel.c +++ b/libkms/intel.c @@ -89,27 +89,32 @@ intel_bo_create(struct kms_driver *kms,

[PATCH 2/6] libkms/nouveau.c: Fix a memory leak and make some code easier to read.

--- libkms/nouveau.c | 27 ++- 1 files changed, 14 insertions(+), 13 deletions(-) diff --git a/libkms/nouveau.c b/libkms/nouveau.c index 0e24a15..fbca6fe 100644 --- a/libkms/nouveau.c +++ b/libkms/nouveau.c @@ -90,21 +90,24 @@ nouveau_bo_create(struct kms_driver *kms,

[PATCH 3/6] nouveau/nouveau.c: Fix two memory leaks.

--- nouveau/nouveau.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c index 5aa4107..e91287f 100644 --- a/nouveau/nouveau.c +++ b/nouveau/nouveau.c @@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev

[PATCH 4/6] xf86drm.c: Make more code UDEV unrelevant.

--- xf86drm.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 6ea068f..e652731 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2, int pci_domain_ok) return 0; } +

[PATCH 5/6] xf86drm.c: Fix two memory leaks.

--- xf86drm.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index e652731..c1cc170 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -1399,8 +1399,11 @@ drm_context_t *drmGetReservedContextList(int fd, int *count) } res.contexts = list; -

[PATCH 6/6] modetest.c: Add return 0 in bit_name_fn(res) macro.

--- tests/modetest/modetest.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index ec3121e..00129fa 100644 --- a/tests/modetest/modetest.c +++ b/tests/modetest/modetest.c @@ -128,6 +128,7 @@ char * res##_str(int type)

Re: [RFC] dma-fence: dma-buf synchronization (v2)

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

[pull] drm-intel-next

Hi Dave, New pull for -next. Highlights: - rc6/turbo support for hsw (Eugeni) - improve corner-case of the reset handling code - gpu reset handling should be rock-solid now - support for fb offset > 4096 pixels on gen4+ (yeah, you need some fairly big screens to hit that) - the "Flush Me Harde

[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 n

Re: [RFC] dma-fence: dma-buf synchronization (v2)

On Fri, Jul 13, 2012 at 4:44 PM, Maarten Lankhorst wrote: > 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

Re: [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 c

Re: general protection fault on ttm_init()

Can you try this patch on top of the previous one? I think it should fix it. Dave. 0001-drm-set-drm_class-to-NULL-after-removing-it.patch Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/

Re: 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 ___ dri-devel mailing list dr

[PATCH] Documentation: DocBook DRM framework documentation

Signed-off-by: Laurent Pinchart --- Documentation/DocBook/drm.tmpl | 2835 +++- 1 files changed, 2226 insertions(+), 609 deletions(-) Hi everybody, Here's the DRM kernel framework documentation previously posted to the dri-devel mailing list. The documentatio

[PATCH] drm/radeon: fix bo creation retry path

On Don, 2012-07-12 at 18:23 -0400, j.glisse at gmail.com wrote: > From: Jerome Glisse > > Retry label was at wrong place in function leading to memory > leak. > > Cc: > Signed-off-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon_object.c |3 ++- > 1 file changed, 2 insertions(+),

[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM

> -Original Message- > From: Prathyush K [mailto:prathyush.k at samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel at lists.freedesktop.org > Cc: prathyush at chromium.org; m.szyprowski at samsung.com; inki.dae at samsung.com; > subash.ramaswamy at linaro.org > Subject:

[PATCH 3/7] drm/exynos: add IOMMU support to drm fimd

> -Original Message- > From: Prathyush K [mailto:prathyush.k at samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel at lists.freedesktop.org > Cc: prathyush at chromium.org; m.szyprowski at samsung.com; inki.dae at samsung.com; > subash.ramaswamy at linaro.org > Subject:

[PATCH 5/7] drm/exynos: attach drm device with common drm mapping

> -Original Message- > From: Prathyush K [mailto:prathyush.k at samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel at lists.freedesktop.org > Cc: prathyush at chromium.org; m.szyprowski at samsung.com; inki.dae at samsung.com; > subash.ramaswamy at linaro.org > Subject:

[PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function

> -Original Message- > From: Prathyush K [mailto:prathyush.k at samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel at lists.freedesktop.org > Cc: prathyush at chromium.org; m.szyprowski at samsung.com; inki.dae at samsung.com; > subash.ramaswamy at linaro.org > Subject:

[PATCH 7/7] drm/exynos: Add IOMMU support for mapping gem object

> -Original Message- > From: Prathyush K [mailto:prathyush.k at samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel at lists.freedesktop.org > Cc: prathyush at chromium.org; m.szyprowski at samsung.com; inki.dae at samsung.com; > subash.ramaswamy at linaro.org > Subject:

[PATCH] drm/radeon: fix bo creation retry path

On 13.07.2012 00:23, j.glisse at gmail.com wrote: > From: Jerome Glisse > > Retry label was at wrong place in function leading to memory > leak. > > Cc: > Signed-off-by: Jerome Glisse Reviewed-by: Christian K?nig > --- > drivers/gpu/drm/radeon/radeon_object.c |3 ++- > 1 file changed, 2

[PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On 12.07.2012 18:36, Alex Deucher wrote: > On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig > wrote: >> Before emitting any indirect buffer, emit the offset of the next >> valid ring content if any. This allow code that want to resume >> ring to resume ring right after ib that caused GPU lockup.

[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM

On 07/13/2012 12:09 PM, Inki Dae wrote: > >> -Original Message- >> From: Prathyush K [mailto:prathyush.k at samsung.com] >> Sent: Wednesday, July 11, 2012 6:40 PM >> To: dri-devel at lists.freedesktop.org >> Cc: prathyush at chromium.org; m.szyprowski at samsung.com; > inki.dae at samsung.c

[PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On Fri, Jul 13, 2012 at 5:09 AM, Christian K?nig wrote: > On 12.07.2012 18:36, Alex Deucher wrote: >> >> On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig >> wrote: >>> >>> Before emitting any indirect buffer, emit the offset of the next >>> valid ring content if any. This allow code that want to

[PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On 13.07.2012 14:27, Alex Deucher wrote: > On Fri, Jul 13, 2012 at 5:09 AM, Christian K?nig > wrote: >> On 12.07.2012 18:36, Alex Deucher wrote: >>> On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig >>> wrote: Before emitting any indirect buffer, emit the offset of the next valid ring c

[PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v3

On Fri, Jul 13, 2012 at 9:46 AM, Christian K?nig wrote: > On 13.07.2012 14:27, Alex Deucher wrote: >> >> On Fri, Jul 13, 2012 at 5:09 AM, Christian K?nig >> wrote: >>> >>> On 12.07.2012 18:36, Alex Deucher wrote: On Thu, Jul 12, 2012 at 12:12 PM, Christian K?nig wrote: > >

[PATCH 1/3] drm/radeon: return an error if there is nothing to wait for

Otherwise the sa managers out of memory handling doesn't work. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_fence.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 76c5

[PATCH 2/3] drm/radeon: let sa manager block for fences to wait for

Otherwise we can encounter out of memory situations under extreme load. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h|2 +- drivers/gpu/drm/radeon/radeon_sa.c | 72 +--- 2 files changed, 51 insertions(+), 23 deletions(-) diff --git

[PATCH 3/3] drm/radeon: fix const IB handling

Const IBs are executed on the CE not the CP, so we can't fence them in the normal way. So submit them directly before the IB instead, just as the documentation says. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/r100.c|2 +- drivers/gpu/drm/radeon/r600.c|2 +-

[PATCH 2/3] drm/radeon: let sa manager block for fences to wait for

On Fri, Jul 13, 2012 at 04:08:14PM +0200, Christian K?nig wrote: > Otherwise we can encounter out of memory situations under extreme load. > > Signed-off-by: Christian K?nig > --- > drivers/gpu/drm/radeon/radeon.h|2 +- > drivers/gpu/drm/radeon/radeon_sa.c | 72 > +

[PATCH 3/3] drm/radeon: fix const IB handling

On Fri, Jul 13, 2012 at 04:08:15PM +0200, Christian K?nig wrote: > Const IBs are executed on the CE not the CP, so we can't > fence them in the normal way. > > So submit them directly before the IB instead, just as > the documentation says. > > Signed-off-by: Christian K?nig > --- > drivers/gpu

[PATCH 3/3] drm/radeon: fix const IB handling

On Fri, Jul 13, 2012 at 10:08 AM, Christian K?nig wrote: > Const IBs are executed on the CE not the CP, so we can't > fence them in the normal way. > > So submit them directly before the IB instead, just as > the documentation says. > > Signed-off-by: Christian K?nig > --- > drivers/gpu/drm/rade

[Bug 52054] New: gallium/opencl doesnt support includes for opencl kernels

https://bugs.freedesktop.org/show_bug.cgi?id=52054 Bug #: 52054 Summary: gallium/opencl doesnt support includes for opencl kernels Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64)

[RFC] dma-fence: dma-buf synchronization (v2)

From: Rob Clark A dma-fence can be attached to a buffer which is being filled or consumed by hw, to allow userspace to pass the buffer without waiting to another device. For example, userspace can call page_flip ioctl to display the next frame of graphics after kicking the GPU but while the GPU

libdrm: Fix some warnings reported by clang's scan-build tool

Patches 1 to 4 were sent to mesa-dev.

[PATCH 2/5] libkms/nouveau.c: Fix a memory leak and cleanup code a bit.

--- libkms/nouveau.c | 20 +++- 1 files changed, 11 insertions(+), 9 deletions(-) diff --git a/libkms/nouveau.c b/libkms/nouveau.c index 0e24a15..4cbca96 100644 --- a/libkms/nouveau.c +++ b/libkms/nouveau.c @@ -94,14 +94,18 @@ nouveau_bo_create(struct kms_driver *kms, if

[PATCH 1/5] libkms/intel.c: Fix a memory leak and a dead assignment as well as cleanup code a bit.

--- libkms/intel.c | 25 ++--- 1 files changed, 14 insertions(+), 11 deletions(-) diff --git a/libkms/intel.c b/libkms/intel.c index 8b8249b..b8ac343 100644 --- a/libkms/intel.c +++ b/libkms/intel.c @@ -93,14 +93,18 @@ intel_bo_create(struct kms_driver *kms, if (!bo)

[PATCH 3/5] nouveau/nouveau.c: Fix two memory leaks.

--- nouveau/nouveau.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c index 5aa4107..e91287f 100644 --- a/nouveau/nouveau.c +++ b/nouveau/nouveau.c @@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev

[PATCH 4/5] xf86drm.c: Make more code UDEV unrelevant and fix a memory leak.

--- xf86drm.c | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 6ea068f..e3789c8 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2, int pci_domain_ok) return 0; }

[PATCH 5/5] modetest.c: Add return 0 in bit_name_fn(res) macro.

--- tests/modetest/modetest.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index ec3121e..00129fa 100644 --- a/tests/modetest/modetest.c +++ b/tests/modetest/modetest.c @@ -128,6 +128,7 @@ char * res##_str(int type)

libdrm: Fix some warnings reported by clang's scan-build tool

On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote: > > Patches 1 to 4 were sent to mesa-dev. And you chose to ignore most of my comments. Fine. Don't expect further reviews from me. Marcin

[RFC] dma-fence: dma-buf synchronization (v2)

Hi Rob, Yes, sorry we've been a bit slack progressing KDS publicly. Your approach looks interesting and seems like it could enable both implicit and explicit synchronization. A good compromise. > From: Rob Clark > > A dma-fence can be attached to a buffer which is being filled or > consumed by

libdrm: Fix some warnings reported by clang's scan-build tool [try 2]

Am Freitag, 13. Juli 2012, 18:47:50 schrieb Marcin Slusarz: > On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote: > > > > Patches 1 to 4 were sent to mesa-dev. > > And you chose to ignore most of my comments. > Fine. Don't expect further reviews from me. > > Marcin Patch 1 and 2

[PATCH 1/6] libkms/intel.c: Fix a memory leak and a dead assignment as well as make some code easier to read.

--- libkms/intel.c | 32 +--- 1 files changed, 17 insertions(+), 15 deletions(-) diff --git a/libkms/intel.c b/libkms/intel.c index 8b8249b..12175b0 100644 --- a/libkms/intel.c +++ b/libkms/intel.c @@ -89,27 +89,32 @@ intel_bo_create(struct kms_driver *kms,

[PATCH 2/6] libkms/nouveau.c: Fix a memory leak and make some code easier to read.

--- libkms/nouveau.c | 27 ++- 1 files changed, 14 insertions(+), 13 deletions(-) diff --git a/libkms/nouveau.c b/libkms/nouveau.c index 0e24a15..fbca6fe 100644 --- a/libkms/nouveau.c +++ b/libkms/nouveau.c @@ -90,21 +90,24 @@ nouveau_bo_create(struct kms_driver *kms,

[PATCH 3/6] nouveau/nouveau.c: Fix two memory leaks.

--- nouveau/nouveau.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c index 5aa4107..e91287f 100644 --- a/nouveau/nouveau.c +++ b/nouveau/nouveau.c @@ -95,6 +95,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev

[PATCH 4/6] xf86drm.c: Make more code UDEV unrelevant.

--- xf86drm.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 6ea068f..e652731 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char *id2, int pci_domain_ok) return 0; } +#

[PATCH 5/6] xf86drm.c: Fix two memory leaks.

--- xf86drm.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index e652731..c1cc170 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -1399,8 +1399,11 @@ drm_context_t *drmGetReservedContextList(int fd, int *count) } res.contexts = list; -

[PATCH 6/6] modetest.c: Add return 0 in bit_name_fn(res) macro.

--- tests/modetest/modetest.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index ec3121e..00129fa 100644 --- a/tests/modetest/modetest.c +++ b/tests/modetest/modetest.c @@ -128,6 +128,7 @@ char * res##_str(int type)

[RFC] dma-fence: dma-buf synchronization (v2)

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

[pull] drm-intel-next

Hi Dave, New pull for -next. Highlights: - rc6/turbo support for hsw (Eugeni) - improve corner-case of the reset handling code - gpu reset handling should be rock-solid now - support for fb offset > 4096 pixels on gen4+ (yeah, you need some fairly big screens to hit that) - the "Flush Me Harde

[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 n

[RFC] dma-fence: dma-buf synchronization (v2)

On Fri, Jul 13, 2012 at 4:44 PM, Maarten Lankhorst wrote: > 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

[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 >