[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

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

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

--- Comment #62 from Alexandre Demers  
2012-06-06 15:37:07 PDT ---
(In reply to comment #61)
> Please also try this patch:
> http://lists.freedesktop.org/archives/dri-devel/2012-June/023735.html
> 
> It doesn't fix anything rendering related, but instead fixes a deadlock
> introduced with the vm patch It isn't the complete solution of the problem it
> might still be an improvement.
> 
> Christian.

Thanks Christian. I just tested the patch and it still fails. Running piglit on
r600.test hangs, kills Xorg, restarts without any 3D support and produce the
following:

-
dmesg:

[   44.640434] retire_capture_urb: 1 callbacks suppressed
[   64.193666] radeon :01:00.0: bo 88021b1d2400 va 0x0180D000 conflict
with (bo 880221d00400 0x0180D000 0x0180E000)
[   64.242569] radeon :01:00.0: bo 880221d1dc00 va 0x0184E000 conflict
with (bo 8802135ac800 0x0184E000 0x0184F000)
[   64.369362] radeon :01:00.0: bo 880222126800 va 0x01841000 conflict
with (bo 88021b3b4400 0x01841000 0x01842000)
[   64.832098] radeon :01:00.0: bo 88021352dc00 va 0x01859000 conflict
with (bo 880222c42800 0x01859000 0x0185B000)
[   65.486230] EXT4-fs (sdc2): warning: maximal mount count reached, running
e2fsck is recommended
[   65.540929] EXT4-fs (sdc2): mounted filesystem with ordered data mode. Opts:
(null)
[   69.016383] radeon :01:00.0: bo 880221d1e000 va 0x0402D000 conflict
with (bo 880221fc5000 0x0402D000 0x0402E000)
[   69.017579] radeon :01:00.0: bo 880221d1b400 va 0x0404D000 conflict
with (bo 880206061400 0x0404D000 0x0404E000)
[  471.209470] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[  471.209482] radeon :01:00.0: GPU lockup (waiting for 0x1ee7
last fence id 0x1ee4)
[  471.708793] radeon :01:00.0: GPU lockup CP stall for more than 10500msec
[  471.708803] radeon :01:00.0: GPU lockup (waiting for 0x1ee5)
[  471.708812] radeon :01:00.0: failed to get a new IB (-35)
[  471.708818] [drm:radeon_cs_ib_chunk] *ERROR* Failed to get ib !
[  471.712988] radeon :01:00.0: GPU softreset 
[  471.712996] radeon :01:00.0:   GRBM_STATUS=0xB3703828
[  471.713001] radeon :01:00.0:   GRBM_STATUS_SE0=0x2407
[  471.713006] radeon :01:00.0:   GRBM_STATUS_SE1=0x3D07
[  471.713012] radeon :01:00.0:   SRBM_STATUS=0x200206C0
[  471.713017] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_ADDR  
0x
[  471.713023] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_STATUS
0x
[  471.713029] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  471.713035] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x07070010
[  471.862829] radeon :01:00.0: Wait for MC idle timedout !
[  471.862831] radeon :01:00.0:   GRBM_SOFT_RESET=0xDF7B
[  471.862933] radeon :01:00.0:   GRBM_STATUS=0x3828
[  471.862934] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[  471.862936] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[  471.862937] radeon :01:00.0:   SRBM_STATUS=0x200206C0
[  471.863938] radeon :01:00.0: GPU reset succeed
[  472.044573] radeon :01:00.0: Wait for MC idle timedout !
[  472.202790] radeon :01:00.0: Wait for MC idle timedout !
[  472.204511] [drm] PCIE GART of 512M enabled (table at 0x0004).
[  472.204582] radeon :01:00.0: WB enabled
[  472.204584] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x880221964c00
[  472.204586] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x4c04 and cpu addr 0x880221964c04
[  472.204587] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x4c08 and cpu addr 0x880221964c08
[  472.387014] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8500)=0xCAFEDEAD)
[  472.387015] [drm:cayman_resume] *ERROR* cayman startup failed on resume
[  472.406246] radeon :01:00.0: 88021c7d3800 unpin not necessary
[  472.406260] radeon :01:00.0: 88021c7d3c00 unpin not necessary
[  472.407518] radeon :01:00.0: GPU softreset 
[  472.407525] radeon :01:00.0:   GRBM_STATUS=0xA0003828
[  472.407530] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[  472.407536] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[  472.407541] radeon :01:00.0:   SRBM_STATUS=0x200206C0
[  472.407546] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_ADDR  
0x
[  472.407552] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_STATUS
0x
[  472.407557] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  472.407562] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x07070010
[  472.577076] radeon :01:00.0: Wait for MC idle timedout !
[  472.577080] radeon :01:00.0:   GRBM_SOFT_RESET=0xDF7B
[  472.577183] radeon :01:00.0:   GRBM_STATUS=0x3828
[  

[Bug 36602] Hierarchical Z support for R600

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

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

--- Comment #45 from darkbasic  2012-06-06 
15:33:35 PDT ---
Thanks Jerome

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36602] Hierarchical Z support for R600

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

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

--- Comment #44 from Jerome Glisse  2012-06-06 
15:24:55 PDT ---
Updated with more fixes (down to ~100 regression with piglit)

http://people.freedesktop.org/~glisse/0001-r600g-add-htile-support-v6.patch

To enable hyperz
R600_HYPERZ=1 glxgears

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43346] New: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018

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

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

   Summary: BUG: unable to handle kernel NULL pointer dereference
at 0018
   Product: Drivers
   Version: 2.5
Kernel Version: 3.2.18
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: bjorn.ottervik at gmail.com
Regression: No


Happens about once a week, but I can't reproduce it at will. X is still running
as before, but unbearably slow. GPU is an integrated HD4200 of an AMD 785G ASUS
mainboard, model M4A785D-M Pro.

[261062.255333] [TTM] Erroneous page count. Leaking pages.
[261062.753541] BUG: unable to handle kernel NULL pointer dereference at
0018
[261062.753705] IP: [] ttm_bo_cleanup_memtype_use+0x51/0x80
[261062.753830] PGD 214e12067 PUD 214e64067 PMD 0 
[261062.753918] Oops:  [#1] SMP 
[261062.753981] CPU 0 
[261062.754007] Modules linked in: sata_sil
[261062.754007] 
[261062.754007] Pid: 2467, comm: xbmc.bin Not tainted 3.2.18 #1 System
manufacturer System Product Name/M4A785D-M PRO
[261062.754007] RIP: 0010:[]  []
ttm_bo_cleanup_memtype_use+0x51/0x80
[261062.754007] RSP: 0018:88021fbd7c58  EFLAGS: 00010256
[261062.754007] RAX:  RBX: 88003c8c6c48 RCX:
8802267f0548
[261062.754007] RDX:  RSI: 88003c8c6ca8 RDI:
8802267f0570
[261062.754007] RBP: 0002 R08:  R09:
813f9a41
[261062.754007] R10: 0039 R11: 0246 R12:
8802267f0548
[261062.754007] R13: 8802259853c0 R14: 88003c8c6c8c R15:
fff2
[261062.754007] FS:  7fe3f3cba720() GS:88022fc0()
knlGS:
[261062.754007] CS:  0010 DS:  ES:  CR0: 80050033
[261062.754007] CR2: 0018 CR3: 000214e0d000 CR4:
06f0
[261062.754007] DR0:  DR1:  DR2:

[261062.754007] DR3:  DR6: 0ff0 DR7:
0400
[261062.754007] Process xbmc.bin (pid: 2467, threadinfo 88021fbd6000, task
88022212)
[261062.754007] Stack:
[261062.754007]  88003c8c6c48 813fad00 88004421b200
88004421b200
[261062.754007]  88021fbd7d74  880226ff5000
88003c8c6c88
[261062.754007]  813faaa0 000a 88003c8c6e00
880226ff5000
[261062.754007] Call Trace:
[261062.754007]  [] ? ttm_bo_release+0x260/0x280
[261062.754007]  [] ? ttm_bo_delayed_workqueue+0x30/0x30
[261062.754007]  [] ? kref_put+0x33/0x70
[261062.754007]  [] ? ttm_bo_unref+0x35/0x50
[261062.754007]  [] ? radeon_bo_unref+0x42/0x80
[261062.754007]  [] ? drm_gem_object_ref_bug+0x10/0x10
[261062.754007]  [] ? radeon_gem_object_free+0x1f/0x30
[261062.754007]  [] ? kref_put+0x33/0x70
[261062.754007]  [] ? drm_gem_handle_delete+0xa8/0xf0
[261062.754007]  [] ? drm_ioctl+0x3ec/0x4a0
[261062.754007]  [] ? cpumask_any_but+0x2d/0x40
[261062.754007]  [] ? drm_gem_destroy+0x50/0x50
[261062.754007]  [] ? tlb_finish_mmu+0xe/0x50
[261062.754007]  [] ? unmap_region+0x10b/0x150
[261062.754007]  [] ? do_vfs_ioctl+0x96/0x540
[261062.754007]  [] ? remove_vma+0x52/0x70
[261062.754007]  [] ? do_munmap+0x2d6/0x360
[261062.754007]  [] ? sys_ioctl+0x49/0x80
[261062.754007]  [] ? system_call_fastpath+0x16/0x1b
[261062.754007] Code: 00 00 00 00 00 00 48 83 7b 60 00 48 8b 4b 08 8b 93 84 00
00 00 74 17 89 d2 48 8d 73 60 48 c1 e2 07 48 8b 44 11 50 48 8d 7c 11 28  50
18 c7 83 20 01 00 00 00 00 00 00 48 8d 7b 48 31 c9 31 d2 
[261062.754007] RIP  [] ttm_bo_cleanup_memtype_use+0x51/0x80
[261062.754007]  RSP 
[261062.754007] CR2: 0018
[261062.795877] ---[ end trace 4bb94fa28b7f787a ]---

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

[PATCH] drm/radeon/kms: attempt to fix rs690 issues.

[Dave Airlie]

From: Dave Airlie 

Since c9a1be96277b3b2d2e8aff2ba69d7817ea8e46c9, or at least since v3.2
we've had some regression reports, this is an attempt to fix them by
putting back some volatiles that were removed in that commit.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/r100.c|2 +-
 drivers/gpu/drm/radeon/r300.c|2 +-
 drivers/gpu/drm/radeon/radeon.h  |2 +-
 drivers/gpu/drm/radeon/radeon_gart.c |2 +-
 drivers/gpu/drm/radeon/rs400.c   |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index fb44e7e..26488f7 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -680,7 +680,7 @@ void r100_pci_gart_disable(struct radeon_device *rdev)

 int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
-   u32 *gtt = rdev->gart.ptr;
+   volatile u32 *gtt = rdev->gart.ptr;

if (i < 0 || i > rdev->gart.num_gpu_pages) {
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..bb596f4 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -74,7 +74,7 @@ void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev)

 int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
-   void __iomem *ptr = rdev->gart.ptr;
+   void __iomem *ptr = (void *)rdev->gart.ptr;

if (i < 0 || i > rdev->gart.num_gpu_pages) {
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fefcca5..3fd759a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -470,7 +470,7 @@ struct radeon_mc;
 struct radeon_gart {
dma_addr_t  table_addr;
struct radeon_bo*robj;
-   void*ptr;
+   volatile void   *ptr;
unsignednum_gpu_pages;
unsignednum_cpu_pages;
unsignedtable_size;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 59d4493..b2db83a 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -102,7 +102,7 @@ int radeon_gart_table_vram_pin(struct radeon_device *rdev)
radeon_bo_unreserve(rdev->gart.robj);
return r;
}
-   r = radeon_bo_kmap(rdev->gart.robj, >gart.ptr);
+   r = radeon_bo_kmap(rdev->gart.robj, (void **)>gart.ptr);
if (r)
radeon_bo_unpin(rdev->gart.robj);
radeon_bo_unreserve(rdev->gart.robj);
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index a464eb5..82f1a7c 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -212,7 +212,7 @@ void rs400_gart_fini(struct radeon_device *rdev)
 int rs400_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
uint32_t entry;
-   u32 *gtt = rdev->gart.ptr;
+   volatile u32 *gtt = rdev->gart.ptr;

if (i < 0 || i > rdev->gart.num_gpu_pages) {
return -EINVAL;
-- 
1.7.10.2

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

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

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

--- Comment #3 from C?dric Legrand  2012-06-06 
11:49:29 PDT ---
I'm sorry, forgot to say that the pointer is the cause of the bug. Directly
accessing the Game class with a global variable works perfectly.

 I'm sorry for my english 

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2 v4] intel: wait render timeout implementation

[Ben Widawsky]

int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)

This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.

v2: don't return remaining timeout amount
use get param and fallback for older kernels

v3: only doing getparam at init
prototypes now have a signed input value

v4: update comments
fall back to correct polling behavior with new userspace and old kernel

Cc: Eric Anholt 
Cc: Daniel Vetter 
Signed-off-by: Ben Widawsky 
---
 intel/intel_bufmgr.h |1 +
 intel/intel_bufmgr_gem.c |   51 ++
 2 files changed, 52 insertions(+)

diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index c197abc..fa6c4dd 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr 
*bufmgr, int crtc_id);

 int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
 int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);

 /* drm_intel_bufmgr_fake.c */
 drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b776d2f..f8e3706 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_blt : 1;
unsigned int has_relaxed_fencing : 1;
unsigned int has_llc : 1;
+   unsigned int has_wait_timeout : 1;
unsigned int bo_reuse : 1;
unsigned int no_exec : 1;
bool fenced_relocs;
@@ -1479,6 +1480,52 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
 }

 /**
+ * Waits on a BO for the given amount of time.
+ *
+ * @bo: buffer object to wait for
+ * @timeout_ns: amount of time to wait in nanoseconds.
+ *   If value is less than 0, an infinite wait will occur.
+ *
+ * Returns 0 if the wait was successful ie. the last batch referencing the
+ * object has completed within the allotted time. Otherwise some negative 
return
+ * value describes the error.
+ *
+ * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter allows
+ * the operation to give up after a certain amount of time. Another subtle
+ * difference is the internal locking semantics are different (this variant 
does
+ * not hold the lock for the duration of the wait). This makes the wait subject
+ * to a larger userspace race window.
+ *
+ * The implementation shall wait until the object is no longer actively
+ * referenced within a batch buffer at the time of the call. The wait will
+ * not guarantee that the buffer is re-issued via another thread, or an flinked
+ * handle. Userspace must make sure this race does not occur if such precision
+ * is important.
+ */
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
+{
+   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+   struct drm_i915_gem_wait wait;
+
+   if (!bufmgr_gem->has_wait_timeout) {
+   DBG("%s:%d: Timed wait is not supported. Falling back to "
+   "infinite wait\n", __FILE__, __LINE__);
+   if (timeout_ns) {
+   drm_intel_gem_bo_wait_rendering(bo);
+   return 0;
+   } else {
+   return drm_intel_gem_bo_busy(bo);
+   }
+   }
+
+   wait.bo_handle = bo_gem->gem_handle;
+   wait.timeout_ns = timeout_ns;
+   wait.flags = 0;
+   return drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_WAIT, );
+}
+
+/**
  * Sets the object to the GTT read and possibly write domain, used by the X
  * 2D driver in the absence of kernel support to do drm_intel_gem_bo_map_gtt().
  *
@@ -2898,6 +2945,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
bufmgr_gem->has_relaxed_fencing = ret == 0;

+   gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
+   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
+   bufmgr_gem->has_wait_timeout = ret == 0;
+
gp.param = I915_PARAM_HAS_LLC;
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
if (ret != 0) {
-- 
1.7.10.3

[PATCH 1/2] drm: drmIoctl return -errno on failure conditions

[Ben Widawsky]

Anyone aware of what this will break? It seems to be a much nicer thing
to do for callers. If people do not like it, I will probably just create
a #define drmIoctl2 or some such thing.

Cc: Daniel Vetter 
Cc: Keith Packard 
Signed-off-by: Ben Widawsky 
---
 xf86drm.c |4 
 1 file changed, 4 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..015203d 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -166,6 +166,10 @@ drmIoctl(int fd, unsigned long request, void *arg)
 do {
ret = ioctl(fd, request, arg);
 } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
+
+if (ret)
+   return -errno;
+
 return ret;
 }

-- 
1.7.10.3

[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[John Reitan]

Hi All,

I'm the original designer of the KDS system that Tom posted 
while I was on paternity leave. Find my responses inline...

> -Original Message-
> From: linaro-mm-sig-bounces at lists.linaro.org [mailto:linaro-mm-sig-
> bounces at lists.linaro.org] On Behalf Of Rob Clark
> Sent: Monday, June 04, 2012 10:31 PM
> To: Tom Cooksey
> Cc: linaro-mm-sig at lists.linaro.org; Pauli; dri-
> devel at lists.freedesktop.org
> Subject: Re: [Linaro-mm-sig] [RFC] Synchronizing access to buffers
> shared with dma-buf between drivers/devices
> 
> Some comments inline.. at this stage mostly superficial issues about
> how the API works, etc..  not had a chance to dig too much into the
> implementation yet (although some of my comments about the API would
> change those anyways).

It was the API we really wanted input on.
The implementation still leaves a bit to be desired. 

> Anyways, thanks for getting the ball rolling on this, and I think I
> can volunteer linaro to pick up and run w/ this if needed.
> 
> On Fri, May 25, 2012 at 7:08 PM, Tom Cooksey 
> wrote:
> > Hi All,
> >
> > I realise it's been a while since this was last discussed, however
> I'd like
> > to bring up kernel-side synchronization again. By kernel-side
> > synchronization, I mean allowing multiple drivers/devices wanting to
> access
> > the same buffer to do so without bouncing up to userspace to resolve
> > dependencies such as "the display controller can't start scanning out
> a
> > buffer until the GPU has finished rendering into it". As such, this
> is
> > really just an optimization which reduces latency between E.g. The
> GPU
> > finishing a rendering job and that buffer being scanned out. I
> appreciate
> > this particular example is already solved on desktop graphics cards
> as the
> > display controller and 3D core are both controlled by the same
> driver, so no
> > "generic" mechanism is needed. However on ARM SoCs, the 3D core (like
> an ARM
> > Mali) and display controller tend to be driven by separate drivers,
> so some
> > mechanism is needed to allow both drivers to synchronize their access
> to
> > buffers.
> >
> > There are multiple ways synchronization can be achieved, fences/sync
> objects
> > is one common approach, however we're presenting a different
> approach.
> > Personally, I quite like fence sync objects, however we believe it
> requires
> > a lot of userspace interfaces to be changed to pass around sync
> object
> > handles. Our hope is that the kds approach will require less effort
> to make
> > use of as no existing userspace interfaces need to be changed. E.g.
> To use
> > explicit fences, the struct drm_mode_crtc_page_flip would need a new
> members
> > to pass in the handle(s) of sync object(s) which the flip depends on
> (I.e.
> > don't flip until these fences fire). The additional benefit of our
> approach
> > is that it prevents userspace specifying dependency loops which can
> cause a
> > deadlock (see kds.txt for an explanation of what I mean here).
> >
> > I have waited until now to bring this up again because I am now able
> to
> > share the code I was trying (and failing I think) to explain
> previously. The
> > code has now been released under the GPLv2 from ARM Mali's developer
> portal,
> > however I've attempted to turn that into a patch to allow it to be
> discussed
> > on this list. Please find the patch inline below.
> >
> > While KDS defines a very generic mechanism, I am proposing that this
> code or
> > at least the concepts be merged with the existing dma_buf code, so a
> the
> > struct kds_resource members get moved to struct dma_buf, kds_*
> functions get
> > renamed to dma_buf_* functions, etc. So I guess what I'm saying is
> please
> > don't review the actual code just yet, only the concepts the code
> describes,
> > where kds_resource == dma_duf.
> >
> >
> > Cheers,
> >
> > Tom
> >
> >
> >
> > Author: Tom Cooksey 
> > Date:   Fri May 25 10:45:27 2012 +0100
> >
> >Add new system to allow synchronizing access to resources
> >
> >See Documentation/kds.txt for details, however the general
> >idea is that this kds framework synchronizes multiple drivers
> >("clients") wanting to access the same resources, where a
> >resource is typically a 2D image buffer being shared around
> >using dma-buf.
> >
> >Note: This patch is created by extracting the sources from the
> >tarball on  >ux-kernel-device-drivers---dev-releases.php> and putting them in
> >roughly the right places.
> >
> > diff --git a/Documentation/kds.txt b/Documentation/kds.txt
> 
> fwiw, I think the documentation could be made a bit more generic, but
> this and code style, etc shouldn't be too hard to fix
> 
> > new file mode 100644
> > index 000..a96db21
> > --- /dev/null
> > +++ b/Documentation/kds.txt
> > @@ -0,0 +1,113 @@
> > +#
> > +# (C) COPYRIGHT 2012 ARM Limited. All rights reserved.
> > +#
> > +# This program is free 

[PATCH 3/3] drm/edid: Add csync parsing

[Adam Jackson]

Just assume saying "this is csync" is enough for whatever the output
type is.  The xfree86 mode flags distinguish between positive and
negative csync, but EDID doesn't encode that.

No connector types set csync_allowed yet, so this is a no-op besides
getting the message to shut up.

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_crtc.c|2 +-
 drivers/gpu/drm/drm_crtc_helper.c |5 +
 drivers/gpu/drm/drm_edid.c|   29 +
 include/drm/drm_crtc.h|2 ++
 include/drm/drm_edid.h|   15 ++-
 include/drm/drm_mode.h|4 
 6 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..265efe8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1081,7 +1081,7 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
out->vtotal = in->vtotal;
out->vscan = in->vscan;
out->vrefresh = in->vrefresh;
-   out->flags = in->flags;
+   out->flags = in->flags & DRM_MODE_FLAG_USERSPACE_MASK;
out->type = in->type;
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..d4625db 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -57,6 +57,9 @@ static void drm_mode_validate_flag(struct drm_connector 
*connector,
if ((mode->flags & DRM_MODE_FLAG_DBLSCAN) &&
!(flags & DRM_MODE_FLAG_DBLSCAN))
mode->status = MODE_NO_DBLESCAN;
+   if ((mode->flags & DRM_MODE_FLAG_CSYNC) &&
+   !(flags & DRM_MODE_FLAG_CSYNC))
+   mode->status = MODE_NO_CSYNC;
}

return;
@@ -140,6 +143,8 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
mode_flags |= DRM_MODE_FLAG_INTERLACE;
if (connector->doublescan_allowed)
mode_flags |= DRM_MODE_FLAG_DBLSCAN;
+   if (connector->csync_allowed)
+   mode_flags |= DRM_MODE_FLAG_CSYNC;
drm_mode_validate_flag(connector, mode_flags);

list_for_each_entry(mode, >modes, head) {
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index be21040..a8af442 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -857,10 +857,27 @@ static void
 drm_mode_detailed_set_sync_flags(struct detailed_pixel_timing *pt,
 unsigned int *flags)
 {
-   *flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
-   *flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+   switch (pt->misc & DRM_EDID_PT_SEPARATE_SYNC) {
+   case DRM_EDID_PT_SEPARATE_SYNC: /* digital, separate */
+   *flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
+   *flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+   break;
+   case DRM_EDID_PT_DIGITAL_CSYNC: /* digital, composite */
+   *flags |= DRM_MODE_FLAG_CSYNC;
+   if (pt->misc & DRM_EDID_PT_CSYNC_SERRATION)
+   *flags |= DRM_MODE_FLAG_SYNC_SERRATION;
+   break;
+   case DRM_EDID_PT_BIANALOG_CSYNC: /* bipolar analog composite */
+   case DRM_EDID_PT_ANALOG_CSYNC: /* unipolar analog composite */
+   *flags |= DRM_MODE_FLAG_CSYNC;
+   if (pt->misc & DRM_EDID_PT_CSYNC_SERRATION)
+   *flags |= DRM_MODE_FLAG_SYNC_SERRATION;
+   if (pt->misc & DRM_EDID_PT_CSYNC_RGB)
+   *flags |= DRM_MODE_FLAG_SYNC_RGB; /* else sync-on-green */
+   break;
+   }
 }

 /**
@@ -898,10 +915,6 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
return NULL;
}

-   if (!(pt->misc & DRM_EDID_PT_SEPARATE_SYNC)) {
-   printk(KERN_WARNING "composite sync not supported\n");
-   }
-
/* it is incorrect if hsync/vsync width is zero */
if (!hsync_pulse_width || !vsync_pulse_width) {
DRM_DEBUG_KMS("Incorrect Detailed timing. "
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 73e4560..d0c958e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -105,6 +105,7 @@ enum drm_mode_status {
 MODE_ONE_HEIGHT,/* only one height is supported */
 MODE_ONE_SIZE,  /* only one resolution is supported */
 MODE_NO_REDUCED,/* monitor doesn't accept reduced blanking */
+MODE_NO_CSYNC, /* connector doesn't 

[PATCH 2/3] drm/edid: Pull mode sync flag setup out to its own function

[Adam Jackson]

For readability, since this is about to get more complicated.

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e7547e3..be21040 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -853,6 +853,16 @@ drm_mode_do_interlace_quirk(struct drm_display_mode *mode,
mode->flags |= DRM_MODE_FLAG_INTERLACE;
 }

+static void
+drm_mode_detailed_set_sync_flags(struct detailed_pixel_timing *pt,
+unsigned int *flags)
+{
+   *flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
+   *flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+}
+
 /**
  * drm_mode_detailed - create a new mode from an EDID detailed timing section
  * @dev: DRM device (needed to create new mode)
@@ -938,10 +948,7 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
pt->misc |= DRM_EDID_PT_HSYNC_POSITIVE | 
DRM_EDID_PT_VSYNC_POSITIVE;
}

-   mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
-   mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+   drm_mode_detailed_set_sync_flags(pt, >flags);

 set_size:
mode->width_mm = pt->width_mm_lo | (pt->width_height_mm_hi & 0xf0) << 4;
-- 
1.7.7.6

[PATCH 1/3] drm/edid: Be stricter about stereo mode rejection

[Adam Jackson]

Either bit 5 or 6 of that byte may be set in a stereo mode.

E-EDID v1.4, Table 3.22

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c |5 +++--
 include/drm/drm_edid.h |2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index eb92fe2..e7547e3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -883,10 +883,11 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
if (hactive < 64 || vactive < 64)
return NULL;

-   if (pt->misc & DRM_EDID_PT_STEREO) {
-   printk(KERN_WARNING "stereo mode not supported\n");
+   if (pt->misc & DRM_EDID_PT_STEREO_MASK) {
+   DRM_DEBUG_KMS(KERN_WARNING "stereo modes not supported\n");
return NULL;
}
+
if (!(pt->misc & DRM_EDID_PT_SEPARATE_SYNC)) {
printk(KERN_WARNING "composite sync not supported\n");
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 0cac551..6350ea0 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -56,7 +56,7 @@ struct std_timing {
 #define DRM_EDID_PT_HSYNC_POSITIVE (1 << 1)
 #define DRM_EDID_PT_VSYNC_POSITIVE (1 << 2)
 #define DRM_EDID_PT_SEPARATE_SYNC  (3 << 3)
-#define DRM_EDID_PT_STEREO (1 << 5)
+#define DRM_EDID_PT_STEREO_MASK(3 << 5)
 #define DRM_EDID_PT_INTERLACED (1 << 7)

 /* If detailed data is pixel timing */
-- 
1.7.7.6

[PATCH v3] scatterlist: add sg_alloc_table_from_pages function

[Tomasz Stanislawski]

On 05/22/2012 10:10 PM, Andrew Morton wrote:
> On Mon, 21 May 2012 16:01:50 +0200
> Tomasz Stanislawski  wrote:
> 
 +int sg_alloc_table_from_pages(struct sg_table *sgt,
 +  struct page **pages, unsigned int n_pages,
 +  unsigned long offset, unsigned long size,
 +  gfp_t gfp_mask)
>>>
>>> I guess a 32-bit n_pages is OK.  A 16TB IO seems enough ;)
>>>
>>
>> Do you think that 'unsigned long' for offset is too big?
>>
>> Ad n_pages. Assuming that Moore's law holds it will take
>> circa 25 years before the limit of 16 TB is reached :) for
>> high-end scatterlist operations.
>> Or I can change the type of n_pages to 'unsigned long' now at
>> no cost :).
> 
> By then it will be Someone Else's Problem ;)
> 

Ok. So let's keep to 'unsigned int n_pages'.

 +{
 +  unsigned int chunks;
 +  unsigned int i;
>>>
>>> erk, please choose a different name for this.  When a C programmer sees
>>> "i", he very much assumes it has type "int".  Making it unsigned causes
>>> surprise.
>>>
>>> And don't rename it to "u"!  Let's give it a nice meaningful name.  pageno?
>>>
>>
>> The problem is that 'i' is  a natural name for a loop counter.
> 
> It's also the natural name for an integer.  If a C programmer sees "i",
> he thinks "int".  It's a Fortran thing ;)
> 
>> AFAIK, in the kernel code developers try to avoid Hungarian notation.
>> A name of a variable should reflect its purpose, not its type.
>> I can change the name of 'i' to 'pageno' and 'j' to 'pageno2' (?)
>> but I think it will make the code less reliable.
> 
> Well, one could do something radical such as using "p".
> 
> 

I can not change the type to 'int' due to 'signed vs unsigned' comparisons
in the loop condition.
What do you think about changing the names 'i' -> 'p' and 'j' -> 'q'?

Regards,
Tomasz Stanislawski

> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: mailto:"dont at kvack.org"> email at kvack.org 
> 

psb_gfx removal

[Greg KH]

On Tue, Jun 05, 2012 at 03:01:06PM +0200, Jan Engelhardt wrote:
> [fixed up gregkh's address]
> 
> Hi,
> 
> 
> I have here a "Wortmann AG terra Pad 1051", which has a GMA500-like 
> device (PCI ID 8086:4102). Using Linux 3.1.x (openSUSE 12.1's default), 
> loading psb_gfx.ko crashed the machine. I therefore tried Linux 3.4.0,
> where this crash does not occur thankfully.
> 
> According to your commit b7cdd9e6323af368e26121c5b791eddc78e79fea, 
> GMA500 is now available through the DRM tree. I take it you mean 
> kernel/drivers/gpu/drm/gma500/gma500_gfx.ko by that. However, 
> gma500_gfx.ko does not provide support for 8086:4102, i.e. modinfo does 
> not show the alias.
> 
> So, am I correct in the assumption that the 4102 code never really 
> worked, and deletion of psb_gfx was therefore ok without having 4102 
> support in gma500_gfx?

I have no idea at all, that would be up to Alan to answer, not me.

greg k-h

[PATCH] drm: Remove unused fields from drm_display_mode

[Adam Jackson]

% size drivers/gpu/drm/drm.o*
   textdata bss dec hex filename
 1873718299 336  196006   2fda6 drivers/gpu/drm/drm.o
 1912518299 336  199886   30cce drivers/gpu/drm/drm.o.orig

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_crtc.c|3 +--
 drivers/gpu/drm/drm_crtc_helper.c |2 --
 drivers/gpu/drm/drm_edid.c|2 +-
 drivers/gpu/drm/drm_fb_helper.c   |2 +-
 drivers/gpu/drm/drm_modes.c   |   16 +++-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |1 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |4 ++--
 drivers/gpu/drm/gma500/psb_drv.c  |1 -
 drivers/gpu/drm/i2c/ch7006_mode.c |1 -
 drivers/gpu/drm/nouveau/nouveau_connector.c   |5 ++---
 drivers/gpu/drm/nouveau/nv04_crtc.c   |3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |2 --
 include/drm/drm_crtc.h|   10 +-
 14 files changed, 15 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..f367dc9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1080,7 +1080,7 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
out->vsync_end = in->vsync_end;
out->vtotal = in->vtotal;
out->vscan = in->vscan;
-   out->vrefresh = in->vrefresh;
+   out->vrefresh = drm_mode_vrefresh(in);
out->flags = in->flags;
out->type = in->type;
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
@@ -1118,7 +1118,6 @@ static int drm_crtc_convert_umode(struct drm_display_mode 
*out,
out->vsync_end = in->vsync_end;
out->vtotal = in->vtotal;
out->vscan = in->vscan;
-   out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..089a838 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -159,8 +159,6 @@ prune:
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] probed modes :\n", connector->base.id,
drm_get_connector_name(connector));
list_for_each_entry(mode, >modes, head) {
-   mode->vrefresh = drm_mode_vrefresh(mode);
-
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
drm_mode_debug_printmodeline(mode);
}
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5ab377f..0858757 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -450,7 +450,7 @@ static u32 edid_get_quirks(struct edid *edid)
 }

 #define MODE_SIZE(m) ((m)->hdisplay * (m)->vdisplay)
-#define MODE_REFRESH_DIFF(m,r) (abs((m)->vrefresh - target_refresh))
+#define MODE_REFRESH_DIFF(m,r) (abs(drm_mode_vrefresh((m)) - target_refresh))

 /**
  * edid_fixup_preferred - set preferred modes based on quirk list
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5683b7f..4bee062 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -980,7 +980,7 @@ static struct drm_display_mode 
*drm_pick_cmdline_mode(struct drm_fb_helper_conne
continue;

if (cmdline_mode->refresh_specified) {
-   if (mode->vrefresh != cmdline_mode->refresh)
+   if (drm_mode_vrefresh(mode) != cmdline_mode->refresh)
continue;
}

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 8df4ec8..f076062 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -49,9 +49,9 @@
  */
 void drm_mode_debug_printmodeline(struct drm_display_mode *mode)
 {
-   DRM_DEBUG_KMS("Modeline %d:\"%s\" %d %d %d %d %d %d %d %d %d %d "
+   DRM_DEBUG_KMS("Modeline %d:\"%s\" %d %d %d %d %d %d %d %d %d "
"0x%x 0x%x\n",
-   mode->base.id, mode->name, mode->vrefresh, mode->clock,
+   mode->base.id, mode->name, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
mode->vdisplay, mode->vsync_start,
@@ -598,9 +598,6 @@ int drm_mode_hsync(const struct drm_display_mode *mode)
 {
unsigned int calc_val;

-   if (mode->hsync)
-   return mode->hsync;
-
if (mode->htotal < 0)
return 0;

@@ -621,8 +618,6 @@ EXPORT_SYMBOL(drm_mode_hsync);
  *
  * Return @mode's vrefresh rate in Hz or calculate it if necessary.
  *
- * FIXME: why is this needed?  shouldn't vrefresh be set already?
- *
  * RETURNS:
  * Vertical refresh rate. It will be the result of actual value plus 0.5.
  * If it is 

[PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Tomasz Stanislawski]

Hi Laurent,
Thank your for your comments.

On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
> Hi Tomasz,
> 
> Thanks for the patch.
> 
> On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
>> This patch adds the setup of sglist list for MMAP buffers.
>> It is needed for buffer exporting via DMABUF mechanism.
>>
>> Signed-off-by: Tomasz Stanislawski 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  drivers/media/video/videobuf2-dma-contig.c |   70 -
>>  1 file changed, 68 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index 52b4f59..ae656be 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>> @@ -32,6 +32,7 @@ struct vb2_dc_buf {
>>  /* MMAP related */
>>  struct vb2_vmarea_handler   handler;
>>  atomic_trefcount;
>> +struct sg_table *sgt_base;
>>
>>  /* USERPTR related */
>>  struct vm_area_struct   *vma;
>> @@ -189,14 +190,37 @@ static void vb2_dc_put(void *buf_priv)
>>  if (!atomic_dec_and_test(>refcount))
>>  return;
>>
>> +vb2_dc_release_sgtable(buf->sgt_base);
>>  dma_free_coherent(buf->dev, buf->size, buf->vaddr, buf->dma_addr);
>>  kfree(buf);
>>  }
>>
>> +static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
>> +struct page **pages, unsigned int n_pages)
>> +{
>> +unsigned int i;
>> +unsigned long pfn;
>> +struct vm_area_struct vma = {
>> +.vm_flags = VM_IO | VM_PFNMAP,
>> +.vm_mm = current->mm,
>> +};
>> +
>> +for (i = 0; i < n_pages; ++i, kaddr += PAGE_SIZE) {
> 
> The follow_pfn() kerneldoc mentions that it looks up a PFN for a user 
> address. 
> The only users I've found in the kernel sources pass a user address. Is it 
> legal to use it for kernel addresses ?
> 

It is not completely legal :). As I understand the mm code,
the follow_pfn works only for IO/PFN mappings.
This is the typical case (every case?) of mappings
created by dma_alloc_coherent.

In order to make this function work for a kernel pointer,
one has to create an artificial VMA that has IO/PFN bits on.

This solution is a hack-around for dma_get_pages (aka dma_get_sgtable).
This way the dependency on dma_get_pages was broken giving a small
hope of merging vb2 exporting.

Marek prepared a patchset 'ARM: DMA-mapping: new extensions for
buffer sharing' that adds dma buffers with no kernel mappings
and dma_get_sgtable function.

However this patchset is still in a RFC state.

I have prepared a patch that removes vb2_dc_kaddr_to_pages
and substitutes it with dma_get_pages. It will become
a part of vb2-exporter patches just after dma_get_sgtable
is merged (or at least acked by major maintainers).

>> +if (follow_pfn(, kaddr, ))
>> +break;
>> +pages[i] = pfn_to_page(pfn);
>> +}
>> +
>> +return i;
>> +}
>> +
>>  static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
>>  {
>>  struct device *dev = alloc_ctx;
>>  struct vb2_dc_buf *buf;
>> +int ret = -ENOMEM;
>> +int n_pages;
>> +struct page **pages = NULL;
>>
>>  buf = kzalloc(sizeof *buf, GFP_KERNEL);
>>  if (!buf)
>> @@ -205,10 +229,41 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
>> long size) buf->vaddr = dma_alloc_coherent(dev, size, >dma_addr,
>> GFP_KERNEL); if (!buf->vaddr) {
>>  dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
>> -kfree(buf);
>> -return ERR_PTR(-ENOMEM);
>> +goto fail_buf;
>> +}
>> +
>> +WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
>> +WARN_ON(buf->dma_addr & ~PAGE_MASK);
>> +
>> +n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
>> +
>> +pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
>> +if (!pages) {
>> +dev_err(dev, "failed to alloc page table\n");
>> +goto fail_dma;
>> +}
>> +
>> +ret = vb2_dc_kaddr_to_pages((unsigned long)buf->vaddr, pages, n_pages);
>> +if (ret < 0) {
>> +dev_err(dev, "failed to get buffer pages from DMA API\n");
>> +goto fail_pages;
>> +}
>> +if (ret != n_pages) {
>> +ret = -EFAULT;
>> +dev_err(dev, "failed to get all pages from DMA API\n");
>> +goto fail_pages;
>> +}
>> +
>> +buf->sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, size);
>> +if (IS_ERR(buf->sgt_base)) {
>> +ret = PTR_ERR(buf->sgt_base);
>> +dev_err(dev, "failed to prepare sg table\n");
>> +goto fail_pages;
>>  }
>>
>> +/* pages are no longer needed */
>> +kfree(pages);
>> +
>>  buf->dev = dev;
>>  buf->size = size;
>>
>> @@ -219,6 +274,17 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
>> long size) atomic_inc(>refcount);
>>
>>  return buf;
>> +
>> +fail_pages:
>> +

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #62672|0   |1
is obsolete||

--- Comment #16 from Alex Deucher  2012-06-06 06:26:50 PDT 
---
Created attachment 62674
  --> https://bugs.freedesktop.org/attachment.cgi?id=62674
libdrm fix

slightly improved version.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

--- Comment #15 from Alex Deucher  2012-06-06 06:14:27 PDT 
---
Created attachment 62672
  --> https://bugs.freedesktop.org/attachment.cgi?id=62672
libdrm fix

This patch should do the trick.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

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

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

--- Comment #2 from C?dric Legrand  2012-06-06 
11:44:24 UTC ---
Here is a piece of C++ code which may help in solving the bug :

///


Class Game :


Game::Game() : renderWindow(sf::VideoMode(800,600),"")
...

void Game::inGame()
{
...
testMap.createRender(this);
...
}

void Game::showSprite(sf::Sprite& sprite)
{
renderWindow.draw(sprite);
}

///
Class Map :
///

void Map::createRender(Game* parent)
{
...
parent->showSprite(tilesFiles[nbTileset]);  //tilesFiles is an sfml sprite
...
}

///

With this code, the same garbage and errors happen.

 I'm sorry for my english 

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 3/3] intel: wait render timeout implementation

[Daniel Vetter]

On Tue, Jun 05, 2012 at 03:43:07PM -0700, Ben Widawsky wrote:
> int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
> 
> This should bump the libdrm version. We're waiting for context support
> so we can do both features in one bump.
> 
> v2: don't return remaining timeout amount
> use get param and fallback for older kernels
> 
> v3: only doing getparam at init
> prototypes now have a signed input value
> 
> Cc: Chris Wilson 
> Signed-off-by: Ben Widawsky 

Let's bikeshed this some more ;-)
- I think a quick comment to say that negative timeouts result in a
  infinite wait would be nice.
- If we want to keep timeout=0 means polling, you need to add a special
  case in the fallback to check for that and call the busy ioctl instead
  (and remap the business value to the correct return value).
- iirc drmIoctl doesn't return the kernels -ERRNO value in it's retval
  (and shovels it into errno instead). I think undoing that suckiness
  would be good, so that we return -ETIME if the timer expired.

Yours, Daniel
> ---
>  intel/intel_bufmgr.h |1 +
>  intel/intel_bufmgr_gem.c |   30 ++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> index c197abc..fa6c4dd 100644
> --- a/intel/intel_bufmgr.h
> +++ b/intel/intel_bufmgr.h
> @@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr 
> *bufmgr, int crtc_id);
>  
>  int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
>  int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
> +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);
>  
>  /* drm_intel_bufmgr_fake.c */
>  drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index b776d2f..048fca7 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
>   unsigned int has_blt : 1;
>   unsigned int has_relaxed_fencing : 1;
>   unsigned int has_llc : 1;
> + unsigned int has_wait_timeout : 1;
>   unsigned int bo_reuse : 1;
>   unsigned int no_exec : 1;
>   bool fenced_relocs;
> @@ -1479,6 +1480,31 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
>  }
>  
>  /**
> + * Same as drm_intel_gem_bo_wait_rendering except a timeout parameter allows 
> the
> + * operation to give up after a certain amount of time.
> + *
> + * A 0 return value implies that the wait was successful. Otherwise some
> + * negative return value describes the error.
> + */
> +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
> +{
> + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
> + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> + struct drm_i915_gem_wait wait;
> + int ret;
> +
> + if (!bufmgr_gem->has_wait_timeout) {
> + drm_intel_gem_bo_wait_rendering(bo);
> + return 0;
> + }
> +
> + wait.bo_handle = bo_gem->gem_handle;
> + wait.timeout_ns = timeout_ns;
> + wait.flags = 0;
> + return drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_WAIT, );
> +}
> +
> +/**
>   * Sets the object to the GTT read and possibly write domain, used by the X
>   * 2D driver in the absence of kernel support to do 
> drm_intel_gem_bo_map_gtt().
>   *
> @@ -2898,6 +2924,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
>   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
>   bufmgr_gem->has_relaxed_fencing = ret == 0;
>  
> + gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
> + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
> + bufmgr_gem->has_wait_timeout = ret == 0;
> +
>   gp.param = I915_PARAM_HAS_LLC;
>   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
>   if (ret != 0) {
> -- 
> 1.7.10.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 50616] glClear occasionally taking >60ms

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

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

Lauri Kasanen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v2] DRM: add drm gem cma helper

[Sascha Hauer]

On Tue, Jun 05, 2012 at 10:54:10PM +0900, InKi Dae wrote:
> 2012/6/5 Sascha Hauer :
> > On Fri, Jun 01, 2012 at 12:29:47AM +0900, InKi Dae wrote:
> >> Hi Sascha,
> >>
> >> >> +struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> >> >> + ? ? ? ? ? ? unsigned int size)
> >> >> +{
> >> >> + ? ? struct drm_gem_cma_object *cma_obj;
> >> >> + ? ? struct drm_gem_object *gem_obj;
> >> >> + ? ? int ret;
> >> >> +
> >> >> + ? ? size = round_up(size, PAGE_SIZE);
> >> >> +
> >> >> + ? ? cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> >> >> + ? ? if (!cma_obj)
> >> >> + ? ? ? ? ? ? return ERR_PTR(-ENOMEM);
> >> >> +
> >> >> + ? ? cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
> >> >> + ? ? ? ? ? ? ? ? ? ? _obj->paddr, GFP_KERNEL | __GFP_NOWARN);
> >>
> >> how about calling drm_gem_cma_buf_allocate() instead of
> >> dma_alloc_wirtecombine() for consistency in using dma api so its call
> >> flow would be "dma_gem_cma_buf_allocate() ->
> >> dma_alloc_writecombine()".
> >
> > What do you mean? There is no drm_gem_cma_buf_allocate() function.
> >
> 
> I mean have a pair with drm_gem_cma_buf_destroy() otherwise how about
> removing dem_gem_cma_buf_destroy() and calling dma_free_writecombine()
> directly? drm_gem_cma_buf_destroy() is just a wrapper to
> dma_free_writecombine().

Ok, then I'll remove drm_gem_cma_buf_destroy() and use
dma_free_writecombine() directly instead.


Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Hans Verkuil]

On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
> Hi Rebecca,
> 
> On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> > I have a system where the data is planar, but the kernel drivers
> > expect to get one allocation with offsets for the planes.  I can't
> > figure out how to do that with the current dma_buf implementation.  I
> > thought I could pass the same dma_buf several times and use the
> > data_offset field of the v4l2_plane struct but it looks like that's
> > only for output.  Am I missing something?  Is this supported?
> 
> data_offset is indeed for video output only at the moment, and doesn't seem 
> to 
> be used by any driver in mainline for now.

Actually, data_offset may be set by capture drivers. For output buffers it is
set by userspace, for capture buffers it is set by the driver. This data_offset
typically contains meta data.

> I can't really see a reason why data_offset couldn't be used for video 
> capture 
> devices as well.
> 
> Sanity checks are currently missing. For output devices we should check that 
> data_offset + bytesused < length in the vb2 core. For input devices the check 
> will have to be performed by drivers. Taking data_offset into account 
> automatically would also be useful. I think most of that should be possible 
> to 
> implement in the allocators.

See this proposal of how to solve this:

http://www.spinics.net/lists/linux-media/msg40376.html

Regards,

Hans

[PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
> This patch adds the setup of sglist list for MMAP buffers.
> It is needed for buffer exporting via DMABUF mechanism.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |   70 -
>  1 file changed, 68 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 52b4f59..ae656be 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -32,6 +32,7 @@ struct vb2_dc_buf {
>   /* MMAP related */
>   struct vb2_vmarea_handler   handler;
>   atomic_trefcount;
> + struct sg_table *sgt_base;
> 
>   /* USERPTR related */
>   struct vm_area_struct   *vma;
> @@ -189,14 +190,37 @@ static void vb2_dc_put(void *buf_priv)
>   if (!atomic_dec_and_test(>refcount))
>   return;
> 
> + vb2_dc_release_sgtable(buf->sgt_base);
>   dma_free_coherent(buf->dev, buf->size, buf->vaddr, buf->dma_addr);
>   kfree(buf);
>  }
> 
> +static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
> + struct page **pages, unsigned int n_pages)
> +{
> + unsigned int i;
> + unsigned long pfn;
> + struct vm_area_struct vma = {
> + .vm_flags = VM_IO | VM_PFNMAP,
> + .vm_mm = current->mm,
> + };
> +
> + for (i = 0; i < n_pages; ++i, kaddr += PAGE_SIZE) {

The follow_pfn() kerneldoc mentions that it looks up a PFN for a user address. 
The only users I've found in the kernel sources pass a user address. Is it 
legal to use it for kernel addresses ?

> + if (follow_pfn(, kaddr, ))
> + break;
> + pages[i] = pfn_to_page(pfn);
> + }
> +
> + return i;
> +}
> +
>  static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
>  {
>   struct device *dev = alloc_ctx;
>   struct vb2_dc_buf *buf;
> + int ret = -ENOMEM;
> + int n_pages;
> + struct page **pages = NULL;
> 
>   buf = kzalloc(sizeof *buf, GFP_KERNEL);
>   if (!buf)
> @@ -205,10 +229,41 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
> long size) buf->vaddr = dma_alloc_coherent(dev, size, >dma_addr,
> GFP_KERNEL); if (!buf->vaddr) {
>   dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
> - kfree(buf);
> - return ERR_PTR(-ENOMEM);
> + goto fail_buf;
> + }
> +
> + WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
> + WARN_ON(buf->dma_addr & ~PAGE_MASK);
> +
> + n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> +
> + pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
> + if (!pages) {
> + dev_err(dev, "failed to alloc page table\n");
> + goto fail_dma;
> + }
> +
> + ret = vb2_dc_kaddr_to_pages((unsigned long)buf->vaddr, pages, n_pages);
> + if (ret < 0) {
> + dev_err(dev, "failed to get buffer pages from DMA API\n");
> + goto fail_pages;
> + }
> + if (ret != n_pages) {
> + ret = -EFAULT;
> + dev_err(dev, "failed to get all pages from DMA API\n");
> + goto fail_pages;
> + }
> +
> + buf->sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, size);
> + if (IS_ERR(buf->sgt_base)) {
> + ret = PTR_ERR(buf->sgt_base);
> + dev_err(dev, "failed to prepare sg table\n");
> + goto fail_pages;
>   }
> 
> + /* pages are no longer needed */
> + kfree(pages);
> +
>   buf->dev = dev;
>   buf->size = size;
> 
> @@ -219,6 +274,17 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
> long size) atomic_inc(>refcount);
> 
>   return buf;
> +
> +fail_pages:
> + kfree(pages);
> +
> +fail_dma:

You can merge the fail_pages and fail_dma labels, as kfree(NULL) is valid.

> + dma_free_coherent(dev, size, buf->vaddr, buf->dma_addr);
> +
> +fail_buf:
> + kfree(buf);
> +
> + return ERR_PTR(ret);
>  }
> 
>  static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)

-- 
Regards,

Laurent Pinchart

[PATCH 11/12] v4l: vb2-dma-contig: use sg_alloc_table_from_pages function

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 23 May 2012 15:07:34 Tomasz Stanislawski wrote:
> This patch makes use of sg_alloc_table_from_pages to simplify
> handling of sg tables.

Would you mind moving this patch before 04/12, to avoid introducing a 
vb2_dc_pages_to_sgt() user only to remove it in this patch ? Otherwise this 
looks good.

> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |   90 +++--
>  1 file changed, 25 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 59ee81c..b5caf1d 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -32,7 +32,7 @@ struct vb2_dc_buf {
>   /* MMAP related */
>   struct vb2_vmarea_handler   handler;
>   atomic_trefcount;
> - struct sg_table *sgt_base;
> + struct sg_table sgt_base;
> 
>   /* USERPTR related */
>   struct vm_area_struct   *vma;
> @@ -45,57 +45,6 @@ struct vb2_dc_buf {
>  /*scatterlist table functions*/
>  /*/
> 
> -static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
> - unsigned int n_pages, unsigned long offset, unsigned long size)
> -{
> - struct sg_table *sgt;
> - unsigned int chunks;
> - unsigned int i;
> - unsigned int cur_page;
> - int ret;
> - struct scatterlist *s;
> -
> - sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> - if (!sgt)
> - return ERR_PTR(-ENOMEM);
> -
> - /* compute number of chunks */
> - chunks = 1;
> - for (i = 1; i < n_pages; ++i)
> - if (pages[i] != pages[i - 1] + 1)
> - ++chunks;
> -
> - ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
> - if (ret) {
> - kfree(sgt);
> - return ERR_PTR(-ENOMEM);
> - }
> -
> - /* merging chunks and putting them into the scatterlist */
> - cur_page = 0;
> - for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> - unsigned long chunk_size;
> - unsigned int j;
> -
> - for (j = cur_page + 1; j < n_pages; ++j)
> - if (pages[j] != pages[j - 1] + 1)
> - break;
> -
> - chunk_size = ((j - cur_page) << PAGE_SHIFT) - offset;
> - sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
> - size -= chunk_size;
> - offset = 0;
> - cur_page = j;
> - }
> -
> - return sgt;
> -}
> -
> -static void vb2_dc_release_sgtable(struct sg_table *sgt)
> -{
> - sg_free_table(sgt);
> - kfree(sgt);
> -}
> 
>  static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
>   void (*cb)(struct page *pg))
> @@ -190,7 +139,7 @@ static void vb2_dc_put(void *buf_priv)
>   if (!atomic_dec_and_test(>refcount))
>   return;
> 
> - vb2_dc_release_sgtable(buf->sgt_base);
> + sg_free_table(>sgt_base);
>   dma_free_coherent(buf->dev, buf->size, buf->vaddr, buf->dma_addr);
>   kfree(buf);
>  }
> @@ -254,9 +203,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
> size) goto fail_pages;
>   }
> 
> - buf->sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, size);
> - if (IS_ERR(buf->sgt_base)) {
> - ret = PTR_ERR(buf->sgt_base);
> + ret = sg_alloc_table_from_pages(>sgt_base,
> + pages, n_pages, 0, size, GFP_KERNEL);
> + if (ret) {
>   dev_err(dev, "failed to prepare sg table\n");
>   goto fail_pages;
>   }
> @@ -379,13 +328,13 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
>   attach->dir = dir;
> 
>   /* copying the buf->base_sgt to attachment */
> - ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
> + ret = sg_alloc_table(sgt, buf->sgt_base.orig_nents, GFP_KERNEL);
>   if (ret) {
>   kfree(attach);
>   return ERR_PTR(-ENOMEM);
>   }
> 
> - rd = buf->sgt_base->sgl;
> + rd = buf->sgt_base.sgl;
>   wr = sgt->sgl;
>   for (i = 0; i < sgt->orig_nents; ++i) {
>   sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
> @@ -519,7 +468,8 @@ static void vb2_dc_put_userptr(void *buf_priv)
>   if (!vma_is_io(buf->vma))
>   vb2_dc_sgt_foreach_page(sgt, vb2_dc_put_dirty_page);
> 
> - vb2_dc_release_sgtable(sgt);
> + sg_free_table(sgt);
> + kfree(sgt);
>   vb2_put_vma(buf->vma);
>   kfree(buf);
>  }
> @@ -586,13 +536,20 @@ static void *vb2_dc_get_userptr(void *alloc_ctx,
> unsigned long vaddr, goto fail_vma;
>   }
> 
> - sgt = vb2_dc_pages_to_sgt(pages, n_pages, offset, size);
> - if (IS_ERR(sgt)) {
> - printk(KERN_ERR "failed to create scatterlist table\n");
> + sgt = kzalloc(sizeof 

[PATCH 02/12] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 23 May 2012 15:07:25 Tomasz Stanislawski wrote:
> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
> used by mmap and return a file descriptor on success.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 

Both the API proposal and the patch look good to me. I'll ack this along with 
the update to the V4L2 documentation ;-)

> ---
>  drivers/media/video/v4l2-compat-ioctl32.c |1 +
>  drivers/media/video/v4l2-dev.c|1 +
>  drivers/media/video/v4l2-ioctl.c  |6 ++
>  include/linux/videodev2.h |   26 ++
> include/media/v4l2-ioctl.h|2 ++
>  5 files changed, 36 insertions(+)
> 
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> b/drivers/media/video/v4l2-compat-ioctl32.c index 5327ad3..45159d9 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
> cmd, unsigned long arg) case VIDIOC_S_FBUF32:
>   case VIDIOC_OVERLAY32:
>   case VIDIOC_QBUF32:
> + case VIDIOC_EXPBUF:
>   case VIDIOC_DQBUF32:
>   case VIDIOC_STREAMON32:
>   case VIDIOC_STREAMOFF32:
> diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
> index 5ccbd46..6bf6307 100644
> --- a/drivers/media/video/v4l2-dev.c
> +++ b/drivers/media/video/v4l2-dev.c
> @@ -597,6 +597,7 @@ static void determine_valid_ioctls(struct video_device
> *vdev) SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
>   SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
>   SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
> + SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
>   SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
>   SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay);
>   SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf);
> diff --git a/drivers/media/video/v4l2-ioctl.c
> b/drivers/media/video/v4l2-ioctl.c index 31fc2ad..a73b14e 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -212,6 +212,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
>   IOCTL_INFO(VIDIOC_S_FBUF, INFO_FL_PRIO),
>   IOCTL_INFO(VIDIOC_OVERLAY, INFO_FL_PRIO),
>   IOCTL_INFO(VIDIOC_QBUF, 0),
> + IOCTL_INFO(VIDIOC_EXPBUF, 0),
>   IOCTL_INFO(VIDIOC_DQBUF, 0),
>   IOCTL_INFO(VIDIOC_STREAMON, INFO_FL_PRIO),
>   IOCTL_INFO(VIDIOC_STREAMOFF, INFO_FL_PRIO),
> @@ -957,6 +958,11 @@ static long __video_do_ioctl(struct file *file,
>   dbgbuf(cmd, vfd, p);
>   break;
>   }
> + case VIDIOC_EXPBUF:
> + {
> + ret = ops->vidioc_expbuf(file, fh, arg);
> + break;
> + }
>   case VIDIOC_DQBUF:
>   {
>   struct v4l2_buffer *p = arg;
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 51b20f4..e8893a5 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -684,6 +684,31 @@ struct v4l2_buffer {
>  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
>  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> 
> +/**
> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> descriptor + *
> + * @fd:  file descriptor associated with DMABUF (set by driver)
> + * @mem_offset:  buffer memory offset as returned by VIDIOC_QUERYBUF in
> struct + *v4l2_buffer::m.offset (for single-plane formats) or
> + *   v4l2_plane::m.offset (for multi-planar formats)
> + * @flags:   flags for newly created file, currently only O_CLOEXEC is
> + *   supported, refer to manual of open syscall for more details
> + *
> + * Contains data used for exporting a video buffer as DMABUF file
> descriptor. + * The buffer is identified by a 'cookie' returned by
> VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> userspace). All + * reserved fields must be set to zero. The field
> reserved0 is expected to + * become a structure 'type' allowing an
> alternative layout of the structure + * content. Therefore this field
> should not be used for any other extensions. + */
> +struct v4l2_exportbuffer {
> + __u32   fd;
> + __u32   reserved0;
> + __u32   mem_offset;
> + __u32   flags;
> + __u32   reserved[12];
> +};
> +
>  /*
>   *   O V E R L A Y   P R E V I E W
>   */
> @@ -2553,6 +2578,7 @@ struct v4l2_create_buffers {
>  #define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
>  #define VIDIOC_OVERLAY_IOW('V', 14, int)
>  #define VIDIOC_QBUF  _IOWR('V', 15, struct v4l2_buffer)
> +#define VIDIOC_EXPBUF_IOWR('V', 16, struct v4l2_exportbuffer)
>  #define VIDIOC_DQBUF

[PATCH 01/12] v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call

[Laurent Pinchart]

Hi Tomasz,

On Wednesday 23 May 2012 15:07:24 Tomasz Stanislawski wrote:
> From: Marek Szyprowski 
> 
> Let mmap method to use dma_mmap_coherent call.  This patch depends on DMA
> mapping redesign patches because the usage of dma_mmap_coherent breaks
> dma-contig allocator for architectures other than ARM and AVR.
> 
> Signed-off-by: Marek Szyprowski 

Could you please squash 10/12 into this patch ? Then, for both,

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[PATCH 03/12] v4l: vb2: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 23 May 2012 15:07:26 Tomasz Stanislawski wrote:
> This patch adds extension to videobuf2-core. It allow to export a mmap

s/allow/allows/

> buffer as a file descriptor.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[PATCH] radeon: fall back to 1D tiling only with broken kernels

[alexdeuc...@gmail.com]

From: Alex Deucher 

Certain cards report the the wrong bank setup which causes
surface init to fail in the ddx and leads to no accel.
If we hit an invalid tiling parameter, just set a default
value and disable 2D tiling.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Signed-off-by: Alex Deucher 
---
 radeon/radeon_surface.c |   28 +---
 1 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index a7b488b..adf209d 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -206,7 +206,9 @@ static int r6_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man->hw_info.num_pipes = 8;
 break;
 default:
-return -EINVAL;
+surf_man->hw_info.num_pipes = 8;
+surf_man->hw_info.allow_2d = 0;
+break;
 }

 switch ((tiling_config & 0x30) >> 4) {
@@ -217,7 +219,9 @@ static int r6_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man->hw_info.num_banks = 8;
 break;
 default:
-return -EINVAL;
+surf_man->hw_info.num_banks = 8;
+surf_man->hw_info.allow_2d = 0;
+break;
 }

 switch ((tiling_config & 0xc0) >> 6) {
@@ -228,7 +232,9 @@ static int r6_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man->hw_info.group_bytes = 512;
 break;
 default:
-return -EINVAL;
+surf_man->hw_info.group_bytes = 256;
+surf_man->hw_info.allow_2d = 0;
+break;
 }
 return 0;
 }
@@ -458,7 +464,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man->hw_info.num_pipes = 8;
 break;
 default:
-return -EINVAL;
+surf_man->hw_info.num_pipes = 8;
+surf_man->hw_info.allow_2d = 0;
+break;
 }

 switch ((tiling_config & 0xf0) >> 4) {
@@ -472,7 +480,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man->hw_info.num_banks = 16;
 break;
 default:
-return -EINVAL;
+surf_man->hw_info.num_banks = 8;
+surf_man->hw_info.allow_2d = 0;
+break;
 }

 switch ((tiling_config & 0xf00) >> 8) {
@@ -483,7 +493,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man->hw_info.group_bytes = 512;
 break;
 default:
-return -EINVAL;
+surf_man->hw_info.group_bytes = 256;
+surf_man->hw_info.allow_2d = 0;
+break;
 }

 switch ((tiling_config & 0xf000) >> 12) {
@@ -497,7 +509,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man->hw_info.row_size = 4096;
 break;
 default:
-return -EINVAL;
+surf_man->hw_info.row_size = 4096;
+surf_man->hw_info.allow_2d = 0;
+break;
 }
 return 0;
 }
-- 
1.7.7.5

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

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

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

--- Comment #61 from Christian K?nig  2012-06-06 
02:15:10 PDT ---
Please also try this patch:
http://lists.freedesktop.org/archives/dri-devel/2012-June/023735.html

It doesn't fix anything rendering related, but instead fixes a deadlock
introduced with the vm patch It isn't the complete solution of the problem it
might still be an improvement.

Christian.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 50616] glClear occasionally taking >60ms

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

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

--- Comment #6 from Michel D?nzer  2012-06-06 02:13:30 
PDT ---
(In reply to comment #5)
> I suppose this means the card is just that slow?

It means the time is spent for the actual rendering, not just for the clears.
Maybe you can narrow it down further, e.g. by sprinkling glFinish() calls
across more places.

You might get better performance out of the card with a current 3.5-rc kernel
thanks to better tiling setup, but it is a lower end card, so I wouldn't expect
any miracles. :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

--- Comment #14 from Michel D?nzer  2012-06-06 01:37:53 
PDT ---
Could libdrm_radeon also be made to deal gracefully with broken kernels?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Erik Gilling]

On Wed, Jun 6, 2012 at 6:33 AM, John Reitan  wrote:
>> But maybe instead of inventing something new, we can just use 'struct
>> kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?
>> ?If the user needs some extra args they can embed 'struct
>> kthread_work' in their own struct and use container_of() magic in the
>> cb.
>>
>> Plus this is a natural fit if you want to dispatch callbacks instead
>> on a kthread_worker, which seems like it would simplify a few things
>> when it comes to deadlock avoidance.. ie., not resource deadlock
>> avoidance, but dispatching callbacks when some lock is held.
>
> That sounds like a better approach.
> Will make a cleaner API, will look into it.

When Tom visited us for android graphics camp in the fall he argued
that there were cases where we would want to avoid an extra schedule.
Consider the case where the GPU is waiting for a render buffer that
the display controller is using.  If that render can be kicked off w/o
acquiring locks, the display's vsync IRQ handler can call release,
which in turn calls the GPU callback, which in turn kicks off the
render very quickly w/o having to leave IRQ context.

One way around the locking issue with callbacks/async wait is to have
async wait return a value to indicate that the resource has been
acquired instead of calling the callback.  This is the approach I
chose in our sync framework.

-Erik

[Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Laurent Pinchart]

Hi Rebecca,

On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> I have a system where the data is planar, but the kernel drivers
> expect to get one allocation with offsets for the planes.  I can't
> figure out how to do that with the current dma_buf implementation.  I
> thought I could pass the same dma_buf several times and use the
> data_offset field of the v4l2_plane struct but it looks like that's
> only for output.  Am I missing something?  Is this supported?

data_offset is indeed for video output only at the moment, and doesn't seem to 
be used by any driver in mainline for now.

I can't really see a reason why data_offset couldn't be used for video capture 
devices as well.

Sanity checks are currently missing. For output devices we should check that 
data_offset + bytesused < length in the vb2 core. For input devices the check 
will have to be performed by drivers. Taking data_offset into account 
automatically would also be useful. I think most of that should be possible to 
implement in the allocators.

-- 
Regards,

Laurent Pinchart

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

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

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

--- Comment #60 from Alexandre Demers  
2012-06-05 19:20:47 PDT ---
Created attachment 62619
  --> https://bugs.freedesktop.org/attachment.cgi?id=62619
snippet when gnome-shell is able to fall bak on its feet

snippet when gnome-shell is able to fall bak on its feet. Should be used with
the last dmesg submitted.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

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

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

--- Comment #59 from Alexandre Demers  
2012-06-05 19:19:18 PDT ---
Created attachment 62618
  --> https://bugs.freedesktop.org/attachment.cgi?id=62618
dmesg related to the xsession-error file

This dmesg happened with the next attachment: xsession-error.txt

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: psb_gfx removal

[Greg KH]

On Tue, Jun 05, 2012 at 03:01:06PM +0200, Jan Engelhardt wrote:
 [fixed up gregkh's address]
 
 Hi,
 
 
 I have here a Wortmann AG terra Pad 1051, which has a GMA500-like 
 device (PCI ID 8086:4102). Using Linux 3.1.x (openSUSE 12.1's default), 
 loading psb_gfx.ko crashed the machine. I therefore tried Linux 3.4.0,
 where this crash does not occur thankfully.
 
 According to your commit b7cdd9e6323af368e26121c5b791eddc78e79fea, 
 GMA500 is now available through the DRM tree. I take it you mean 
 kernel/drivers/gpu/drm/gma500/gma500_gfx.ko by that. However, 
 gma500_gfx.ko does not provide support for 8086:4102, i.e. modinfo does 
 not show the alias.
 
 So, am I correct in the assumption that the 4102 code never really 
 worked, and deletion of psb_gfx was therefore ok without having 4102 
 support in gma500_gfx?

I have no idea at all, that would be up to Alan to answer, not me.

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

Re: [PATCH 03/12] v4l: vb2: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 23 May 2012 15:07:26 Tomasz Stanislawski wrote:
 This patch adds extension to videobuf2-core. It allow to export a mmap

s/allow/allows/

 buffer as a file descriptor.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 01/12] v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call

[Laurent Pinchart]

Hi Tomasz,

On Wednesday 23 May 2012 15:07:24 Tomasz Stanislawski wrote:
 From: Marek Szyprowski m.szyprow...@samsung.com
 
 Let mmap method to use dma_mmap_coherent call.  This patch depends on DMA
 mapping redesign patches because the usage of dma_mmap_coherent breaks
 dma-contig allocator for architectures other than ARM and AVR.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

Could you please squash 10/12 into this patch ? Then, for both,

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 02/12] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 23 May 2012 15:07:25 Tomasz Stanislawski wrote:
 This patch adds extension to V4L2 api. It allow to export a mmap buffer as
 file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
 used by mmap and return a file descriptor on success.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Both the API proposal and the patch look good to me. I'll ack this along with 
the update to the V4L2 documentation ;-)

 ---
  drivers/media/video/v4l2-compat-ioctl32.c |1 +
  drivers/media/video/v4l2-dev.c|1 +
  drivers/media/video/v4l2-ioctl.c  |6 ++
  include/linux/videodev2.h |   26 ++
 include/media/v4l2-ioctl.h|2 ++
  5 files changed, 36 insertions(+)
 
 diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
 b/drivers/media/video/v4l2-compat-ioctl32.c index 5327ad3..45159d9 100644
 --- a/drivers/media/video/v4l2-compat-ioctl32.c
 +++ b/drivers/media/video/v4l2-compat-ioctl32.c
 @@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
 cmd, unsigned long arg) case VIDIOC_S_FBUF32:
   case VIDIOC_OVERLAY32:
   case VIDIOC_QBUF32:
 + case VIDIOC_EXPBUF:
   case VIDIOC_DQBUF32:
   case VIDIOC_STREAMON32:
   case VIDIOC_STREAMOFF32:
 diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
 index 5ccbd46..6bf6307 100644
 --- a/drivers/media/video/v4l2-dev.c
 +++ b/drivers/media/video/v4l2-dev.c
 @@ -597,6 +597,7 @@ static void determine_valid_ioctls(struct video_device
 *vdev) SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
   SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
   SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
 + SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
   SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
   SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay);
   SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf);
 diff --git a/drivers/media/video/v4l2-ioctl.c
 b/drivers/media/video/v4l2-ioctl.c index 31fc2ad..a73b14e 100644
 --- a/drivers/media/video/v4l2-ioctl.c
 +++ b/drivers/media/video/v4l2-ioctl.c
 @@ -212,6 +212,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
   IOCTL_INFO(VIDIOC_S_FBUF, INFO_FL_PRIO),
   IOCTL_INFO(VIDIOC_OVERLAY, INFO_FL_PRIO),
   IOCTL_INFO(VIDIOC_QBUF, 0),
 + IOCTL_INFO(VIDIOC_EXPBUF, 0),
   IOCTL_INFO(VIDIOC_DQBUF, 0),
   IOCTL_INFO(VIDIOC_STREAMON, INFO_FL_PRIO),
   IOCTL_INFO(VIDIOC_STREAMOFF, INFO_FL_PRIO),
 @@ -957,6 +958,11 @@ static long __video_do_ioctl(struct file *file,
   dbgbuf(cmd, vfd, p);
   break;
   }
 + case VIDIOC_EXPBUF:
 + {
 + ret = ops-vidioc_expbuf(file, fh, arg);
 + break;
 + }
   case VIDIOC_DQBUF:
   {
   struct v4l2_buffer *p = arg;
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index 51b20f4..e8893a5 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -684,6 +684,31 @@ struct v4l2_buffer {
  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
 
 +/**
 + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
 descriptor + *
 + * @fd:  file descriptor associated with DMABUF (set by driver)
 + * @mem_offset:  buffer memory offset as returned by VIDIOC_QUERYBUF in
 struct + *v4l2_buffer::m.offset (for single-plane formats) or
 + *   v4l2_plane::m.offset (for multi-planar formats)
 + * @flags:   flags for newly created file, currently only O_CLOEXEC is
 + *   supported, refer to manual of open syscall for more details
 + *
 + * Contains data used for exporting a video buffer as DMABUF file
 descriptor. + * The buffer is identified by a 'cookie' returned by
 VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
 userspace). All + * reserved fields must be set to zero. The field
 reserved0 is expected to + * become a structure 'type' allowing an
 alternative layout of the structure + * content. Therefore this field
 should not be used for any other extensions. + */
 +struct v4l2_exportbuffer {
 + __u32   fd;
 + __u32   reserved0;
 + __u32   mem_offset;
 + __u32   flags;
 + __u32   reserved[12];
 +};
 +
  /*
   *   O V E R L A Y   P R E V I E W
   */
 @@ -2553,6 +2578,7 @@ struct v4l2_create_buffers {
  #define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
  #define VIDIOC_OVERLAY_IOW('V', 14, int)
  #define VIDIOC_QBUF  _IOWR('V', 15, struct v4l2_buffer)
 +#define VIDIOC_EXPBUF_IOWR('V', 16, struct v4l2_exportbuffer)
  #define VIDIOC_DQBUF _IOWR('V', 17, struct v4l2_buffer)
  #define 

Re: [PATCH 11/12] v4l: vb2-dma-contig: use sg_alloc_table_from_pages function

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Wednesday 23 May 2012 15:07:34 Tomasz Stanislawski wrote:
 This patch makes use of sg_alloc_table_from_pages to simplify
 handling of sg tables.

Would you mind moving this patch before 04/12, to avoid introducing a 
vb2_dc_pages_to_sgt() user only to remove it in this patch ? Otherwise this 
looks good.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/video/videobuf2-dma-contig.c |   90 +++--
  1 file changed, 25 insertions(+), 65 deletions(-)
 
 diff --git a/drivers/media/video/videobuf2-dma-contig.c
 b/drivers/media/video/videobuf2-dma-contig.c index 59ee81c..b5caf1d 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
 @@ -32,7 +32,7 @@ struct vb2_dc_buf {
   /* MMAP related */
   struct vb2_vmarea_handler   handler;
   atomic_trefcount;
 - struct sg_table *sgt_base;
 + struct sg_table sgt_base;
 
   /* USERPTR related */
   struct vm_area_struct   *vma;
 @@ -45,57 +45,6 @@ struct vb2_dc_buf {
  /*scatterlist table functions*/
  /*/
 
 -static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
 - unsigned int n_pages, unsigned long offset, unsigned long size)
 -{
 - struct sg_table *sgt;
 - unsigned int chunks;
 - unsigned int i;
 - unsigned int cur_page;
 - int ret;
 - struct scatterlist *s;
 -
 - sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
 - if (!sgt)
 - return ERR_PTR(-ENOMEM);
 -
 - /* compute number of chunks */
 - chunks = 1;
 - for (i = 1; i  n_pages; ++i)
 - if (pages[i] != pages[i - 1] + 1)
 - ++chunks;
 -
 - ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
 - if (ret) {
 - kfree(sgt);
 - return ERR_PTR(-ENOMEM);
 - }
 -
 - /* merging chunks and putting them into the scatterlist */
 - cur_page = 0;
 - for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
 - unsigned long chunk_size;
 - unsigned int j;
 -
 - for (j = cur_page + 1; j  n_pages; ++j)
 - if (pages[j] != pages[j - 1] + 1)
 - break;
 -
 - chunk_size = ((j - cur_page)  PAGE_SHIFT) - offset;
 - sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
 - size -= chunk_size;
 - offset = 0;
 - cur_page = j;
 - }
 -
 - return sgt;
 -}
 -
 -static void vb2_dc_release_sgtable(struct sg_table *sgt)
 -{
 - sg_free_table(sgt);
 - kfree(sgt);
 -}
 
  static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
   void (*cb)(struct page *pg))
 @@ -190,7 +139,7 @@ static void vb2_dc_put(void *buf_priv)
   if (!atomic_dec_and_test(buf-refcount))
   return;
 
 - vb2_dc_release_sgtable(buf-sgt_base);
 + sg_free_table(buf-sgt_base);
   dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
   kfree(buf);
  }
 @@ -254,9 +203,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
 size) goto fail_pages;
   }
 
 - buf-sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, size);
 - if (IS_ERR(buf-sgt_base)) {
 - ret = PTR_ERR(buf-sgt_base);
 + ret = sg_alloc_table_from_pages(buf-sgt_base,
 + pages, n_pages, 0, size, GFP_KERNEL);
 + if (ret) {
   dev_err(dev, failed to prepare sg table\n);
   goto fail_pages;
   }
 @@ -379,13 +328,13 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
   attach-dir = dir;
 
   /* copying the buf-base_sgt to attachment */
 - ret = sg_alloc_table(sgt, buf-sgt_base-orig_nents, GFP_KERNEL);
 + ret = sg_alloc_table(sgt, buf-sgt_base.orig_nents, GFP_KERNEL);
   if (ret) {
   kfree(attach);
   return ERR_PTR(-ENOMEM);
   }
 
 - rd = buf-sgt_base-sgl;
 + rd = buf-sgt_base.sgl;
   wr = sgt-sgl;
   for (i = 0; i  sgt-orig_nents; ++i) {
   sg_set_page(wr, sg_page(rd), rd-length, rd-offset);
 @@ -519,7 +468,8 @@ static void vb2_dc_put_userptr(void *buf_priv)
   if (!vma_is_io(buf-vma))
   vb2_dc_sgt_foreach_page(sgt, vb2_dc_put_dirty_page);
 
 - vb2_dc_release_sgtable(sgt);
 + sg_free_table(sgt);
 + kfree(sgt);
   vb2_put_vma(buf-vma);
   kfree(buf);
  }
 @@ -586,13 +536,20 @@ static void *vb2_dc_get_userptr(void *alloc_ctx,
 unsigned long vaddr, goto fail_vma;
   }
 
 - sgt = vb2_dc_pages_to_sgt(pages, n_pages, offset, size);
 - if (IS_ERR(sgt)) {
 - printk(KERN_ERR failed to create scatterlist table\n);
 + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
 + if (!sgt) {
 + printk(KERN_ERR failed to allocate sg table\n);

Re: [PATCH v2] DRM: add drm gem cma helper

[Sascha Hauer]

On Tue, Jun 05, 2012 at 10:54:10PM +0900, InKi Dae wrote:
 2012/6/5 Sascha Hauer s.ha...@pengutronix.de:
  On Fri, Jun 01, 2012 at 12:29:47AM +0900, InKi Dae wrote:
  Hi Sascha,
 
   +struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
   +             unsigned int size)
   +{
   +     struct drm_gem_cma_object *cma_obj;
   +     struct drm_gem_object *gem_obj;
   +     int ret;
   +
   +     size = round_up(size, PAGE_SIZE);
   +
   +     cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
   +     if (!cma_obj)
   +             return ERR_PTR(-ENOMEM);
   +
   +     cma_obj-vaddr = dma_alloc_writecombine(drm-dev, size,
   +                     cma_obj-paddr, GFP_KERNEL | __GFP_NOWARN);
 
  how about calling drm_gem_cma_buf_allocate() instead of
  dma_alloc_wirtecombine() for consistency in using dma api so its call
  flow would be dma_gem_cma_buf_allocate() -
  dma_alloc_writecombine().
 
  What do you mean? There is no drm_gem_cma_buf_allocate() function.
 
 
 I mean have a pair with drm_gem_cma_buf_destroy() otherwise how about
 removing dem_gem_cma_buf_destroy() and calling dma_free_writecombine()
 directly? drm_gem_cma_buf_destroy() is just a wrapper to
 dma_free_writecombine().

Ok, then I'll remove drm_gem_cma_buf_destroy() and use
dma_free_writecombine() directly instead.


Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

--- Comment #14 from Michel Dänzer mic...@daenzer.net 2012-06-06 01:37:53 PDT 
---
Could libdrm_radeon also be made to deal gracefully with broken kernels?

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

[Bug 50616] glClear occasionally taking 60ms

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-06-06 02:13:30 PDT 
---
(In reply to comment #5)
 I suppose this means the card is just that slow?

It means the time is spent for the actual rendering, not just for the clears.
Maybe you can narrow it down further, e.g. by sprinkling glFinish() calls
across more places.

You might get better performance out of the card with a current 3.5-rc kernel
thanks to better tiling setup, but it is a lower end card, so I wouldn't expect
any miracles. :)

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

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

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

--- Comment #61 from Christian König deathsim...@vodafone.de 2012-06-06 
02:15:10 PDT ---
Please also try this patch:
http://lists.freedesktop.org/archives/dri-devel/2012-June/023735.html

It doesn't fix anything rendering related, but instead fixes a deadlock
introduced with the vm patch It isn't the complete solution of the problem it
might still be an improvement.

Christian.

-- 
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 3/3] intel: wait render timeout implementation

[Daniel Vetter]

On Tue, Jun 05, 2012 at 03:43:07PM -0700, Ben Widawsky wrote:
 int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
 
 This should bump the libdrm version. We're waiting for context support
 so we can do both features in one bump.
 
 v2: don't return remaining timeout amount
 use get param and fallback for older kernels
 
 v3: only doing getparam at init
 prototypes now have a signed input value
 
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

Let's bikeshed this some more ;-)
- I think a quick comment to say that negative timeouts result in a
  infinite wait would be nice.
- If we want to keep timeout=0 means polling, you need to add a special
  case in the fallback to check for that and call the busy ioctl instead
  (and remap the business value to the correct return value).
- iirc drmIoctl doesn't return the kernels -ERRNO value in it's retval
  (and shovels it into errno instead). I think undoing that suckiness
  would be good, so that we return -ETIME if the timer expired.

Yours, Daniel
 ---
  intel/intel_bufmgr.h |1 +
  intel/intel_bufmgr_gem.c |   30 ++
  2 files changed, 31 insertions(+)
 
 diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
 index c197abc..fa6c4dd 100644
 --- a/intel/intel_bufmgr.h
 +++ b/intel/intel_bufmgr.h
 @@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr 
 *bufmgr, int crtc_id);
  
  int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
  int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
 +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);
  
  /* drm_intel_bufmgr_fake.c */
  drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
 diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
 index b776d2f..048fca7 100644
 --- a/intel/intel_bufmgr_gem.c
 +++ b/intel/intel_bufmgr_gem.c
 @@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
   unsigned int has_blt : 1;
   unsigned int has_relaxed_fencing : 1;
   unsigned int has_llc : 1;
 + unsigned int has_wait_timeout : 1;
   unsigned int bo_reuse : 1;
   unsigned int no_exec : 1;
   bool fenced_relocs;
 @@ -1479,6 +1480,31 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
  }
  
  /**
 + * Same as drm_intel_gem_bo_wait_rendering except a timeout parameter allows 
 the
 + * operation to give up after a certain amount of time.
 + *
 + * A 0 return value implies that the wait was successful. Otherwise some
 + * negative return value describes the error.
 + */
 +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
 +{
 + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
 + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
 + struct drm_i915_gem_wait wait;
 + int ret;
 +
 + if (!bufmgr_gem-has_wait_timeout) {
 + drm_intel_gem_bo_wait_rendering(bo);
 + return 0;
 + }
 +
 + wait.bo_handle = bo_gem-gem_handle;
 + wait.timeout_ns = timeout_ns;
 + wait.flags = 0;
 + return drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GEM_WAIT, wait);
 +}
 +
 +/**
   * Sets the object to the GTT read and possibly write domain, used by the X
   * 2D driver in the absence of kernel support to do 
 drm_intel_gem_bo_map_gtt().
   *
 @@ -2898,6 +2924,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
   ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
   bufmgr_gem-has_relaxed_fencing = ret == 0;
  
 + gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
 + ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
 + bufmgr_gem-has_wait_timeout = ret == 0;
 +
   gp.param = I915_PARAM_HAS_LLC;
   ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
   if (ret != 0) {
 -- 
 1.7.10.3
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50616] glClear occasionally taking 60ms

[bugzilla-daemon]

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

Lauri Kasanen cur...@operamail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

-- 
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 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Tomasz Stanislawski]

Hi Laurent,
Thank your for your comments.

On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
 Hi Tomasz,
 
 Thanks for the patch.
 
 On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
 This patch adds the setup of sglist list for MMAP buffers.
 It is needed for buffer exporting via DMABUF mechanism.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/video/videobuf2-dma-contig.c |   70 -
  1 file changed, 68 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/video/videobuf2-dma-contig.c
 b/drivers/media/video/videobuf2-dma-contig.c index 52b4f59..ae656be 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
 @@ -32,6 +32,7 @@ struct vb2_dc_buf {
  /* MMAP related */
  struct vb2_vmarea_handler   handler;
  atomic_trefcount;
 +struct sg_table *sgt_base;

  /* USERPTR related */
  struct vm_area_struct   *vma;
 @@ -189,14 +190,37 @@ static void vb2_dc_put(void *buf_priv)
  if (!atomic_dec_and_test(buf-refcount))
  return;

 +vb2_dc_release_sgtable(buf-sgt_base);
  dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
  kfree(buf);
  }

 +static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
 +struct page **pages, unsigned int n_pages)
 +{
 +unsigned int i;
 +unsigned long pfn;
 +struct vm_area_struct vma = {
 +.vm_flags = VM_IO | VM_PFNMAP,
 +.vm_mm = current-mm,
 +};
 +
 +for (i = 0; i  n_pages; ++i, kaddr += PAGE_SIZE) {
 
 The follow_pfn() kerneldoc mentions that it looks up a PFN for a user 
 address. 
 The only users I've found in the kernel sources pass a user address. Is it 
 legal to use it for kernel addresses ?
 

It is not completely legal :). As I understand the mm code,
the follow_pfn works only for IO/PFN mappings.
This is the typical case (every case?) of mappings
created by dma_alloc_coherent.

In order to make this function work for a kernel pointer,
one has to create an artificial VMA that has IO/PFN bits on.

This solution is a hack-around for dma_get_pages (aka dma_get_sgtable).
This way the dependency on dma_get_pages was broken giving a small
hope of merging vb2 exporting.

Marek prepared a patchset 'ARM: DMA-mapping: new extensions for
buffer sharing' that adds dma buffers with no kernel mappings
and dma_get_sgtable function.

However this patchset is still in a RFC state.

I have prepared a patch that removes vb2_dc_kaddr_to_pages
and substitutes it with dma_get_pages. It will become
a part of vb2-exporter patches just after dma_get_sgtable
is merged (or at least acked by major maintainers).

 +if (follow_pfn(vma, kaddr, pfn))
 +break;
 +pages[i] = pfn_to_page(pfn);
 +}
 +
 +return i;
 +}
 +
  static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
  {
  struct device *dev = alloc_ctx;
  struct vb2_dc_buf *buf;
 +int ret = -ENOMEM;
 +int n_pages;
 +struct page **pages = NULL;

  buf = kzalloc(sizeof *buf, GFP_KERNEL);
  if (!buf)
 @@ -205,10 +229,41 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
 long size) buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr,
 GFP_KERNEL); if (!buf-vaddr) {
  dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
 -kfree(buf);
 -return ERR_PTR(-ENOMEM);
 +goto fail_buf;
 +}
 +
 +WARN_ON((unsigned long)buf-vaddr  ~PAGE_MASK);
 +WARN_ON(buf-dma_addr  ~PAGE_MASK);
 +
 +n_pages = PAGE_ALIGN(size)  PAGE_SHIFT;
 +
 +pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
 +if (!pages) {
 +dev_err(dev, failed to alloc page table\n);
 +goto fail_dma;
 +}
 +
 +ret = vb2_dc_kaddr_to_pages((unsigned long)buf-vaddr, pages, n_pages);
 +if (ret  0) {
 +dev_err(dev, failed to get buffer pages from DMA API\n);
 +goto fail_pages;
 +}
 +if (ret != n_pages) {
 +ret = -EFAULT;
 +dev_err(dev, failed to get all pages from DMA API\n);
 +goto fail_pages;
 +}
 +
 +buf-sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, size);
 +if (IS_ERR(buf-sgt_base)) {
 +ret = PTR_ERR(buf-sgt_base);
 +dev_err(dev, failed to prepare sg table\n);
 +goto fail_pages;
  }

 +/* pages are no longer needed */
 +kfree(pages);
 +
  buf-dev = dev;
  buf-size = size;

 @@ -219,6 +274,17 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
 long size) atomic_inc(buf-refcount);

  return buf;
 +
 +fail_pages:
 +kfree(pages);
 +
 +fail_dma:
 
 You can merge the fail_pages and fail_dma labels, as kfree(NULL) is valid.
 

Yes, I can. But there are two reasons for not doing that:
- first: calling a dummy kfree introduces 

Re: [PATCH v3] scatterlist: add sg_alloc_table_from_pages function

[Tomasz Stanislawski]

On 05/22/2012 10:10 PM, Andrew Morton wrote:
 On Mon, 21 May 2012 16:01:50 +0200
 Tomasz Stanislawski t.stanisl...@samsung.com wrote:
 
 +int sg_alloc_table_from_pages(struct sg_table *sgt,
 +  struct page **pages, unsigned int n_pages,
 +  unsigned long offset, unsigned long size,
 +  gfp_t gfp_mask)

 I guess a 32-bit n_pages is OK.  A 16TB IO seems enough ;)


 Do you think that 'unsigned long' for offset is too big?

 Ad n_pages. Assuming that Moore's law holds it will take
 circa 25 years before the limit of 16 TB is reached :) for
 high-end scatterlist operations.
 Or I can change the type of n_pages to 'unsigned long' now at
 no cost :).
 
 By then it will be Someone Else's Problem ;)
 

Ok. So let's keep to 'unsigned int n_pages'.

 +{
 +  unsigned int chunks;
 +  unsigned int i;

 erk, please choose a different name for this.  When a C programmer sees
 i, he very much assumes it has type int.  Making it unsigned causes
 surprise.

 And don't rename it to u!  Let's give it a nice meaningful name.  pageno?


 The problem is that 'i' is  a natural name for a loop counter.
 
 It's also the natural name for an integer.  If a C programmer sees i,
 he thinks int.  It's a Fortran thing ;)
 
 AFAIK, in the kernel code developers try to avoid Hungarian notation.
 A name of a variable should reflect its purpose, not its type.
 I can change the name of 'i' to 'pageno' and 'j' to 'pageno2' (?)
 but I think it will make the code less reliable.
 
 Well, one could do something radical such as using p.
 
 

I can not change the type to 'int' due to 'signed vs unsigned' comparisons
in the loop condition.
What do you think about changing the names 'i' - 'p' and 'j' - 'q'?

Regards,
Tomasz Stanislawski

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
 Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
 

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

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

--- Comment #15 from Alex Deucher ag...@yahoo.com 2012-06-06 06:14:27 PDT ---
Created attachment 62672
  -- https://bugs.freedesktop.org/attachment.cgi?id=62672
libdrm fix

This patch should do the trick.

-- 
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] radeon: fall back to 1D tiling only with broken kernels

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Certain cards report the the wrong bank setup which causes
surface init to fail in the ddx and leads to no accel.
If we hit an invalid tiling parameter, just set a default
value and disable 2D tiling.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 radeon/radeon_surface.c |   28 +---
 1 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index a7b488b..adf209d 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -206,7 +206,9 @@ static int r6_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man-hw_info.num_pipes = 8;
 break;
 default:
-return -EINVAL;
+surf_man-hw_info.num_pipes = 8;
+surf_man-hw_info.allow_2d = 0;
+break;
 }
 
 switch ((tiling_config  0x30)  4) {
@@ -217,7 +219,9 @@ static int r6_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man-hw_info.num_banks = 8;
 break;
 default:
-return -EINVAL;
+surf_man-hw_info.num_banks = 8;
+surf_man-hw_info.allow_2d = 0;
+break;
 }
 
 switch ((tiling_config  0xc0)  6) {
@@ -228,7 +232,9 @@ static int r6_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man-hw_info.group_bytes = 512;
 break;
 default:
-return -EINVAL;
+surf_man-hw_info.group_bytes = 256;
+surf_man-hw_info.allow_2d = 0;
+break;
 }
 return 0;
 }
@@ -458,7 +464,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man-hw_info.num_pipes = 8;
 break;
 default:
-return -EINVAL;
+surf_man-hw_info.num_pipes = 8;
+surf_man-hw_info.allow_2d = 0;
+break;
 }
 
 switch ((tiling_config  0xf0)  4) {
@@ -472,7 +480,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man-hw_info.num_banks = 16;
 break;
 default:
-return -EINVAL;
+surf_man-hw_info.num_banks = 8;
+surf_man-hw_info.allow_2d = 0;
+break;
 }
 
 switch ((tiling_config  0xf00)  8) {
@@ -483,7 +493,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man-hw_info.group_bytes = 512;
 break;
 default:
-return -EINVAL;
+surf_man-hw_info.group_bytes = 256;
+surf_man-hw_info.allow_2d = 0;
+break;
 }
 
 switch ((tiling_config  0xf000)  12) {
@@ -497,7 +509,9 @@ static int eg_init_hw_info(struct radeon_surface_manager 
*surf_man)
 surf_man-hw_info.row_size = 4096;
 break;
 default:
-return -EINVAL;
+surf_man-hw_info.row_size = 4096;
+surf_man-hw_info.allow_2d = 0;
+break;
 }
 return 0;
 }
-- 
1.7.7.5

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

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #62672|0   |1
is obsolete||

--- Comment #16 from Alex Deucher ag...@yahoo.com 2012-06-06 06:26:50 PDT ---
Created attachment 62674
  -- https://bugs.freedesktop.org/attachment.cgi?id=62674
libdrm fix

slightly improved version.

-- 
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] drm: Remove unused fields from drm_display_mode

[Adam Jackson]

% size drivers/gpu/drm/drm.o*
   textdata bss dec hex filename
 1873718299 336  196006   2fda6 drivers/gpu/drm/drm.o
 1912518299 336  199886   30cce drivers/gpu/drm/drm.o.orig

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_crtc.c|3 +--
 drivers/gpu/drm/drm_crtc_helper.c |2 --
 drivers/gpu/drm/drm_edid.c|2 +-
 drivers/gpu/drm/drm_fb_helper.c   |2 +-
 drivers/gpu/drm/drm_modes.c   |   16 +++-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |1 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |4 ++--
 drivers/gpu/drm/gma500/psb_drv.c  |1 -
 drivers/gpu/drm/i2c/ch7006_mode.c |1 -
 drivers/gpu/drm/nouveau/nouveau_connector.c   |5 ++---
 drivers/gpu/drm/nouveau/nv04_crtc.c   |3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |2 --
 include/drm/drm_crtc.h|   10 +-
 14 files changed, 15 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..f367dc9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1080,7 +1080,7 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
out-vsync_end = in-vsync_end;
out-vtotal = in-vtotal;
out-vscan = in-vscan;
-   out-vrefresh = in-vrefresh;
+   out-vrefresh = drm_mode_vrefresh(in);
out-flags = in-flags;
out-type = in-type;
strncpy(out-name, in-name, DRM_DISPLAY_MODE_LEN);
@@ -1118,7 +1118,6 @@ static int drm_crtc_convert_umode(struct drm_display_mode 
*out,
out-vsync_end = in-vsync_end;
out-vtotal = in-vtotal;
out-vscan = in-vscan;
-   out-vrefresh = in-vrefresh;
out-flags = in-flags;
out-type = in-type;
strncpy(out-name, in-name, DRM_DISPLAY_MODE_LEN);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..089a838 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -159,8 +159,6 @@ prune:
DRM_DEBUG_KMS([CONNECTOR:%d:%s] probed modes :\n, connector-base.id,
drm_get_connector_name(connector));
list_for_each_entry(mode, connector-modes, head) {
-   mode-vrefresh = drm_mode_vrefresh(mode);
-
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
drm_mode_debug_printmodeline(mode);
}
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5ab377f..0858757 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -450,7 +450,7 @@ static u32 edid_get_quirks(struct edid *edid)
 }
 
 #define MODE_SIZE(m) ((m)-hdisplay * (m)-vdisplay)
-#define MODE_REFRESH_DIFF(m,r) (abs((m)-vrefresh - target_refresh))
+#define MODE_REFRESH_DIFF(m,r) (abs(drm_mode_vrefresh((m)) - target_refresh))
 
 /**
  * edid_fixup_preferred - set preferred modes based on quirk list
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5683b7f..4bee062 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -980,7 +980,7 @@ static struct drm_display_mode 
*drm_pick_cmdline_mode(struct drm_fb_helper_conne
continue;
 
if (cmdline_mode-refresh_specified) {
-   if (mode-vrefresh != cmdline_mode-refresh)
+   if (drm_mode_vrefresh(mode) != cmdline_mode-refresh)
continue;
}
 
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 8df4ec8..f076062 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -49,9 +49,9 @@
  */
 void drm_mode_debug_printmodeline(struct drm_display_mode *mode)
 {
-   DRM_DEBUG_KMS(Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d 
+   DRM_DEBUG_KMS(Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d 
0x%x 0x%x\n,
-   mode-base.id, mode-name, mode-vrefresh, mode-clock,
+   mode-base.id, mode-name, mode-clock,
mode-hdisplay, mode-hsync_start,
mode-hsync_end, mode-htotal,
mode-vdisplay, mode-vsync_start,
@@ -598,9 +598,6 @@ int drm_mode_hsync(const struct drm_display_mode *mode)
 {
unsigned int calc_val;
 
-   if (mode-hsync)
-   return mode-hsync;
-
if (mode-htotal  0)
return 0;
 
@@ -621,8 +618,6 @@ EXPORT_SYMBOL(drm_mode_hsync);
  *
  * Return @mode's vrefresh rate in Hz or calculate it if necessary.
  *
- * FIXME: why is this needed?  shouldn't vrefresh be set already?
- *
  * RETURNS:
  * Vertical refresh rate. It will be the result of actual value plus 0.5.
  * If it is 70.288, it will return 70Hz.
@@ -633,9 

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

[bugzilla-daemon]

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

--- Comment #2 from Cédric Legrand legrand.cedric...@gmail.com 2012-06-06 
11:44:24 UTC ---
Here is a piece of C++ code which may help in solving the bug :

///


Class Game :


Game::Game() : renderWindow(sf::VideoMode(800,600),)
...

void Game::inGame()
{
...
testMap.createRender(this);
...
}

void Game::showSprite(sf::Sprite sprite)
{
renderWindow.draw(sprite);
}

///
Class Map :
///

void Map::createRender(Game* parent)
{
...
parent-showSprite(tilesFiles[nbTileset]);  //tilesFiles is an sfml sprite
...
}

///

With this code, the same garbage and errors happen.

 I'm sorry for my english 

-- 
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/3] drm/edid: Be stricter about stereo mode rejection

[Adam Jackson]

Either bit 5 or 6 of that byte may be set in a stereo mode.

E-EDID v1.4, Table 3.22

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_edid.c |5 +++--
 include/drm/drm_edid.h |2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index eb92fe2..e7547e3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -883,10 +883,11 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
if (hactive  64 || vactive  64)
return NULL;
 
-   if (pt-misc  DRM_EDID_PT_STEREO) {
-   printk(KERN_WARNING stereo mode not supported\n);
+   if (pt-misc  DRM_EDID_PT_STEREO_MASK) {
+   DRM_DEBUG_KMS(KERN_WARNING stereo modes not supported\n);
return NULL;
}
+
if (!(pt-misc  DRM_EDID_PT_SEPARATE_SYNC)) {
printk(KERN_WARNING composite sync not supported\n);
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 0cac551..6350ea0 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -56,7 +56,7 @@ struct std_timing {
 #define DRM_EDID_PT_HSYNC_POSITIVE (1  1)
 #define DRM_EDID_PT_VSYNC_POSITIVE (1  2)
 #define DRM_EDID_PT_SEPARATE_SYNC  (3  3)
-#define DRM_EDID_PT_STEREO (1  5)
+#define DRM_EDID_PT_STEREO_MASK(3  5)
 #define DRM_EDID_PT_INTERLACED (1  7)
 
 /* If detailed data is pixel timing */
-- 
1.7.7.6

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

[PATCH 2/3] drm/edid: Pull mode sync flag setup out to its own function

[Adam Jackson]

For readability, since this is about to get more complicated.

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_edid.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e7547e3..be21040 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -853,6 +853,16 @@ drm_mode_do_interlace_quirk(struct drm_display_mode *mode,
mode-flags |= DRM_MODE_FLAG_INTERLACE;
 }
 
+static void
+drm_mode_detailed_set_sync_flags(struct detailed_pixel_timing *pt,
+unsigned int *flags)
+{
+   *flags |= (pt-misc  DRM_EDID_PT_HSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
+   *flags |= (pt-misc  DRM_EDID_PT_VSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+}
+
 /**
  * drm_mode_detailed - create a new mode from an EDID detailed timing section
  * @dev: DRM device (needed to create new mode)
@@ -938,10 +948,7 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
pt-misc |= DRM_EDID_PT_HSYNC_POSITIVE | 
DRM_EDID_PT_VSYNC_POSITIVE;
}
 
-   mode-flags |= (pt-misc  DRM_EDID_PT_HSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
-   mode-flags |= (pt-misc  DRM_EDID_PT_VSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+   drm_mode_detailed_set_sync_flags(pt, mode-flags);
 
 set_size:
mode-width_mm = pt-width_mm_lo | (pt-width_height_mm_hi  0xf0)  4;
-- 
1.7.7.6

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

[PATCH 3/3] drm/edid: Add csync parsing

[Adam Jackson]

Just assume saying this is csync is enough for whatever the output
type is.  The xfree86 mode flags distinguish between positive and
negative csync, but EDID doesn't encode that.

No connector types set csync_allowed yet, so this is a no-op besides
getting the message to shut up.

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_crtc.c|2 +-
 drivers/gpu/drm/drm_crtc_helper.c |5 +
 drivers/gpu/drm/drm_edid.c|   29 +
 include/drm/drm_crtc.h|2 ++
 include/drm/drm_edid.h|   15 ++-
 include/drm/drm_mode.h|4 
 6 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..265efe8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1081,7 +1081,7 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
out-vtotal = in-vtotal;
out-vscan = in-vscan;
out-vrefresh = in-vrefresh;
-   out-flags = in-flags;
+   out-flags = in-flags  DRM_MODE_FLAG_USERSPACE_MASK;
out-type = in-type;
strncpy(out-name, in-name, DRM_DISPLAY_MODE_LEN);
out-name[DRM_DISPLAY_MODE_LEN-1] = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..d4625db 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -57,6 +57,9 @@ static void drm_mode_validate_flag(struct drm_connector 
*connector,
if ((mode-flags  DRM_MODE_FLAG_DBLSCAN) 
!(flags  DRM_MODE_FLAG_DBLSCAN))
mode-status = MODE_NO_DBLESCAN;
+   if ((mode-flags  DRM_MODE_FLAG_CSYNC) 
+   !(flags  DRM_MODE_FLAG_CSYNC))
+   mode-status = MODE_NO_CSYNC;
}
 
return;
@@ -140,6 +143,8 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
mode_flags |= DRM_MODE_FLAG_INTERLACE;
if (connector-doublescan_allowed)
mode_flags |= DRM_MODE_FLAG_DBLSCAN;
+   if (connector-csync_allowed)
+   mode_flags |= DRM_MODE_FLAG_CSYNC;
drm_mode_validate_flag(connector, mode_flags);
 
list_for_each_entry(mode, connector-modes, head) {
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index be21040..a8af442 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -857,10 +857,27 @@ static void
 drm_mode_detailed_set_sync_flags(struct detailed_pixel_timing *pt,
 unsigned int *flags)
 {
-   *flags |= (pt-misc  DRM_EDID_PT_HSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
-   *flags |= (pt-misc  DRM_EDID_PT_VSYNC_POSITIVE) ?
-   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+   switch (pt-misc  DRM_EDID_PT_SEPARATE_SYNC) {
+   case DRM_EDID_PT_SEPARATE_SYNC: /* digital, separate */
+   *flags |= (pt-misc  DRM_EDID_PT_HSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
+   *flags |= (pt-misc  DRM_EDID_PT_VSYNC_POSITIVE) ?
+   DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+   break;
+   case DRM_EDID_PT_DIGITAL_CSYNC: /* digital, composite */
+   *flags |= DRM_MODE_FLAG_CSYNC;
+   if (pt-misc  DRM_EDID_PT_CSYNC_SERRATION)
+   *flags |= DRM_MODE_FLAG_SYNC_SERRATION;
+   break;
+   case DRM_EDID_PT_BIANALOG_CSYNC: /* bipolar analog composite */
+   case DRM_EDID_PT_ANALOG_CSYNC: /* unipolar analog composite */
+   *flags |= DRM_MODE_FLAG_CSYNC;
+   if (pt-misc  DRM_EDID_PT_CSYNC_SERRATION)
+   *flags |= DRM_MODE_FLAG_SYNC_SERRATION;
+   if (pt-misc  DRM_EDID_PT_CSYNC_RGB)
+   *flags |= DRM_MODE_FLAG_SYNC_RGB; /* else sync-on-green */
+   break;
+   }
 }
 
 /**
@@ -898,10 +915,6 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
return NULL;
}
 
-   if (!(pt-misc  DRM_EDID_PT_SEPARATE_SYNC)) {
-   printk(KERN_WARNING composite sync not supported\n);
-   }
-
/* it is incorrect if hsync/vsync width is zero */
if (!hsync_pulse_width || !vsync_pulse_width) {
DRM_DEBUG_KMS(Incorrect Detailed timing. 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 73e4560..d0c958e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -105,6 +105,7 @@ enum drm_mode_status {
 MODE_ONE_HEIGHT,/* only one height is supported */
 MODE_ONE_SIZE,  /* only one resolution is supported */
 MODE_NO_REDUCED,/* monitor doesn't accept reduced blanking */
+MODE_NO_CSYNC, /* connector doesn't support composite sync */

[PATCH] drm/radeon/kms: attempt to fix rs690 issues.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

Since c9a1be96277b3b2d2e8aff2ba69d7817ea8e46c9, or at least since v3.2
we've had some regression reports, this is an attempt to fix them by
putting back some volatiles that were removed in that commit.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/r100.c|2 +-
 drivers/gpu/drm/radeon/r300.c|2 +-
 drivers/gpu/drm/radeon/radeon.h  |2 +-
 drivers/gpu/drm/radeon/radeon_gart.c |2 +-
 drivers/gpu/drm/radeon/rs400.c   |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index fb44e7e..26488f7 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -680,7 +680,7 @@ void r100_pci_gart_disable(struct radeon_device *rdev)
 
 int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
-   u32 *gtt = rdev-gart.ptr;
+   volatile u32 *gtt = rdev-gart.ptr;
 
if (i  0 || i  rdev-gart.num_gpu_pages) {
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..bb596f4 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -74,7 +74,7 @@ void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev)
 
 int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
-   void __iomem *ptr = rdev-gart.ptr;
+   void __iomem *ptr = (void *)rdev-gart.ptr;
 
if (i  0 || i  rdev-gart.num_gpu_pages) {
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fefcca5..3fd759a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -470,7 +470,7 @@ struct radeon_mc;
 struct radeon_gart {
dma_addr_t  table_addr;
struct radeon_bo*robj;
-   void*ptr;
+   volatile void   *ptr;
unsignednum_gpu_pages;
unsignednum_cpu_pages;
unsignedtable_size;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 59d4493..b2db83a 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -102,7 +102,7 @@ int radeon_gart_table_vram_pin(struct radeon_device *rdev)
radeon_bo_unreserve(rdev-gart.robj);
return r;
}
-   r = radeon_bo_kmap(rdev-gart.robj, rdev-gart.ptr);
+   r = radeon_bo_kmap(rdev-gart.robj, (void **)rdev-gart.ptr);
if (r)
radeon_bo_unpin(rdev-gart.robj);
radeon_bo_unreserve(rdev-gart.robj);
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index a464eb5..82f1a7c 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -212,7 +212,7 @@ void rs400_gart_fini(struct radeon_device *rdev)
 int rs400_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
uint32_t entry;
-   u32 *gtt = rdev-gart.ptr;
+   volatile u32 *gtt = rdev-gart.ptr;
 
if (i  0 || i  rdev-gart.num_gpu_pages) {
return -EINVAL;
-- 
1.7.10.2

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

Re: [PATCH 2/3] intel: wait render header updates

[Ben Widawsky]

On Tue,  5 Jun 2012 15:42:39 -0700
Ben Widawsky b...@bwidawsk.net wrote:

 make headers_install in kernel. Copy to here.
 
 v2: signed ns_timeout
 
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

This has been pushed with IRC
Acked-by Kenneth Graunke kenn...@whitecape.org

 ---
  include/drm/i915_drm.h |   11 +++
  1 file changed, 11 insertions(+)
 
 diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
 index 725a8de..4931107 100644
 --- a/include/drm/i915_drm.h
 +++ b/include/drm/i915_drm.h
 @@ -192,6 +192,7 @@ typedef struct _drm_i915_sarea {
  #define DRM_I915_GEM_EXECBUFFER2 0x29
  #define DRM_I915_GET_SPRITE_COLORKEY 0x2a
  #define DRM_I915_SET_SPRITE_COLORKEY 0x2b
 +#define DRM_I915_GEM_WAIT0x2c
  
  #define DRM_IOCTL_I915_INIT  DRM_IOW( DRM_COMMAND_BASE + 
 DRM_I915_INIT, drm_i915_init_t)
  #define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE + 
 DRM_I915_FLUSH)
 @@ -235,6 +236,7 @@ typedef struct _drm_i915_sarea {
  #define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE + 
 DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
  #define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + 
 DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
  #define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + 
 DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
 +#define DRM_IOCTL_I915_GEM_WAIT  DRM_IOWR(DRM_COMMAND_BASE + 
 DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
  
  /* Allow drivers to submit batchbuffers directly to hardware, relying
   * on the security mechanisms provided by hardware.
 @@ -290,6 +292,7 @@ typedef struct drm_i915_irq_wait {
  #define I915_PARAM_HAS_GEN7_SOL_RESET 16
  #define I915_PARAM_HAS_LLC17
  #define I915_PARAM_HAS_ALIASING_PPGTT 18
 +#define I915_PARAM_HAS_WAIT_TIMEOUT   19
  
  typedef struct drm_i915_getparam {
   int param;
 @@ -878,4 +881,12 @@ struct drm_intel_sprite_colorkey {
   __u32 flags;
  };
  
 +struct drm_i915_gem_wait {
 + /** Handle of BO we shall wait on */
 + __u32 bo_handle;
 + __u32 flags;
 + /** Number of nanoseconds to wait, Returns time remaining. */
 + __s64 timeout_ns;
 +};
 +
  #endif   /* _I915_DRM_H_ */



-- 
Ben Widawsky, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] intel: sanitize i915_drm.h

[Ben Widawsky]

On Tue,  5 Jun 2012 11:58:11 -0700
Ben Widawsky b...@bwidawsk.net wrote:

 run make headers_isntall on d-i-n, copy to here
 
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

This has been pushed with IRC
Acked-by Kenneth Graunke kenn...@whitecape.org



 ---
  include/drm/i915_drm.h |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
 index af3ce17..725a8de 100644
 --- a/include/drm/i915_drm.h
 +++ b/include/drm/i915_drm.h
 @@ -33,6 +33,7 @@
   * subject to backwards-compatibility constraints.
   */
  
 +
  /* Each region is a minimum of 16k, and there are at most 255 of them.
   */
  #define I915_NR_TEX_REGIONS 255  /* table size 2k - maximum due to use
 @@ -287,7 +288,8 @@ typedef struct drm_i915_irq_wait {
  #define I915_PARAM_HAS_EXEC_CONSTANTS 14
  #define I915_PARAM_HAS_RELAXED_DELTA  15
  #define I915_PARAM_HAS_GEN7_SOL_RESET 16
 -#define I915_PARAM_HAS_LLC17
 +#define I915_PARAM_HAS_LLC17
 +#define I915_PARAM_HAS_ALIASING_PPGTT 18
  
  typedef struct drm_i915_getparam {
   int param;



-- 
Ben Widawsky, Intel Open Source Technology Center

-- 
Ben Widawsky, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43346] New: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018

[bugzilla-daemon]

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

   Summary: BUG: unable to handle kernel NULL pointer dereference
at 0018
   Product: Drivers
   Version: 2.5
Kernel Version: 3.2.18
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: bjorn.otter...@gmail.com
Regression: No


Happens about once a week, but I can't reproduce it at will. X is still running
as before, but unbearably slow. GPU is an integrated HD4200 of an AMD 785G ASUS
mainboard, model M4A785D-M Pro.

[261062.255333] [TTM] Erroneous page count. Leaking pages.
[261062.753541] BUG: unable to handle kernel NULL pointer dereference at
0018
[261062.753705] IP: [813f9a71] ttm_bo_cleanup_memtype_use+0x51/0x80
[261062.753830] PGD 214e12067 PUD 214e64067 PMD 0 
[261062.753918] Oops:  [#1] SMP 
[261062.753981] CPU 0 
[261062.754007] Modules linked in: sata_sil
[261062.754007] 
[261062.754007] Pid: 2467, comm: xbmc.bin Not tainted 3.2.18 #1 System
manufacturer System Product Name/M4A785D-M PRO
[261062.754007] RIP: 0010:[813f9a71]  [813f9a71]
ttm_bo_cleanup_memtype_use+0x51/0x80
[261062.754007] RSP: 0018:88021fbd7c58  EFLAGS: 00010256
[261062.754007] RAX:  RBX: 88003c8c6c48 RCX:
8802267f0548
[261062.754007] RDX:  RSI: 88003c8c6ca8 RDI:
8802267f0570
[261062.754007] RBP: 0002 R08:  R09:
813f9a41
[261062.754007] R10: 0039 R11: 0246 R12:
8802267f0548
[261062.754007] R13: 8802259853c0 R14: 88003c8c6c8c R15:
fff2
[261062.754007] FS:  7fe3f3cba720() GS:88022fc0()
knlGS:
[261062.754007] CS:  0010 DS:  ES:  CR0: 80050033
[261062.754007] CR2: 0018 CR3: 000214e0d000 CR4:
06f0
[261062.754007] DR0:  DR1:  DR2:

[261062.754007] DR3:  DR6: 0ff0 DR7:
0400
[261062.754007] Process xbmc.bin (pid: 2467, threadinfo 88021fbd6000, task
88022212)
[261062.754007] Stack:
[261062.754007]  88003c8c6c48 813fad00 88004421b200
88004421b200
[261062.754007]  88021fbd7d74  880226ff5000
88003c8c6c88
[261062.754007]  813faaa0 000a 88003c8c6e00
880226ff5000
[261062.754007] Call Trace:
[261062.754007]  [813fad00] ? ttm_bo_release+0x260/0x280
[261062.754007]  [813faaa0] ? ttm_bo_delayed_workqueue+0x30/0x30
[261062.754007]  [813304e3] ? kref_put+0x33/0x70
[261062.754007]  [813f9ec5] ? ttm_bo_unref+0x35/0x50
[261062.754007]  [8142f902] ? radeon_bo_unref+0x42/0x80
[261062.754007]  [813e4f60] ? drm_gem_object_ref_bug+0x10/0x10
[261062.754007]  [8143fc1f] ? radeon_gem_object_free+0x1f/0x30
[261062.754007]  [813304e3] ? kref_put+0x33/0x70
[261062.754007]  [813e50c8] ? drm_gem_handle_delete+0xa8/0xf0
[261062.754007]  [813e374c] ? drm_ioctl+0x3ec/0x4a0
[261062.754007]  [8132d54d] ? cpumask_any_but+0x2d/0x40
[261062.754007]  [813e55f0] ? drm_gem_destroy+0x50/0x50
[261062.754007]  [810cda5e] ? tlb_finish_mmu+0xe/0x50
[261062.754007]  [810d468b] ? unmap_region+0x10b/0x150
[261062.754007]  [8110a7b6] ? do_vfs_ioctl+0x96/0x540
[261062.754007]  [810d4562] ? remove_vma+0x52/0x70
[261062.754007]  [810d5936] ? do_munmap+0x2d6/0x360
[261062.754007]  [8110aca9] ? sys_ioctl+0x49/0x80
[261062.754007]  [8175e73b] ? system_call_fastpath+0x16/0x1b
[261062.754007] Code: 00 00 00 00 00 00 48 83 7b 60 00 48 8b 4b 08 8b 93 84 00
00 00 74 17 89 d2 48 8d 73 60 48 c1 e2 07 48 8b 44 11 50 48 8d 7c 11 28 ff 50
18 c7 83 20 01 00 00 00 00 00 00 48 8d 7b 48 31 c9 31 d2 
[261062.754007] RIP  [813f9a71] ttm_bo_cleanup_memtype_use+0x51/0x80
[261062.754007]  RSP 88021fbd7c58
[261062.754007] CR2: 0018
[261062.795877] ---[ end trace 4bb94fa28b7f787a ]---

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

[Bug 36602] Hierarchical Z support for R600

[bugzilla-daemon]

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

--- Comment #44 from Jerome Glisse gli...@freedesktop.org 2012-06-06 15:24:55 
PDT ---
Updated with more fixes (down to ~100 regression with piglit)

http://people.freedesktop.org/~glisse/0001-r600g-add-htile-support-v6.patch

To enable hyperz
R600_HYPERZ=1 glxgears

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

[Bug 36602] Hierarchical Z support for R600

[bugzilla-daemon]

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

--- Comment #45 from darkbasic darkba...@linuxsystems.it 2012-06-06 15:33:35 
PDT ---
Thanks Jerome

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

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

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

--- Comment #62 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-06-06 
15:37:07 PDT ---
(In reply to comment #61)
 Please also try this patch:
 http://lists.freedesktop.org/archives/dri-devel/2012-June/023735.html
 
 It doesn't fix anything rendering related, but instead fixes a deadlock
 introduced with the vm patch It isn't the complete solution of the problem it
 might still be an improvement.
 
 Christian.

Thanks Christian. I just tested the patch and it still fails. Running piglit on
r600.test hangs, kills Xorg, restarts without any 3D support and produce the
following:

-
dmesg:

[   44.640434] retire_capture_urb: 1 callbacks suppressed
[   64.193666] radeon :01:00.0: bo 88021b1d2400 va 0x0180D000 conflict
with (bo 880221d00400 0x0180D000 0x0180E000)
[   64.242569] radeon :01:00.0: bo 880221d1dc00 va 0x0184E000 conflict
with (bo 8802135ac800 0x0184E000 0x0184F000)
[   64.369362] radeon :01:00.0: bo 880222126800 va 0x01841000 conflict
with (bo 88021b3b4400 0x01841000 0x01842000)
[   64.832098] radeon :01:00.0: bo 88021352dc00 va 0x01859000 conflict
with (bo 880222c42800 0x01859000 0x0185B000)
[   65.486230] EXT4-fs (sdc2): warning: maximal mount count reached, running
e2fsck is recommended
[   65.540929] EXT4-fs (sdc2): mounted filesystem with ordered data mode. Opts:
(null)
[   69.016383] radeon :01:00.0: bo 880221d1e000 va 0x0402D000 conflict
with (bo 880221fc5000 0x0402D000 0x0402E000)
[   69.017579] radeon :01:00.0: bo 880221d1b400 va 0x0404D000 conflict
with (bo 880206061400 0x0404D000 0x0404E000)
[  471.209470] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[  471.209482] radeon :01:00.0: GPU lockup (waiting for 0x1ee7
last fence id 0x1ee4)
[  471.708793] radeon :01:00.0: GPU lockup CP stall for more than 10500msec
[  471.708803] radeon :01:00.0: GPU lockup (waiting for 0x1ee5)
[  471.708812] radeon :01:00.0: failed to get a new IB (-35)
[  471.708818] [drm:radeon_cs_ib_chunk] *ERROR* Failed to get ib !
[  471.712988] radeon :01:00.0: GPU softreset 
[  471.712996] radeon :01:00.0:   GRBM_STATUS=0xB3703828
[  471.713001] radeon :01:00.0:   GRBM_STATUS_SE0=0x2407
[  471.713006] radeon :01:00.0:   GRBM_STATUS_SE1=0x3D07
[  471.713012] radeon :01:00.0:   SRBM_STATUS=0x200206C0
[  471.713017] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_ADDR  
0x
[  471.713023] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_STATUS
0x
[  471.713029] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  471.713035] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x07070010
[  471.862829] radeon :01:00.0: Wait for MC idle timedout !
[  471.862831] radeon :01:00.0:   GRBM_SOFT_RESET=0xDF7B
[  471.862933] radeon :01:00.0:   GRBM_STATUS=0x3828
[  471.862934] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[  471.862936] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[  471.862937] radeon :01:00.0:   SRBM_STATUS=0x200206C0
[  471.863938] radeon :01:00.0: GPU reset succeed
[  472.044573] radeon :01:00.0: Wait for MC idle timedout !
[  472.202790] radeon :01:00.0: Wait for MC idle timedout !
[  472.204511] [drm] PCIE GART of 512M enabled (table at 0x0004).
[  472.204582] radeon :01:00.0: WB enabled
[  472.204584] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x880221964c00
[  472.204586] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x4c04 and cpu addr 0x880221964c04
[  472.204587] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x4c08 and cpu addr 0x880221964c08
[  472.387014] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8500)=0xCAFEDEAD)
[  472.387015] [drm:cayman_resume] *ERROR* cayman startup failed on resume
[  472.406246] radeon :01:00.0: 88021c7d3800 unpin not necessary
[  472.406260] radeon :01:00.0: 88021c7d3c00 unpin not necessary
[  472.407518] radeon :01:00.0: GPU softreset 
[  472.407525] radeon :01:00.0:   GRBM_STATUS=0xA0003828
[  472.407530] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[  472.407536] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[  472.407541] radeon :01:00.0:   SRBM_STATUS=0x200206C0
[  472.407546] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_ADDR  
0x
[  472.407552] radeon :01:00.0:   VM_CONTEXT0_PROTECTION_FAULT_STATUS
0x
[  472.407557] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  472.407562] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x07070010
[  472.577076] radeon :01:00.0: Wait for MC idle timedout !
[  472.577080] radeon :01:00.0:   GRBM_SOFT_RESET=0xDF7B
[  472.577183] radeon :01:00.0:   

[PATCH 1/2] drm: drmIoctl return -errno on failure conditions

[Ben Widawsky]

Anyone aware of what this will break? It seems to be a much nicer thing
to do for callers. If people do not like it, I will probably just create
a #define drmIoctl2 or some such thing.

Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Keith Packard kei...@keithp.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 xf86drm.c |4 
 1 file changed, 4 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..015203d 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -166,6 +166,10 @@ drmIoctl(int fd, unsigned long request, void *arg)
 do {
ret = ioctl(fd, request, arg);
 } while (ret == -1  (errno == EINTR || errno == EAGAIN));
+
+if (ret)
+   return -errno;
+
 return ret;
 }
 
-- 
1.7.10.3

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

Re: [PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Laurent Pinchart]

Hi Tomasz,

On Wednesday 06 June 2012 13:56:42 Tomasz Stanislawski wrote:
 On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
  On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
  This patch adds the setup of sglist list for MMAP buffers.
  It is needed for buffer exporting via DMABUF mechanism.
  
  Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
  
   drivers/media/video/videobuf2-dma-contig.c |   70 +-
   1 file changed, 68 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/media/video/videobuf2-dma-contig.c
  b/drivers/media/video/videobuf2-dma-contig.c index 52b4f59..ae656be
  100644
  --- a/drivers/media/video/videobuf2-dma-contig.c
  +++ b/drivers/media/video/videobuf2-dma-contig.c

[snip]

  +static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
  +  struct page **pages, unsigned int n_pages)
  +{
  +  unsigned int i;
  +  unsigned long pfn;
  +  struct vm_area_struct vma = {
  +  .vm_flags = VM_IO | VM_PFNMAP,
  +  .vm_mm = current-mm,
  +  };
  +
  +  for (i = 0; i  n_pages; ++i, kaddr += PAGE_SIZE) {
  
  The follow_pfn() kerneldoc mentions that it looks up a PFN for a user
  address. The only users I've found in the kernel sources pass a user
  address. Is it legal to use it for kernel addresses ?
 
 It is not completely legal :). As I understand the mm code, the follow_pfn
 works only for IO/PFN mappings. This is the typical case (every case?) of
 mappings created by dma_alloc_coherent.
 
 In order to make this function work for a kernel pointer, one has to create
 an artificial VMA that has IO/PFN bits on.
 
 This solution is a hack-around for dma_get_pages (aka dma_get_sgtable). This
 way the dependency on dma_get_pages was broken giving a small hope of
 merging vb2 exporting.
 
 Marek prepared a patchset 'ARM: DMA-mapping: new extensions for buffer
 sharing' that adds dma buffers with no kernel mappings and dma_get_sgtable
 function.
 
 However this patchset is still in a RFC state.

That's totally understood :-) I'm fine with keeping the hack for now until the 
dma_get_sgtable() gets in a usable/mergeable state, please just mention it in 
the code with something like

/* HACK: This is a temporary workaround until the dma_get_sgtable() function 
becomes available. */

 I have prepared a patch that removes vb2_dc_kaddr_to_pages and substitutes
 it with dma_get_pages. It will become a part of vb2-exporter patches just
 after dma_get_sgtable is merged (or at least acked by major maintainers).

-- 
Regards,

Laurent Pinchart

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

Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Laurent Pinchart]

Hi Hans,

On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
 On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
  On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
   I have a system where the data is planar, but the kernel drivers
   expect to get one allocation with offsets for the planes.  I can't
   figure out how to do that with the current dma_buf implementation.  I
   thought I could pass the same dma_buf several times and use the
   data_offset field of the v4l2_plane struct but it looks like that's
   only for output.  Am I missing something?  Is this supported?
  
  data_offset is indeed for video output only at the moment, and doesn't
  seem to be used by any driver in mainline for now.
 
 Actually, data_offset may be set by capture drivers. For output buffers it
 is set by userspace, for capture buffers it is set by the driver. This
 data_offset typically contains meta data.

Is that documented somewhere ? I wasn't aware of this use case.

  I can't really see a reason why data_offset couldn't be used for video
  capture devices as well.
  
  Sanity checks are currently missing. For output devices we should check
  that data_offset + bytesused  length in the vb2 core. For input devices
  the check will have to be performed by drivers. Taking data_offset into
  account automatically would also be useful. I think most of that should
  be possible to implement in the allocators.
 
 See this proposal of how to solve this:
 
 http://www.spinics.net/lists/linux-media/msg40376.html

This requires more discussions regarding how the app_offset and data_offset 
fields should be used for the different memory types we support.

For instance app_offset would not make that much sense for the USERPTR memory 
type, as we can include the offset in the user pointer already (using 
app_offset there would only make the code more complex without any added 
benefit).

For the MMAP memory type adding an app_offset would require allocating buffers 
large enough to accomodate the offset, and would thus only be useful with 
CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer 
to another device that requires that app_offset) wouldn't be better addressed 
by the DMABUF memory type anyway.

Comments are welcome.

-- 
Regards,

Laurent Pinchart

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

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

[bugzilla-daemon]

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

--- Comment #83 from t...@math.tu-berlin.de 2012-06-06 18:21:06 PDT ---
Finally, success!

I'm not quite sure why, but for reasons unclear to me the DVO chip only wants
to talk if the PLL is enabled and running and the screen resolution fits. In
addition, the system has apparently a fake VGA output that must be disabled
to have the system working properly. Otherwise, the KMS layer seems to want to
redirect the output to the VGA, and then drops dead, leaving an unusable screen
(and DVO!) behind. I do not know yet whether the physical VGA connector works,
but basically, here is the receipt:

1) Apply the patches I mentioned above. Especially, the bypass mode of the
scaler must be set as its function is unclear.

static void ns2501_dpms(struct intel_dvo_device *dvo, int mode)
{
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo-dev_priv);
  unsigned char ch;

  DRM_DEBUG_KMS(%s: Trying set the dpms of the DVO to
%d\n,__FUNCTION__,mode);

  if (ns-reg_8_set) {
ch = ns-reg_8_shadow;
  } else {
ch = NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN;
  }

  if (mode == DRM_MODE_DPMS_ON)
ch |= NS2501_8_PD;
  else
ch = ~NS2501_8_PD;

  ch |= NS2501_8_BPAS;

  if (ns-reg_8_set == 0 || ns-reg_8_shadow != ch) {
ns-reg_8_set= 1;
ns-reg_8_shadow = ch;
ns2501_writeb(dvo, NS2501_REG8, ch);
  }
}

Here I added a shadow register which is likely not exactly necessary, though I
wanted to avoid the i2c communication if not necessary.


2) There is still a bug in the ns2501 source in so far as the query function
returns something unitialized if reading from the DVO fails. And it fails quite
often.

static enum drm_connector_status ns2501_detect(struct intel_dvo_device *dvo)
{
  uint8_t reg9;
  enum drm_connector_status status = connector_status_unknown;
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo-dev_priv);

  DRM_DEBUG_KMS(%s: Trying to detect the connector status\n,__FUNCTION__);


  if (ns2501_readb(dvo, NS2501_REG9, reg9)) {
if (!(reg9  NS2501_9_RSEN))
  status = connector_status_connected;
else
  status = connector_status_disconnected;

ns-reg_9_set= 1;
ns-reg_9_shadow = reg9;
  } else if (ns-reg_9_set) {
if (!(ns-reg_9_shadow  NS2501_9_RSEN))
  status = connector_status_connected;
else
  status = connector_status_disconnected;
  } 

  DRM_DEBUG_KMS(%s: Status is %d\n,__FUNCTION__,status);

  return status;
}

Again a shadow register was added.

3) The following kernel arguments should be added to disable the VGA output:

i915.modeset=1 video=VGA-1:1024x768d video=DVI-I-1:1024x768e

I'm not sure why the system behaives so strange otherwise, I'll try to dig a
bit deeper, but I believe that there is some limitation with the i830 and its
outputs. Probably I'll find a datasheet.

With the above modifications, you cannot, of course, scale the screen
(resolution is fixed), though 3D acceleration works nicely.

The same trick might also apply to the IBM R31, I'll check later next week - it
had similar issues.

(Is actually anyone reading this??? Is there a better way to supply patches?)

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

[Bug 50805] New: radeon gpu driver bug on suspend/resume in 3.5-rc1

[bugzilla-daemon]

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

 Bug #: 50805
   Summary: radeon gpu driver bug on suspend/resume in 3.5-rc1
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: Other
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: austin.l...@gmail.com


Created attachment 62685
  -- https://bugs.freedesktop.org/attachment.cgi?id=62685
two samples of the kernel log

I get the attached traces with 3.5-rc1 after suspend/resume,
sometimes.  It doesn't always happen.  Usually happens at least once
in 10 suspend/resume cycles.  The first trace seems non fatal, but the
system locks up in the second one and needs to be rebooted.

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

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

--- Comment #9 from Bryan Quigley bryanquig...@ubuntu.com 2012-06-06 21:39:53 
PDT ---
I think I did everything right in this bisect (I didn't the first attempt).

fbebd431ec4e2e461a0cbcd5f3a04a000b8f6bbf is the first bad commit
commit fbebd431ec4e2e461a0cbcd5f3a04a000b8f6bbf
Author: Marek Olšák mar...@gmail.com
Date:   Fri Feb 3 05:05:31 2012 +0100

r600g: move invariant register updates into start_cs for r6xx-r7xx

:04 04 dd9232a0c49e54e0cd536fa858dc131982dc2fbe
379e1d61c53d98a8706f32da5020dc22c0c0ee33 Msrc

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

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

--- Comment #10 from Bryan Quigley bryanquig...@ubuntu.com 2012-06-06 
21:42:42 PDT ---
Created attachment 62689
  -- https://bugs.freedesktop.org/attachment.cgi?id=62689
good+bad git bisects

Both the good and bad git bisect logs, the good one had me run warsow, padman,
and urbanterror looking for the bug.
The bad one missed some occurrences it seems.

-- 
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 libdrm 8/8] proptest: support plane properties

[Joonyoung Shim]

Hi, Rob.

On 06/06/2012 03:06 AM, Rob Clark wrote:

From: Rob Clarkr...@ti.com

Add support to display plane properties.


Do you not support to set property for plane?



Signed-off-by: Rob Clarkr...@ti.com
---
  tests/proptest/proptest.c |   32 
  1 file changed, 32 insertions(+)

diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
index fa34a48..aac6b8f 100644
--- a/tests/proptest/proptest.c
+++ b/tests/proptest/proptest.c
@@ -39,6 +39,7 @@

  int fd;
  drmModeResPtr res = NULL;
+drmModePlaneResPtr plane_res = NULL;

  const char *connector_type_str(uint32_t type)
  {
@@ -239,10 +240,33 @@ static void listCrtcProperties(void)
}
  }

+static void listPlaneProperties(void)
+{
+   int i;
+   drmModePlanePtr p;
+
+   for (i = 0; i  plane_res-count_planes; i++) {
+   p = drmModeGetPlane(fd, plane_res-planes[i]);
+
+   if (!p) {
+   fprintf(stderr, Could not get plane %u: %s\n,
+   plane_res-planes[i], strerror(errno));
+   continue;
+   }
+
+   printf(Plane %u\n, p-plane_id);
+
+   listObjectProperties(p-plane_id, DRM_MODE_OBJECT_PLANE);
+
+   drmModeFreePlane(p);
+   }
+}
+
  static void listAllProperties(void)
  {
listConnectorProperties();
listCrtcProperties();
+   listPlaneProperties();
  }

  static int setProperty(char *argv[])
@@ -309,6 +333,14 @@ int main(int argc, char *argv[])
goto done;
}

+   plane_res = drmModeGetPlaneResources(fd);
+   if (!plane_res) {
+   fprintf(stderr, Failed to get plane resources: %s\n,
+   strerror(errno));
+   ret = 1;
+   goto done;
+   }
+
if (argc  2) {
listAllProperties();
} else if (argc == 5) {


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

Re: [PATCH libdrm 3/8] tests: add proptest

[Joonyoung Shim]

Hi, Rob and Paulo.

On 06/06/2012 03:06 AM, Rob Clark wrote:

From: Paulo Zanonipaulo.r.zan...@intel.com

A small program that allows us to see and modify properties.

Reviewed-by: Rob Clarkr...@ti.com
Signed-off-by: Paulo Zanonipaulo.r.zan...@intel.com
---
  configure.ac   |1 +
  tests/Makefile.am  |2 +-
  tests/proptest/Makefile.am |   11 ++
  tests/proptest/proptest.c  |  317 
  4 files changed, 330 insertions(+), 1 deletion(-)
  create mode 100644 tests/proptest/Makefile.am
  create mode 100644 tests/proptest/proptest.c

diff --git a/configure.ac b/configure.ac
index e6e9a9f..73558ce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -329,6 +329,7 @@ AC_CONFIG_FILES([
tests/modeprint/Makefile
tests/modetest/Makefile
tests/kmstest/Makefile
+   tests/proptest/Makefile
tests/radeon/Makefile
tests/vbltest/Makefile
include/Makefile
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a3a59bd..1442854 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -10,7 +10,7 @@ check_PROGRAMS = \
dristat \
drmstat

-SUBDIRS = modeprint
+SUBDIRS = modeprint proptest

  if HAVE_LIBKMS
  SUBDIRS += kmstest modetest
diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
new file mode 100644
index 000..f81a3c0
--- /dev/null
+++ b/tests/proptest/Makefile.am
@@ -0,0 +1,11 @@
+AM_CFLAGS = \
+   -I$(top_srcdir)/include/drm \
+   -I$(top_srcdir)
+
+noinst_PROGRAMS = \
+   proptest
+
+proptest_SOURCES = \
+   proptest.c
+proptest_LDADD = \
+   $(top_builddir)/libdrm.la
diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
new file mode 100644
index 000..52896fe
--- /dev/null
+++ b/tests/proptest/proptest.c
@@ -0,0 +1,317 @@
+/*
+ * Copyright (c) 2012 Intel 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 (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Paulo Zanonipaulo.r.zan...@intel.com
+ *
+ */
+
+#includeassert.h
+#includeerrno.h
+#includeinttypes.h
+#includestdlib.h
+#includestdio.h
+#includestring.h
+
+#include xf86drm.h
+#include xf86drmMode.h
+
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+int fd;
+drmModeResPtr res = NULL;
+
+const char *connector_type_str(uint32_t type)
+{
+   switch (type) {
+   case DRM_MODE_CONNECTOR_Unknown:
+   return Unknown;
+   case DRM_MODE_CONNECTOR_VGA:
+   return VGA;
+   case DRM_MODE_CONNECTOR_DVII:
+   return DVI-I;
+   case DRM_MODE_CONNECTOR_DVID:
+   return DVI-D;
+   case DRM_MODE_CONNECTOR_DVIA:
+   return DVI-A;
+   case DRM_MODE_CONNECTOR_Composite:
+   return Composite;
+   case DRM_MODE_CONNECTOR_SVIDEO:
+   return SVIDEO;
+   case DRM_MODE_CONNECTOR_LVDS:
+   return LVDS;
+   case DRM_MODE_CONNECTOR_Component:
+   return Component;
+   case DRM_MODE_CONNECTOR_9PinDIN:
+   return 9PinDin;
+   case DRM_MODE_CONNECTOR_DisplayPort:
+   return DisplayPort;
+   case DRM_MODE_CONNECTOR_HDMIA:
+   return HDMI-A;
+   case DRM_MODE_CONNECTOR_HDMIB:
+   return HDMI-B;
+   case DRM_MODE_CONNECTOR_TV:
+   return TV;
+   case DRM_MODE_CONNECTOR_eDP:
+   return eDP;
+   default:
+   return Invalid;
+   }
+}
+
+/* dump_blob and dump_prop shamelessly copied from ../modetest/modetest.c */
+static void
+dump_blob(uint32_t blob_id)
+{
+   uint32_t i;
+   unsigned char *blob_data;
+   drmModePropertyBlobPtr blob;
+
+   blob = drmModeGetPropertyBlob(fd, blob_id);
+   if (!blob)
+   return;
+
+   blob_data = blob-data;
+
+   for (i = 0; i  blob-length; i++) {
+   if (i % 16 == 0)
+   printf(\n\t\t\t);
+