Re: [PATCH 2/6] drm/i915: use common functions for mmap offset creation

2011-09-13 Thread Daniel Vetter 
On Mon, Sep 12, 2011 at 02:21:22PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
-- 
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

Re: [PATCH 5/6] drm/i915: use common functions for get/put pages

2011-09-13 Thread Daniel Vetter 
On Mon, Sep 12, 2011 at 02:21:25PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
-- 
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

[PATCH] drm/radeon: Don't read from CP ring write pointer registers.

2011-09-13 Thread Michel Dänzer 
From: Michel Dänzer 

Apparently this doesn't always work reliably, e.g. at resume time.

Just initialize to 0, so the ring is considered empty.

Tested with hibernation on Sumo and Cayman cards.

Should fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ .

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/evergreen.c |4 ++--
 drivers/gpu/drm/radeon/ni.c|   12 ++--
 drivers/gpu/drm/radeon/r100.c  |6 ++
 drivers/gpu/drm/radeon/r600.c  |4 ++--
 4 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 15bd047..f2bd90a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1378,7 +1378,8 @@ int evergreen_cp_resume(struct radeon_device *rdev)
/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB_CNTL, tmp | RB_RPTR_WR_ENA);
WREG32(CP_RB_RPTR_WR, 0);
-   WREG32(CP_RB_WPTR, 0);
+   rdev->cp.wptr = 0;
+   WREG32(CP_RB_WPTR, rdev->cp.wptr);
 
/* set the wb address wether it's enabled or not */
WREG32(CP_RB_RPTR_ADDR,
@@ -1403,7 +1404,6 @@ int evergreen_cp_resume(struct radeon_device *rdev)
WREG32(CP_DEBUG, (1 << 27) | (1 << 28));
 
rdev->cp.rptr = RREG32(CP_RB_RPTR);
-   rdev->cp.wptr = RREG32(CP_RB_WPTR);
 
evergreen_cp_start(rdev);
rdev->cp.ready = true;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 559dbd4..e3489ee 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1182,7 +1182,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
 
/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB0_CNTL, tmp | RB_RPTR_WR_ENA);
-   WREG32(CP_RB0_WPTR, 0);
+   rdev->cp.wptr = 0;
+   WREG32(CP_RB0_WPTR, rdev->cp.wptr);
 
/* set the wb address wether it's enabled or not */
WREG32(CP_RB0_RPTR_ADDR, (rdev->wb.gpu_addr + RADEON_WB_CP_RPTR_OFFSET) 
& 0xFFFC);
@@ -1202,7 +1203,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
WREG32(CP_RB0_BASE, rdev->cp.gpu_addr >> 8);
 
rdev->cp.rptr = RREG32(CP_RB0_RPTR);
-   rdev->cp.wptr = RREG32(CP_RB0_WPTR);
 
/* ring1  - compute only */
/* Set ring buffer size */
@@ -1215,7 +1215,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
 
/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB1_CNTL, tmp | RB_RPTR_WR_ENA);
-   WREG32(CP_RB1_WPTR, 0);
+   rdev->cp1.wptr = 0;
+   WREG32(CP_RB1_WPTR, rdev->cp1.wptr);
 
/* set the wb address wether it's enabled or not */
WREG32(CP_RB1_RPTR_ADDR, (rdev->wb.gpu_addr + 
RADEON_WB_CP1_RPTR_OFFSET) & 0xFFFC);
@@ -1227,7 +1228,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
WREG32(CP_RB1_BASE, rdev->cp1.gpu_addr >> 8);
 
rdev->cp1.rptr = RREG32(CP_RB1_RPTR);
-   rdev->cp1.wptr = RREG32(CP_RB1_WPTR);
 
/* ring2 - compute only */
/* Set ring buffer size */
@@ -1240,7 +1240,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
 
/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB2_CNTL, tmp | RB_RPTR_WR_ENA);
-   WREG32(CP_RB2_WPTR, 0);
+   rdev->cp2.wptr = 0;
+   WREG32(CP_RB2_WPTR, rdev->cp2.wptr);
 
/* set the wb address wether it's enabled or not */
WREG32(CP_RB2_RPTR_ADDR, (rdev->wb.gpu_addr + 
RADEON_WB_CP2_RPTR_OFFSET) & 0xFFFC);
@@ -1252,7 +1253,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
WREG32(CP_RB2_BASE, rdev->cp2.gpu_addr >> 8);
 
rdev->cp2.rptr = RREG32(CP_RB2_RPTR);
-   rdev->cp2.wptr = RREG32(CP_RB2_WPTR);
 
/* start the rings */
cayman_cp_start(rdev);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index f2204cb..11e44a3 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -990,7 +990,8 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
/* Force read & write ptr to 0 */
WREG32(RADEON_CP_RB_CNTL, tmp | RADEON_RB_RPTR_WR_ENA | 
RADEON_RB_NO_UPDATE);
WREG32(RADEON_CP_RB_RPTR_WR, 0);
-   WREG32(RADEON_CP_RB_WPTR, 0);
+   rdev->cp.wptr = 0;
+   WREG32(RADEON_CP_RB_WPTR, rdev->cp.wptr);
 
/* set the wb address whether it's enabled or not */
WREG32(R_00070C_CP_RB_RPTR_ADDR,
@@ -1007,9 +1008,6 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
WREG32(RADEON_CP_RB_CNTL, tmp);
udelay(10);
rdev->cp.rptr = RREG32(RADEON_CP_RB_RPTR);
-   rdev->cp.wptr = RREG32(RADEON_CP_RB_WPTR);
-   /* protect against crazy HW on resume */
-   rdev->cp.wptr &= rdev->cp.ptr_mask;
/* Set cp mode to bus mastering & enable cp*/
WREG32(RADEON_CP_CSQ_MODE,
   REG_SET(RADEON_INDIRECT2_START, indirect2_start)

Re: [BUG] drm/radeon: locking problems with page_flip

2011-09-13 Thread Michel Dänzer 
On Die, 2011-09-13 at 05:49 +0200, Witold Baryluk wrote: 
> 
> I yeasterday discovered pretty nasty issue in radeon / drm code,
> and page_flip locking code on my ThinkPad T43.

Does the patch below fix the problem?


From ed7cf809c4fb737fa486b24004ee47056bf0e797 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= 
Date: Thu, 8 Sep 2011 17:36:22 +0200
Subject: [PATCH] drm/radeon: Unreference GEM object outside of spinlock
 in page flip error path.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Should fix https://bugzilla.redhat.com/show_bug.cgi?id=726277 .

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_display.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 6cc17fb..6adb3e5 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -473,8 +473,8 @@ pflip_cleanup:
spin_lock_irqsave(&dev->event_lock, flags);
radeon_crtc->unpin_work = NULL;
 unlock_free:
-   drm_gem_object_unreference_unlocked(old_radeon_fb->obj);
spin_unlock_irqrestore(&dev->event_lock, flags);
+   drm_gem_object_unreference_unlocked(old_radeon_fb->obj);
radeon_fence_unref(&work->fence);
kfree(work);
 
-- 
1.7.5.4

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40826] New: RV_770/90 regression by - r600g: simplify deducing chip family

2011-09-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=40826

   Summary: RV_770/90 regression by - r600g: simplify deducing
chip family
   Product: Mesa
   Version: unspecified
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: li...@andyfurniss.entadsl.com


rv_770 (it's a 790 really) all mesa demos I've tried misrender in some way
since -

commit 915227b0aa228fd203618adbb35930e994658087
Author: Marek Olšák 
Date:   Sun Sep 11 14:57:55 2011 +0200

r600g: simplify deducing chip family

reverting this + power cycle to resolve card state fixes.

-- 
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 40826] RV_770/90 regression by - r600g: simplify deducing chip family

2011-09-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=40826

--- Comment #1 from Marek Olšák  2011-09-13 04:10:29 PDT ---
This should be fixed now in Mesa master, can you test?

-- 
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 40826] RV_770/90 regression by - r600g: simplify deducing chip family

2011-09-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=40826

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Andy Furniss  2011-09-13 
04:35:54 PDT ---
OK now, thanks.

-- 
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 2/7] ttm: Introduce ttm_page_alloc_func structure.

2011-09-13 Thread Konrad Rzeszutek Wilk 
Which has the function members for all of the current page pool
operations defined. The old calls (ttm_put_pages, ttm_get_pages, etc)
are plumbed through little functions which lookup in the ttm_page_alloc_func
the appropiate implementation and call it.

There is currently only one page pool code so the default registration
goes to 'ttm_page_alloc_default'. The subsequent patch
"ttm: Provide a DMA aware TTM page pool code." introduces the one
to be used when the SWIOTLB code is turned on (that implementation
is a union of the default TTM pool code with the DMA pool code).

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/ttm/ttm_memory.c |3 ++
 drivers/gpu/drm/ttm/ttm_page_alloc.c |   58 
 include/drm/ttm/ttm_page_alloc.h |   60 ++
 3 files changed, 113 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index e70ddd8..c7d97a5 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -356,6 +356,8 @@ static int ttm_mem_init_dma32_zone(struct ttm_mem_global 
*glob,
 }
 #endif
 
+struct ttm_page_alloc_func *ttm_page_alloc;
+
 int ttm_mem_global_init(struct ttm_mem_global *glob)
 {
struct sysinfo si;
@@ -394,6 +396,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
   "Zone %7s: Available graphics memory: %llu kiB.\n",
   zone->name, (unsigned long long) zone->max_mem >> 10);
}
+   ttm_page_alloc = &ttm_page_alloc_default;
ttm_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE));
return 0;
 out_no_zone:
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index d948575..6a888f8 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -664,9 +664,9 @@ out:
  * On success pages list will hold count number of correctly
  * cached pages.
  */
-int ttm_get_pages(struct list_head *pages, int flags,
- enum ttm_caching_state cstate, unsigned count,
- dma_addr_t *dma_address)
+int __ttm_get_pages(struct list_head *pages, int flags,
+   enum ttm_caching_state cstate, unsigned count,
+   dma_addr_t *dma_address)
 {
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct page *p = NULL;
@@ -734,8 +734,8 @@ int ttm_get_pages(struct list_head *pages, int flags,
 }
 
 /* Put all pages in pages list to correct pool to wait for reuse */
-void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
-  enum ttm_caching_state cstate, dma_addr_t *dma_address)
+void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
+enum ttm_caching_state cstate, dma_addr_t *dma_address)
 {
unsigned long irq_flags;
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
@@ -785,7 +785,7 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool 
*pool, int flags,
pool->name = name;
 }
 
-int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
+int __ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 {
int ret;
 
@@ -822,7 +822,7 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
return 0;
 }
 
-void ttm_page_alloc_fini(void)
+void __ttm_page_alloc_fini(void)
 {
int i;
 
@@ -836,7 +836,7 @@ void ttm_page_alloc_fini(void)
_manager = NULL;
 }
 
-int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
+int __ttm_page_alloc_debugfs(struct seq_file *m, void *data)
 {
struct ttm_page_pool *p;
unsigned i;
@@ -856,4 +856,46 @@ int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
}
return 0;
 }
+
+struct ttm_page_alloc_func ttm_page_alloc_default = {
+   .get_pages  = __ttm_get_pages,
+   .put_pages  = __ttm_put_pages,
+   .alloc_init = __ttm_page_alloc_init,
+   .alloc_fini = __ttm_page_alloc_fini,
+   .debugfs= __ttm_page_alloc_debugfs,
+};
+
+int ttm_get_pages(struct list_head *pages, int flags,
+ enum ttm_caching_state cstate, unsigned count,
+ dma_addr_t *dma_address)
+{
+   if (ttm_page_alloc && ttm_page_alloc->get_pages)
+   return ttm_page_alloc->get_pages(pages, flags, cstate, count,
+dma_address);
+   return -1;
+}
+void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
+  enum ttm_caching_state cstate, dma_addr_t *dma_address)
+{
+   if (ttm_page_alloc && ttm_page_alloc->put_pages)
+   ttm_page_alloc->put_pages(pages, page_count, flags, cstate,
+ dma_address);
+}
+int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
+{
+   if (ttm

[PATCH] TTM DMA v1.8

2011-09-13 Thread Konrad Rzeszutek Wilk 
Since v1.7: [https://lkml.org/lkml/2011/8/30/460]
 - Fixed checking the DMA address in radeon/nouveau code.
Since v1: [http://lwn.net/Articles/456246/]
 - Ran it through the gauntlet of SubmitChecklist and fixed issues
 - Made radeon/nouveau driver set coherent_dma (which is required for dmapool)

[.. and this is what I said in v1 post]:

Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.

After a bit of discussion on the mailing list
http://marc.info/?i=4d769726.2030...@shipmail.org I started working on it, but
got waylaid by other things .. and finally I am able to post the RFC patches.

There was a lot of discussion about it and I am not sure if I captured
everybody's thoughts - if I did not - that is _not_ intentional - it has just
been quite some time..

Anyhow .. the patches explore what the "lib/dmapool.c" does - which is to have a
DMA pool that the device has associated with. I kind of married that code
along with drivers/gpu/drm/ttm/ttm_page_alloc.c to create a TTM DMA pool code.
The end result is DMA pool with extra features: can do write-combine, uncached,
writeback (and tracks them and sets back to WB when freed); tracks "cached"
pages that don't really need to be returned to a pool; and hooks up to
the shrinker code so that the pools can be shrunk.

If you guys think this set of patches make sense  - my future plans were
 1) Get this in large crowd of testing .. and if it works for a kernel release
 2) to move a bulk of this in the lib/dmapool.c (I spoke with Matthew Wilcox
about it and he is OK as long as I don't introduce performance regressions).

But before I do any of that a second set of eyes taking a look at these
patches would be most welcome.

In regards to testing, I've been running them non-stop for the last two weeks
(and found some issues which I've fixed up) - and been quite happy with how
they work. I finally got my Intel VT-d box online so will test that shortly.

Michel (thanks!) took a spin of the patches on his PowerPC and they did not
cause any regressions (wheew).

The patches are also located in a git tree:

 git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v1.8

 drivers/gpu/drm/nouveau/nouveau_mem.c|8 +-
 drivers/gpu/drm/nouveau/nouveau_sgdma.c  |3 +-
 drivers/gpu/drm/radeon/radeon_device.c   |6 +
 drivers/gpu/drm/radeon/radeon_gart.c |4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c  |3 +-
 drivers/gpu/drm/ttm/Makefile |3 +
 drivers/gpu/drm/ttm/ttm_bo.c |4 +-
 drivers/gpu/drm/ttm/ttm_memory.c |5 +
 drivers/gpu/drm/ttm/ttm_page_alloc.c |   63 ++-
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1317 ++
 drivers/gpu/drm/ttm/ttm_tt.c |5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |4 +-
 drivers/xen/swiotlb-xen.c|2 +-
 include/drm/ttm/ttm_bo_driver.h  |7 +-
 include/drm/ttm/ttm_page_alloc.h |  100 +++-
 include/linux/swiotlb.h  |7 +-
 lib/swiotlb.c|5 +-
 17 files changed, 1516 insertions(+), 30 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device.

2011-09-13 Thread Konrad Rzeszutek Wilk 
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-
 drivers/gpu/drm/radeon/radeon_ttm.c   |3 ++-
 drivers/gpu/drm/ttm/ttm_bo.c  |4 +++-
 drivers/gpu/drm/ttm/ttm_page_alloc.c  |   17 ++---
 drivers/gpu/drm/ttm/ttm_tt.c  |5 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |4 ++--
 include/drm/ttm/ttm_bo_driver.h   |7 ++-
 include/drm/ttm/ttm_page_alloc.h  |   16 
 8 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c 
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 5ee14d2..a2d7e35 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -417,7 +417,8 @@ nouveau_mem_vram_init(struct drm_device *dev)
ret = ttm_bo_device_init(&dev_priv->ttm.bdev,
 dev_priv->ttm.bo_global_ref.ref.object,
 &nouveau_bo_driver, DRM_FILE_PAGE_OFFSET,
-dma_bits <= 32 ? true : false);
+dma_bits <= 32 ? true : false,
+dev->dev);
if (ret) {
NV_ERROR(dev, "Error initialising bo driver: %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 60125dd..dbc6bcb 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -517,7 +517,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
r = ttm_bo_device_init(&rdev->mman.bdev,
   rdev->mman.bo_global_ref.ref.object,
   &radeon_bo_driver, DRM_FILE_PAGE_OFFSET,
-  rdev->need_dma32);
+  rdev->need_dma32,
+  rdev->dev);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2e618b5..0358889 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1527,12 +1527,14 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
   struct ttm_bo_global *glob,
   struct ttm_bo_driver *driver,
   uint64_t file_page_offset,
-  bool need_dma32)
+  bool need_dma32,
+  struct device *dev)
 {
int ret = -EINVAL;
 
rwlock_init(&bdev->vm_lock);
bdev->driver = driver;
+   bdev->dev = dev;
 
memset(bdev->man, 0, sizeof(bdev->man));
 
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 6a888f8..f9a4d83 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -666,7 +666,7 @@ out:
  */
 int __ttm_get_pages(struct list_head *pages, int flags,
enum ttm_caching_state cstate, unsigned count,
-   dma_addr_t *dma_address)
+   dma_addr_t *dma_address, struct device *dev)
 {
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct page *p = NULL;
@@ -724,7 +724,8 @@ int __ttm_get_pages(struct list_head *pages, int flags,
printk(KERN_ERR TTM_PFX
   "Failed to allocate extra pages "
   "for large request.");
-   ttm_put_pages(pages, 0, flags, cstate, NULL);
+   ttm_put_pages(pages, 0, flags, cstate, dma_address,
+ dev);
return r;
}
}
@@ -735,7 +736,8 @@ int __ttm_get_pages(struct list_head *pages, int flags,
 
 /* Put all pages in pages list to correct pool to wait for reuse */
 void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
-enum ttm_caching_state cstate, dma_addr_t *dma_address)
+enum ttm_caching_state cstate, dma_addr_t *dma_address,
+struct device *dev)
 {
unsigned long irq_flags;
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
@@ -867,19 +869,20 @@ struct ttm_page_alloc_func ttm_page_alloc_default = {
 
 int ttm_get_pages(struct list_head *pages, int flags,
  enum ttm_caching_state cstate, unsigned count,
- dma_addr_t *dma_address)
+ dma_addr_t *dma_address, struct device *dev)
 {
if (ttm_page_alloc && ttm_page_alloc->get_pages)
return ttm_page_alloc->get_pages(pages, flags, cstate, count,
-dma_a

[PATCH 7/7] nouveau/radeon: Set coherent DMA mask

2011-09-13 Thread Konrad Rzeszutek Wilk 
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/nouveau/nouveau_mem.c  |5 +
 drivers/gpu/drm/radeon/radeon_device.c |6 ++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c 
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index a2d7e35..bb6ccbd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -408,6 +408,11 @@ nouveau_mem_vram_init(struct drm_device *dev)
if (ret)
return ret;
 
+   ret = pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(dma_bits));
+   if (ret) {
+   /* Reset to default value. */
+   pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(32));
+   }
dev_priv->fb_phys = pci_resource_start(dev->pdev, 1);
 
ret = nouveau_ttm_global_init(dev_priv);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 7cfaa7e..0c0a970 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -757,8 +757,14 @@ int radeon_device_init(struct radeon_device *rdev,
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
rdev->need_dma32 = true;
+   dma_bits = 32;
printk(KERN_WARNING "radeon: No suitable DMA available.\n");
}
+   r = pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
+   if (r) {
+   pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(32));
+   printk(KERN_WARNING "radeon: No coherent DMA available.\n");
+   }
 
/* Registers mapping */
/* TODO: block userspace mapping of io register */
-- 
1.7.4.1

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

[PATCH 6/7] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime.

2011-09-13 Thread Konrad Rzeszutek Wilk 
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.

In the future this parameter can be removed.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4 
 include/drm/ttm/ttm_page_alloc.h |4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 5a5739c..5909d28 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -51,6 +51,10 @@
 #include 
 #endif
 
+int __read_mostly dma_ttm_disable;
+MODULE_PARM_DESC(no_dma, "Disable TTM DMA pool");
+module_param_named(no_dma, dma_ttm_disable, bool, S_IRUGO);
+
 #define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *))
 #define SMALL_ALLOCATION   16
 #define FREE_ALL_PAGES (~0U)
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 192c5f8..e75af77 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -103,10 +103,10 @@ extern struct ttm_page_alloc_func ttm_page_alloc_default;
 #ifdef CONFIG_SWIOTLB
 /* Defined in ttm_page_alloc_dma.c */
 extern struct ttm_page_alloc_func ttm_page_alloc_dma;
-
+extern int dma_ttm_disable;
 static inline bool ttm_page_alloc_need_dma(void)
 {
-   if (swiotlb_enabled()) {
+   if (!dma_ttm_disable && swiotlb_enabled()) {
ttm_page_alloc = &ttm_page_alloc_dma;
return true;
}
-- 
1.7.4.1

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

[PATCH 4/7] swiotlb: Expose swiotlb_nr_tlb function to modules as swiotlb_enabled

2011-09-13 Thread Konrad Rzeszutek Wilk 
As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.

We also fix the spelling - it was swioltb instead of
swiotlb.

CC: FUJITA Tomonori 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/swiotlb-xen.c |2 +-
 include/linux/swiotlb.h   |7 ++-
 lib/swiotlb.c |5 +++--
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6e8c15a..cbcd8cc 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -149,7 +149,7 @@ void __init xen_swiotlb_init(int verbose)
int rc;
unsigned long nr_tbl;
 
-   nr_tbl = swioltb_nr_tbl();
+   nr_tbl = swiotlb_nr_tbl();
if (nr_tbl)
xen_io_tlb_nslabs = nr_tbl;
else {
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 445702c..014ff53 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -24,7 +24,12 @@ extern int swiotlb_force;
 
 extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int 
verbose);
-extern unsigned long swioltb_nr_tbl(void);
+extern unsigned long swiotlb_nr_tbl(void);
+
+static inline bool swiotlb_enabled(void)
+{
+   return !!swiotlb_nr_tbl();
+}
 
 /*
  * Enumeration for sync targets
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 99093b3..058935e 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -110,11 +110,11 @@ setup_io_tlb_npages(char *str)
 __setup("swiotlb=", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
-unsigned long swioltb_nr_tbl(void)
+unsigned long swiotlb_nr_tbl(void)
 {
return io_tlb_nslabs;
 }
-
+EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
  volatile void *address)
@@ -321,6 +321,7 @@ void __init swiotlb_free(void)
free_bootmem_late(__pa(io_tlb_start),
  PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
}
+   io_tlb_nslabs = 0;
 }
 
 static int is_swiotlb_buffer(phys_addr_t paddr)
-- 
1.7.4.1

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

[PATCH 1/7] ttm/radeon/nouveau: Check the DMA address from TTM against known value.

2011-09-13 Thread Konrad Rzeszutek Wilk 
. instead of checking against the DMA_ERROR_CODE value which is
per-platform specific. The zero value is a known invalid value
that the TTM layer sets on the dma_address array if it is not
used (ttm_tt_alloc_page_directory calls drm_calloc_large which
creates a page with GFP_ZERO).

We can't use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).

Also update the comments in the header about the true state
of that parameter.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 +--
 drivers/gpu/drm/radeon/radeon_gart.c|4 +---
 include/drm/ttm/ttm_page_alloc.h|4 ++--
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c 
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 82fad91..9b570c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -42,8 +42,7 @@ nouveau_sgdma_populate(struct ttm_backend *be, unsigned long 
num_pages,
 
nvbe->nr_pages = 0;
while (num_pages--) {
-   /* this code path isn't called and is incorrect anyways */
-   if (0) { /*dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE)*/
+   if (dma_addrs[nvbe->nr_pages] != 0) {
nvbe->pages[nvbe->nr_pages] =
dma_addrs[nvbe->nr_pages];
nvbe->ttm_alloced[nvbe->nr_pages] = true;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index a533f52..068ba09 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -181,9 +181,7 @@ int radeon_gart_bind(struct radeon_device *rdev, unsigned 
offset,
p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
 
for (i = 0; i < pages; i++, p++) {
-   /* we reverted the patch using dma_addr in TTM for now but this
-* code stops building on alpha so just comment it out for now 
*/
-   if (0) { /*dma_addr[i] != DMA_ERROR_CODE) */
+   if (dma_addr[i] != 0) {
rdev->gart.ttm_alloced[p] = true;
rdev->gart.pages_addr[p] = dma_addr[i];
} else {
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 8062890..0017b17 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -36,7 +36,7 @@
  * @flags: ttm flags for page allocation.
  * @cstate: ttm caching state for the page.
  * @count: number of pages to allocate.
- * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set).
+ * @dma_address: The DMA (bus) address of pages - (by default zero).
  */
 int ttm_get_pages(struct list_head *pages,
  int flags,
@@ -51,7 +51,7 @@ int ttm_get_pages(struct list_head *pages,
  * count.
  * @flags: ttm flags for page allocation.
  * @cstate: ttm caching state.
- * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set).
+ * @dma_address: The DMA (bus) address of pages (by default zero).
  */
 void ttm_put_pages(struct list_head *pages,
   unsigned page_count,
-- 
1.7.4.1

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

Re: PGRAPH: unsupported chipset

2011-09-13 Thread Sérgio Basto 
Hi wiebittewas, dri-de...@lists.sourceforge.net, is the old ML
dri-devel@lists.freedesktop.org, is the new dri-devel. 
So I am redirect the email ...  

On Mon, 2011-09-12 at 22:17 +0200, wiebittewas wrote: 
> Hi!
> 
> here's a latop with a nvidia quadro 1000M, where the nouveau-driver
> tells on startup "PGRAPH: unsupported chipset, please report", which
> I'll do now. (this list was the only address I've found within the code)
> 
> because I haven't found any info, what information I should report, I'll
> try it:
> 
> a short patch gives, that the requested value would be 0xc1
> 
> here's the full lspci-out:
> ==
> 01:00.0 VGA compatible controller [0300]: nVidia Corporation Device
> [10de:0dfa] (rev a1) (prog-if 00 [VGA controller])
>   Subsystem: Dell Device [1028:14a3]
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0, Cache Line Size: 64 bytes
>   Interrupt: pin A routed to IRQ 16
>   Region 0: Memory at ec00 (32-bit, non-prefetchable) [size=16M]
>   Region 1: Memory at e000 (64-bit, prefetchable) [size=128M]
>   Region 3: Memory at e800 (64-bit, prefetchable) [size=32M]
>   Region 5: I/O ports at 7000 [size=128]
>   Expansion ROM at ed00 [disabled] [size=512K]
>   Capabilities: [60] Power Management version 3
>   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>   Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>   Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
>   Address:   Data: 
>   Capabilities: [78] Express (v1) Endpoint, MSI 00
>   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 
> unlimited, L1 <64us
>   ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
> Unsupported-
>   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>   MaxPayload 128 bytes, MaxReadReq 512 bytes
>   DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
> TransPend-
>   LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency 
> L0
> <256ns, L1 <4us
>   ClockPM+ Surprise- LLActRep- BwNot-
>   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>   LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive-
> BWMgmt- ABWMgmt-
>   Capabilities: [b4] Vendor Specific Information: Len=14 
>   Capabilities: [100 v1] Virtual Channel
>   Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>   Arb:Fixed- WRR32- WRR64- WRR128-
>   Ctrl:   ArbSelect=Fixed
>   Status: InProgress-
>   VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>   Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>   Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
>   Status: NegoPending- InProgress-
>   Capabilities: [128 v1] Power Budgeting 
>   Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1
> Len=024 
>   Kernel driver in use: nouveau
>   Kernel modules: nouveau, nvidiafb
> ==
> if you want more information, please tell me, how I'll extract it.
> 
> best regards
> 
> wiebittewas
> 
> 
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the 
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1 
> --
> ___
> Dri-devel mailing list
> dri-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel

-- 
Sérgio M. B.

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

Re: [PATCH] drm/radeon: Don't read from CP ring write pointer registers.

2011-09-13 Thread Alex Deucher 
2011/9/13 Michel Dänzer :
> From: Michel Dänzer 
>
> Apparently this doesn't always work reliably, e.g. at resume time.
>
> Just initialize to 0, so the ring is considered empty.
>
> Tested with hibernation on Sumo and Cayman cards.
>
> Should fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ .
>
> Signed-off-by: Michel Dänzer 

Looks good to me.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/evergreen.c |    4 ++--
>  drivers/gpu/drm/radeon/ni.c        |   12 ++--
>  drivers/gpu/drm/radeon/r100.c      |    6 ++
>  drivers/gpu/drm/radeon/r600.c      |    4 ++--
>  4 files changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 15bd047..f2bd90a 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1378,7 +1378,8 @@ int evergreen_cp_resume(struct radeon_device *rdev)
>        /* Initialize the ring buffer's read and write pointers */
>        WREG32(CP_RB_CNTL, tmp | RB_RPTR_WR_ENA);
>        WREG32(CP_RB_RPTR_WR, 0);
> -       WREG32(CP_RB_WPTR, 0);
> +       rdev->cp.wptr = 0;
> +       WREG32(CP_RB_WPTR, rdev->cp.wptr);
>
>        /* set the wb address wether it's enabled or not */
>        WREG32(CP_RB_RPTR_ADDR,
> @@ -1403,7 +1404,6 @@ int evergreen_cp_resume(struct radeon_device *rdev)
>        WREG32(CP_DEBUG, (1 << 27) | (1 << 28));
>
>        rdev->cp.rptr = RREG32(CP_RB_RPTR);
> -       rdev->cp.wptr = RREG32(CP_RB_WPTR);
>
>        evergreen_cp_start(rdev);
>        rdev->cp.ready = true;
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 559dbd4..e3489ee 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1182,7 +1182,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
>
>        /* Initialize the ring buffer's read and write pointers */
>        WREG32(CP_RB0_CNTL, tmp | RB_RPTR_WR_ENA);
> -       WREG32(CP_RB0_WPTR, 0);
> +       rdev->cp.wptr = 0;
> +       WREG32(CP_RB0_WPTR, rdev->cp.wptr);
>
>        /* set the wb address wether it's enabled or not */
>        WREG32(CP_RB0_RPTR_ADDR, (rdev->wb.gpu_addr + 
> RADEON_WB_CP_RPTR_OFFSET) & 0xFFFC);
> @@ -1202,7 +1203,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
>        WREG32(CP_RB0_BASE, rdev->cp.gpu_addr >> 8);
>
>        rdev->cp.rptr = RREG32(CP_RB0_RPTR);
> -       rdev->cp.wptr = RREG32(CP_RB0_WPTR);
>
>        /* ring1  - compute only */
>        /* Set ring buffer size */
> @@ -1215,7 +1215,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
>
>        /* Initialize the ring buffer's read and write pointers */
>        WREG32(CP_RB1_CNTL, tmp | RB_RPTR_WR_ENA);
> -       WREG32(CP_RB1_WPTR, 0);
> +       rdev->cp1.wptr = 0;
> +       WREG32(CP_RB1_WPTR, rdev->cp1.wptr);
>
>        /* set the wb address wether it's enabled or not */
>        WREG32(CP_RB1_RPTR_ADDR, (rdev->wb.gpu_addr + 
> RADEON_WB_CP1_RPTR_OFFSET) & 0xFFFC);
> @@ -1227,7 +1228,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
>        WREG32(CP_RB1_BASE, rdev->cp1.gpu_addr >> 8);
>
>        rdev->cp1.rptr = RREG32(CP_RB1_RPTR);
> -       rdev->cp1.wptr = RREG32(CP_RB1_WPTR);
>
>        /* ring2 - compute only */
>        /* Set ring buffer size */
> @@ -1240,7 +1240,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
>
>        /* Initialize the ring buffer's read and write pointers */
>        WREG32(CP_RB2_CNTL, tmp | RB_RPTR_WR_ENA);
> -       WREG32(CP_RB2_WPTR, 0);
> +       rdev->cp2.wptr = 0;
> +       WREG32(CP_RB2_WPTR, rdev->cp2.wptr);
>
>        /* set the wb address wether it's enabled or not */
>        WREG32(CP_RB2_RPTR_ADDR, (rdev->wb.gpu_addr + 
> RADEON_WB_CP2_RPTR_OFFSET) & 0xFFFC);
> @@ -1252,7 +1253,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
>        WREG32(CP_RB2_BASE, rdev->cp2.gpu_addr >> 8);
>
>        rdev->cp2.rptr = RREG32(CP_RB2_RPTR);
> -       rdev->cp2.wptr = RREG32(CP_RB2_WPTR);
>
>        /* start the rings */
>        cayman_cp_start(rdev);
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index f2204cb..11e44a3 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -990,7 +990,8 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
> ring_size)
>        /* Force read & write ptr to 0 */
>        WREG32(RADEON_CP_RB_CNTL, tmp | RADEON_RB_RPTR_WR_ENA | 
> RADEON_RB_NO_UPDATE);
>        WREG32(RADEON_CP_RB_RPTR_WR, 0);
> -       WREG32(RADEON_CP_RB_WPTR, 0);
> +       rdev->cp.wptr = 0;
> +       WREG32(RADEON_CP_RB_WPTR, rdev->cp.wptr);
>
>        /* set the wb address whether it's enabled or not */
>        WREG32(R_00070C_CP_RB_RPTR_ADDR,
> @@ -1007,9 +1008,6 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
> ring_size)
>        WREG32(RADEON_CP_RB_CNTL, tmp);
>        udelay(10);
>        rdev->cp.rptr = RREG32(RADEON_CP_RB_RPTR);
> -       rdev->cp.wptr = RREG32(RADEON_CP_RB_WPTR);
>

[PATCH] drm/ttm: request zeroed system memory pages for new TT buffer objects

2011-09-13 Thread skeggsb 
From: Ben Skeggs 

Fixes an information leak to userspace, we were handing out un-zeroed pages
for any newly created TTM_PL_TT buffer.

Reported-by: Marcin Slusarz 
Signed-off-by: Ben Skeggs 
Tested-by: Marcin Slusarz 
Cc: sta...@kernel.org
---
 drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a4d38d8..ef06194 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -394,7 +394,8 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
 
if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
if (bo->ttm == NULL) {
-   ret = ttm_bo_add_ttm(bo, false);
+   bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
+   ret = ttm_bo_add_ttm(bo, zero);
if (ret)
goto out_err;
}
-- 
1.7.6.1

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

[Bug 36934] screen corruption after running a game

2011-09-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #11 from almos  2011-09-13 14:59:31 PDT ---
(In reply to comment #10)
> (In reply to comment #7)
> > A couple of random things to try would be radeon.agpmode=4 and =-1, 
> > disabling
> > tiling, ...
> 
> Have you tried any of these?

Now I tried radeon.agpmode=-1 for a couple of days, but this issue didn't
appear. I could only reproduce the corruption of the image mentioned in comment
9. Usually it takes several days of uptime for the corruption to start to
appear noticeably, so the experiment might have been too short. I'll try it
again later.

-- 
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 40790] r600g readPixSanity failure on RS880 Radeon HD 4250

2011-09-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=40790

Nicholas Miell  changed:

   What|Removed |Added

  Attachment #51059|0   |1
is obsolete||

--- Comment #2 from Nicholas Miell  2011-09-13 15:38:19 PDT 
---
Created an attachment (id=51166)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51166)
updated results

With http://lists.freedesktop.org/archives/mesa-dev/2011-September/011977.html
applied, the DRI2SwapBuffers error goes away and there's opportunity to fail
even more tests.

-- 
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 v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-13 Thread Inki Dae 
Hi Thomas.
Sorry for being late.

> -Original Message-
> From: Thomas Hellstrom [mailto:tho...@shipmail.org]
> Sent: Saturday, September 10, 2011 11:04 PM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> sw0312@samsung.com; kyungmin.p...@samsung.com; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> 
> On 09/09/2011 01:38 PM, Inki Dae wrote:
> > This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
> > only FIMD yet but we will add HDMI support also in the future.
> >
> > from now on, I will remove RFC prefix because I think we have got
> comments
> > enough.
> >
> > this patch is based on git repository below:
> > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
> > branch name: drm-next
> > commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> >
> > you can refer to our working repository below:
> > http://git.infradead.org/users/kmpark/linux-2.6-samsung
> > branch name: samsung-drm
> >
> > We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
> > based on Linux framebuffer) but couldn't so because lowlevel codes
> > of s3c-fb.c are included internally and so FIMD module of this driver
> has
> > its own lowlevel codes.
> >
> > We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
> > for buffer allocation. by using DMA API, we could use CMA later.
> >
> > Refer to this link for CMA(Continuous Memory Allocator):
> > http://lkml.org/lkml/2011/7/20/45
> >
> > this driver supports only physically continuous memory(non-iommu).
> >
> > Links to previous versions of the patchset:
> > v1:<  https://lwn.net/Articles/454380/>
> > v2:<  http://www.spinics.net/lists/kernel/msg1224275.html>
> > v3:<  http://www.gossamer-threads.com/lists/linux/kernel/1423684>
> >
> > Changelog v2:
> > DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> >
> >  this feature maps user address space to physical memory region
> >  once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
> >
> > DRM: code clean and add exception codes.
> >
> > Changelog v3:
> > DRM: Support multiple irq.
> >
> >  FIMD and HDMI have their own irq handler but DRM Framework can
> regiter
> >  only one irq handler this patch supports mutiple irq for Samsung
SoC.
> >
> > DRM: Consider modularization.
> >
> >  each DRM, FIMD could be built as a module.
> >
> > DRM: Have indenpendent crtc object.
> >
> >  crtc isn't specific to SoC Platform so this patch gets a crtc
> >  to be used as common object.
> >  created crtc could be attached to any encoder object.
> >
> > DRM: code clean and add exception codes.
> >
> > Changelog v4:
> > DRM: remove is_defult from samsung_fb.
> >
> >  is_default isn't used for default framebuffer.
> >
> > DRM: code refactoring to fimd module.
> >  this patch is be considered with multiple display objects and
> >  would use its own request_irq() to register a irq handler instead
of
> >  drm framework's one.
> >
> > DRM: remove find_samsung_drm_gem_object()
> >
> > DRM: move kernel private data structures and definitions to driver
> folder.
> >
> >  samsung_drm.h would contain only public information for userspace
> >  ioctl interface.
> >
> > DRM: code refactoring to gem modules.
> >  buffer module isn't dependent of gem module anymore.
> >
> > DRM: fixed security issue.
> >
> > DRM: remove encoder porinter from specific connector.
> >
> >  samsung connector doesn't need to have generic encoder.
> >
> > DRM: code clean and add exception codes.
> >
> > Signed-off-by: Inki Dae
> > Signed-off-by: Joonyoung Shim
> > Signed-off-by: SeungWoo Kim
> > Signed-off-by: kyungmin.park
> > ---
> >
> > +static struct drm_ioctl_desc samsung_ioctls[] = {
> > +   DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE, samsung_drm_gem_create_ioctl,
> > +   DRM_UNLOCKED | DRM_AUTH),
> >
> 
> Hi!
> 
> With reference my previous security comment.
> 
> Let's say you have a compromised video player running as a DRM client,
> that tries to repeatedly allocate huge GEM buffers...
> 
> What will happen when all DMA memory is exhausted? Will this cause other
> device drivers to see an OOM, or only DRM?
> 

Out driver allocates physically continuous memory from the region reserved
by CMA or DMA Region in case of not using CMA. if all memory is exhausted at
allocation moment, it just returns "Allocation fail" and then the
application would be terminated.

> The old DRI model basically allowed any authorized DRI client to exhaust
> video ram or AGP memory, but never system memory. Newer DRI drivers
> typically only allow DRI masters to do that.
> as
> 

I thought it's enough for an authorized DRI client to request memory
allocation. because an authorized DRI client has root authority. I know, in
case of v4l2 based device drivers, the applications can request buffer
allocation through v4l2 interface, REQBUFS. and also if memory allocation is

RE: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-13 Thread Inki Dae 
Hi Thomas.

> -Original Message-
> From: Thomas Hellstrom [mailto:tho...@shipmail.org]
> Sent: Monday, September 12, 2011 3:32 PM
> To: Rob Clark
> Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; linux-
> arm-ker...@lists.infradead.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> 
> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
> > On 09/10/2011 07:31 PM, Rob Clark wrote:
> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
> >> Hellstrom  wrote:
> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
>  This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
>  only FIMD yet but we will add HDMI support also in the future.
> 
>  from now on, I will remove RFC prefix because I think we have got
>  comments
>  enough.
> 
>  this patch is based on git repository below:
>  git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>  branch name: drm-next
>  commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> 
>  you can refer to our working repository below:
>  http://git.infradead.org/users/kmpark/linux-2.6-samsung
>  branch name: samsung-drm
> 
>  We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>  based on Linux framebuffer) but couldn't so because lowlevel codes
>  of s3c-fb.c are included internally and so FIMD module of this
>  driver has
>  its own lowlevel codes.
> 
>  We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
>  for buffer allocation. by using DMA API, we could use CMA later.
> 
>  Refer to this link for CMA(Continuous Memory Allocator):
>  http://lkml.org/lkml/2011/7/20/45
> 
>  this driver supports only physically continuous memory(non-iommu).
> 
>  Links to previous versions of the patchset:
>  v1:
>  v2:
>  v3:
> 
>  Changelog v2:
>  DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> 
>   this feature maps user address space to physical memory region
>   once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
> 
>  DRM: code clean and add exception codes.
> 
>  Changelog v3:
>  DRM: Support multiple irq.
> 
>   FIMD and HDMI have their own irq handler but DRM Framework can
>  regiter
>   only one irq handler this patch supports mutiple irq for
>  Samsung SoC.
> 
>  DRM: Consider modularization.
> 
>   each DRM, FIMD could be built as a module.
> 
>  DRM: Have indenpendent crtc object.
> 
>   crtc isn't specific to SoC Platform so this patch gets a crtc
>   to be used as common object.
>   created crtc could be attached to any encoder object.
> 
>  DRM: code clean and add exception codes.
> 
>  Changelog v4:
>  DRM: remove is_defult from samsung_fb.
> 
>   is_default isn't used for default framebuffer.
> 
>  DRM: code refactoring to fimd module.
>   this patch is be considered with multiple display objects and
>   would use its own request_irq() to register a irq handler
>  instead of
>   drm framework's one.
> 
>  DRM: remove find_samsung_drm_gem_object()
> 
>  DRM: move kernel private data structures and definitions to driver
>  folder.
> 
>   samsung_drm.h would contain only public information for
userspace
>   ioctl interface.
> 
>  DRM: code refactoring to gem modules.
>   buffer module isn't dependent of gem module anymore.
> 
>  DRM: fixed security issue.
> 
>  DRM: remove encoder porinter from specific connector.
> 
>   samsung connector doesn't need to have generic encoder.
> 
>  DRM: code clean and add exception codes.
> 
>  Signed-off-by: Inki Dae
>  Signed-off-by: Joonyoung Shim
>  Signed-off-by: SeungWoo Kim
>  Signed-off-by: kyungmin.park
>  ---
> 
>  +static struct drm_ioctl_desc samsung_ioctls[] = {
>  +   DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>  samsung_drm_gem_create_ioctl,
>  +   DRM_UNLOCKED | DRM_AUTH),
> 
> >>> Hi!
> >>>
> >>> With reference my previous security comment.
> >>>
> >>> Let's say you have a compromised video player running as a DRM
> >>> client, that
> >>> tries to repeatedly allocate huge GEM buffers...
> >>>
> >>> What will happen when all DMA memory is exhausted? Will this cause
> >>> other
> >>> device drivers to see an OOM, or only DRM?
> >>>
> >>> The old DRI model basically allowed any authorized DRI client to
> >>> exhaust
> >>> video ram or AGP memory, but never system memory. Newer DRI drivers
> >>> typically only allow DRI masters to do that.
> >>> as
> >

Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-13 Thread Rob Clark 
On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae  wrote:
> Hi Thomas.
>
>> -Original Message-
>> From: Thomas Hellstrom [mailto:tho...@shipmail.org]
>> Sent: Monday, September 12, 2011 3:32 PM
>> To: Rob Clark
>> Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; linux-
>> arm-ker...@lists.infradead.org; dri-devel@lists.freedesktop.org
>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>
>> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
>> > On 09/10/2011 07:31 PM, Rob Clark wrote:
>> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
>> >> Hellstrom  wrote:
>> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
>>  This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
>>  only FIMD yet but we will add HDMI support also in the future.
>> 
>>  from now on, I will remove RFC prefix because I think we have got
>>  comments
>>  enough.
>> 
>>  this patch is based on git repository below:
>>  git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>>  branch name: drm-next
>>  commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
>> 
>>  you can refer to our working repository below:
>>  http://git.infradead.org/users/kmpark/linux-2.6-samsung
>>  branch name: samsung-drm
>> 
>>  We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>>  based on Linux framebuffer) but couldn't so because lowlevel codes
>>  of s3c-fb.c are included internally and so FIMD module of this
>>  driver has
>>  its own lowlevel codes.
>> 
>>  We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
>>  for buffer allocation. by using DMA API, we could use CMA later.
>> 
>>  Refer to this link for CMA(Continuous Memory Allocator):
>>  http://lkml.org/lkml/2011/7/20/45
>> 
>>  this driver supports only physically continuous memory(non-iommu).
>> 
>>  Links to previous versions of the patchset:
>>  v1:<    https://lwn.net/Articles/454380/>
>>  v2:<    http://www.spinics.net/lists/kernel/msg1224275.html>
>>  v3:<    http://www.gossamer-threads.com/lists/linux/kernel/1423684>
>> 
>>  Changelog v2:
>>  DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
>> 
>>       this feature maps user address space to physical memory region
>>       once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
>> 
>>  DRM: code clean and add exception codes.
>> 
>>  Changelog v3:
>>  DRM: Support multiple irq.
>> 
>>       FIMD and HDMI have their own irq handler but DRM Framework can
>>  regiter
>>       only one irq handler this patch supports mutiple irq for
>>  Samsung SoC.
>> 
>>  DRM: Consider modularization.
>> 
>>       each DRM, FIMD could be built as a module.
>> 
>>  DRM: Have indenpendent crtc object.
>> 
>>       crtc isn't specific to SoC Platform so this patch gets a crtc
>>       to be used as common object.
>>       created crtc could be attached to any encoder object.
>> 
>>  DRM: code clean and add exception codes.
>> 
>>  Changelog v4:
>>  DRM: remove is_defult from samsung_fb.
>> 
>>       is_default isn't used for default framebuffer.
>> 
>>  DRM: code refactoring to fimd module.
>>       this patch is be considered with multiple display objects and
>>       would use its own request_irq() to register a irq handler
>>  instead of
>>       drm framework's one.
>> 
>>  DRM: remove find_samsung_drm_gem_object()
>> 
>>  DRM: move kernel private data structures and definitions to driver
>>  folder.
>> 
>>       samsung_drm.h would contain only public information for
> userspace
>>       ioctl interface.
>> 
>>  DRM: code refactoring to gem modules.
>>       buffer module isn't dependent of gem module anymore.
>> 
>>  DRM: fixed security issue.
>> 
>>  DRM: remove encoder porinter from specific connector.
>> 
>>       samsung connector doesn't need to have generic encoder.
>> 
>>  DRM: code clean and add exception codes.
>> 
>>  Signed-off-by: Inki Dae
>>  Signed-off-by: Joonyoung Shim
>>  Signed-off-by: SeungWoo Kim
>>  Signed-off-by: kyungmin.park
>>  ---
>> 
>>  +static struct drm_ioctl_desc samsung_ioctls[] = {
>>  +       DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>>  samsung_drm_gem_create_ioctl,
>>  +                       DRM_UNLOCKED | DRM_AUTH),
>> 
>> >>> Hi!
>> >>>
>> >>> With reference my previous security comment.
>> >>>
>> >>> Let's say you have a compromised video player running as a DRM
>> >>> client, that
>> >>> tries to repeatedly allocate huge GEM buffers...
>> >>>
>> >>> What will happen when all DMA memory is exhausted? Will this cause
>> >>> other
>> >>> device drivers to see an OOM, or only DRM?
>> >>>
>> >>> The old DRI model basically allo

RE: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms

2011-09-13 Thread Inki Dae 
Hello Rob.
Sorry for being late. here was a national holiday.


> -Original Message-
> From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
> Clark
> Sent: Thursday, September 08, 2011 3:44 AM
> To: Inki Dae
> Cc: linaro-...@lists.linaro.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
> 
> On Wed, Sep 7, 2011 at 1:00 AM, Inki Dae  wrote:
> > Hello, Rob.
> >
> [snip]
> >> >> +static void page_flip_cb(void *arg)
> >> >> +{
> >> >> +     struct drm_crtc *crtc = arg;
> >> >> +     struct drm_device *dev = crtc->dev;
> >> >> +     struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> >> >> +     struct drm_pending_vblank_event *event = omap_crtc->event;
> >> >> +     struct timeval now;
> >> >> +     unsigned long flags;
> >> >> +
> >> >> +     WARN_ON(!event);
> >> >> +
> >> >> +     omap_crtc->event = NULL;
> >> >> +
> >> >> +     update_scanout(crtc);
> >> >> +     commit(crtc);
> >> >> +
> >> >> +     /* wakeup userspace */
> >> >> +     // TODO: this should happen *after* flip.. somehow..
> >> >> +     if (event) {
> >> >> +             spin_lock_irqsave(&dev->event_lock, flags);
> >> >> +             event->event.sequence =
> >> >> +                             drm_vblank_count_and_time(dev,
> >> > omap_crtc->id,
> >> >> &now);
> >> >> +             event->event.tv_sec = now.tv_sec;
> >> >> +             event->event.tv_usec = now.tv_usec;
> >> >> +             list_add_tail(&event->base.link,
> >> >> +                             &event->base.file_priv->event_list);
> >> >> +
> > wake_up_interruptible(&event->base.file_priv->event_wait);
> >> >> +             spin_unlock_irqrestore(&dev->event_lock, flags);
> >> >> +     }
> >> >
> >> > How about moving codes above into interrupt handler for vblank?
> >> >  maybe there
> >>
> >> I should mention a couple of things:
> >>
> >> 1) drm vblank stuff isn't really used currently.. it is actually DSS2
> >> layer that is registering for the display related interrupt(s).  I'm
> >> not really sure how to handle this best.  I suppose the DRM driver
> >> could *also* register for these interrupts, but that seems a bit odd..
> >>
> >
> > DRM Framework supports only one interrupt handler. this issue should be
> > resolved. and currently I made our driver to use its own request_irq,
> not
> > DRM Framework side. we only sets drm_device->irq_enabled to 1 and
> interrupt
> > handler is registered at display controller or hdmi driver respectively.
> but
> > I'm not sure that this way is best so I will look over more. Anyway
> current
> > drm framework should be fixed to be considered with multiple irq.
> 
> Or perhaps even callbacks (some other driver handling the irq's directly)?
> 

Yes.

> >> Also, I guess it is also worth mentioning.. when it comes to vblank,
> >> there are two fundamentally different sorts of displays we deal with.
> >> Something like DVI/HDMI/etc which need constant refreshing.  In these
> >> cases we constantly scan-out the buffer until the next page
> >> flip+vsync.  And smart panels, where they get scanned out once and
> >> then DSS is no longer reading the scanout buffer until we manually
> >> trigger an update.
> >>
> >
> > Is the Smart panel CPU interface based lcd panel that has its own
> > framebuffer internally.?
> 
> yes
> 

CPU Interface based lcd panel needs manual updating once all contents of
internal framebuffer are transferred to panel. thus, the Smart Panel(cpu
interface based lcd panel) has advantage of power consumption with
user-requested update. this means application should trigger display
controller to be transferred to lcd panel at framedone signal of lcd panel
because only the application is aware of this moment. this way would be
getting confused, especially on general os, such as linux system, based
platform so in case of using Smart Panel, I think we should make the panel
driver to be worked like RGB interface.

- framedone interrupt handler of the panel should be placed in the driver.
- at booting time, display controller driver triggers just one time
- the panel driver triggers every time framedone interrupt handler is
called.

and the order above would be repeated like RGB interface. thus I think we
could deal with the Smart Panel like RGB way.

> [snip]
> >>
> >> The main reason for the page-flip cb is actually not vsync
> >> synchronization, but rather synchronizing with other hw blocks that
> >> might be rendering to the buffer..  the page flip can be submitted
> >> from userspace while some other hw block (3d, 2d, etc) is still
> >> DMA'ing to the buffer.  The sync-obj is intended to give a way to
> >> defer the (in this case) page flip until other hw blocks are done
> >> writing to the buffer.
> >
> > I thought page-flip is used to change buffer register value of display
> > controller into another one like the Pan Display feature of linux
> > framebuffer. actually page flip interface of libdrm library,
> > page_flip_handler, is

RE: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-13 Thread Inki Dae 


> -Original Message-
> From: Rob Clark [mailto:robdcl...@gmail.com]
> Sent: Wednesday, September 14, 2011 11:26 AM
> To: Inki Dae
> Cc: Thomas Hellstrom; kyungmin.p...@samsung.com; sw0312@samsung.com;
> linux-arm-ker...@lists.infradead.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> 
> On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae  wrote:
> > Hi Thomas.
> >
> >> -Original Message-
> >> From: Thomas Hellstrom [mailto:tho...@shipmail.org]
> >> Sent: Monday, September 12, 2011 3:32 PM
> >> To: Rob Clark
> >> Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; linux-
> >> arm-ker...@lists.infradead.org; dri-devel@lists.freedesktop.org
> >> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> >>
> >> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
> >> > On 09/10/2011 07:31 PM, Rob Clark wrote:
> >> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
> >> >> Hellstrom  wrote:
> >> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
> >>  This patch is a DRM Driver for Samsung SoC Exynos4210 and now
> enables
> >>  only FIMD yet but we will add HDMI support also in the future.
> >> 
> >>  from now on, I will remove RFC prefix because I think we have got
> >>  comments
> >>  enough.
> >> 
> >>  this patch is based on git repository below:
> >>  git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
> >>  branch name: drm-next
> >>  commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> >> 
> >>  you can refer to our working repository below:
> >>  http://git.infradead.org/users/kmpark/linux-2.6-samsung
> >>  branch name: samsung-drm
> >> 
> >>  We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
> >>  based on Linux framebuffer) but couldn't so because lowlevel codes
> >>  of s3c-fb.c are included internally and so FIMD module of this
> >>  driver has
> >>  its own lowlevel codes.
> >> 
> >>  We used GEM framework for buffer management and DMA
> APIs(dma_alloc_*)
> >>  for buffer allocation. by using DMA API, we could use CMA later.
> >> 
> >>  Refer to this link for CMA(Continuous Memory Allocator):
> >>  http://lkml.org/lkml/2011/7/20/45
> >> 
> >>  this driver supports only physically continuous memory(non-iommu).
> >> 
> >>  Links to previous versions of the patchset:
> >>  v1:<    https://lwn.net/Articles/454380/>
> >>  v2:<    http://www.spinics.net/lists/kernel/msg1224275.html>
> >>  v3:<    http://www.gossamer-
> threads.com/lists/linux/kernel/1423684>
> >> 
> >>  Changelog v2:
> >>  DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> >> 
> >>       this feature maps user address space to physical memory
> region
> >>       once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP
> ioctl.
> >> 
> >>  DRM: code clean and add exception codes.
> >> 
> >>  Changelog v3:
> >>  DRM: Support multiple irq.
> >> 
> >>       FIMD and HDMI have their own irq handler but DRM Framework
> can
> >>  regiter
> >>       only one irq handler this patch supports mutiple irq for
> >>  Samsung SoC.
> >> 
> >>  DRM: Consider modularization.
> >> 
> >>       each DRM, FIMD could be built as a module.
> >> 
> >>  DRM: Have indenpendent crtc object.
> >> 
> >>       crtc isn't specific to SoC Platform so this patch gets a crtc
> >>       to be used as common object.
> >>       created crtc could be attached to any encoder object.
> >> 
> >>  DRM: code clean and add exception codes.
> >> 
> >>  Changelog v4:
> >>  DRM: remove is_defult from samsung_fb.
> >> 
> >>       is_default isn't used for default framebuffer.
> >> 
> >>  DRM: code refactoring to fimd module.
> >>       this patch is be considered with multiple display objects and
> >>       would use its own request_irq() to register a irq handler
> >>  instead of
> >>       drm framework's one.
> >> 
> >>  DRM: remove find_samsung_drm_gem_object()
> >> 
> >>  DRM: move kernel private data structures and definitions to driver
> >>  folder.
> >> 
> >>       samsung_drm.h would contain only public information for
> > userspace
> >>       ioctl interface.
> >> 
> >>  DRM: code refactoring to gem modules.
> >>       buffer module isn't dependent of gem module anymore.
> >> 
> >>  DRM: fixed security issue.
> >> 
> >>  DRM: remove encoder porinter from specific connector.
> >> 
> >>       samsung connector doesn't need to have generic encoder.
> >> 
> >>  DRM: code clean and add exception codes.
> >> 
> >>  Signed-off-by: Inki Dae
> >>  Signed-off-by: Joonyoung Shim
> >>  Signed-off-by: SeungWoo Kim
> >>  Signed-off-by: kyungmin.park
> >>  ---
> >> 
> >>  +static str

PGRAPH: unsupported chipset

2011-09-13 Thread wiebittewas 
Hi!

here's a latop with a nvidia quadro 1000M, where the nouveau-driver
tells on startup "PGRAPH: unsupported chipset, please report", which
I'll do now. (this list was the only address I've found within the code)

because I haven't found any info, what information I should report, I'll
try it:

a short patch gives, that the requested value would be 0xc1

here's the full lspci-out:
==
01:00.0 VGA compatible controller [0300]: nVidia Corporation Device
[10de:0dfa] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Dell Device [1028:14a3]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [100 v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [128 v1] Power Budgeting 
Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1
Len=024 
Kernel driver in use: nouveau
Kernel modules: nouveau, nvidiafb
==
if you want more information, please tell me, how I'll extract it.

best regards

wiebittewas


--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the 
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1 
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] drm/radeon: locking problems with page_flip

2011-09-13 Thread Witold Baryluk 
7.11-5
 free implementation of the EGL API -- hardware drivers
ii  libgl1-mesa-dri   7.11-5
 free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx   7.11-5
 free implementation of the OpenGL API -- GLX runtime
ii  libglapi-mesa 7.11-5
 free implementation of the GL API -- shared library
ii  libglu1-mesa  7.11-5
 Mesa OpenGL utility library (GLU)
ii  libopenvg1-mesa   7.11-5
 free implementation of the OpenVG API -- runtime
ii  libosmesa67.11-5
 Mesa Off-screen rendering extension
ii  mesa-utils8.0.1-2+b1
 Miscellaneous Mesa GL utilities
ii  xfwm4 4.8.1-4   
 window manager of the Xfce project
ii  xfce4 4.8.0.3   
 Meta-package for the Xfce Lightweight Desktop Environment
ii  xfdesktop44.8.2-2   
 xfce desktop background, icons and root menu manager


I was using clear xfce profile. It was create maybe
5 days ago.

Kernel config attached.

Regards,
Witek

-- 
Witold Baryluk
-- next part --
A non-text attachment was scrubbed...
Name: config-3.1.0-rc5-t43-prod-00079-ged2888e-dirty.gz
Type: application/octet-stream
Size: 19044 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110913/39829648/attachment-0001.obj>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110913/39829648/attachment-0001.pgp>

[PATCH 2/6] drm/i915: use common functions for mmap offset creation

2011-09-13 Thread Daniel Vetter 
On Mon, Sep 12, 2011 at 02:21:22PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 5/6] drm/i915: use common functions for get/put pages

2011-09-13 Thread Daniel Vetter 
On Mon, Sep 12, 2011 at 02:21:25PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/radeon: Don't read from CP ring write pointer registers.

2011-09-13 Thread Michel Dänzer 
From: Michel D?nzer 

Apparently this doesn't always work reliably, e.g. at resume time.

Just initialize to 0, so the ring is considered empty.

Tested with hibernation on Sumo and Cayman cards.

Should fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ .

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/evergreen.c |4 ++--
 drivers/gpu/drm/radeon/ni.c|   12 ++--
 drivers/gpu/drm/radeon/r100.c  |6 ++
 drivers/gpu/drm/radeon/r600.c  |4 ++--
 4 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 15bd047..f2bd90a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1378,7 +1378,8 @@ int evergreen_cp_resume(struct radeon_device *rdev)
/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB_CNTL, tmp | RB_RPTR_WR_ENA);
WREG32(CP_RB_RPTR_WR, 0);
-   WREG32(CP_RB_WPTR, 0);
+   rdev->cp.wptr = 0;
+   WREG32(CP_RB_WPTR, rdev->cp.wptr);

/* set the wb address wether it's enabled or not */
WREG32(CP_RB_RPTR_ADDR,
@@ -1403,7 +1404,6 @@ int evergreen_cp_resume(struct radeon_device *rdev)
WREG32(CP_DEBUG, (1 << 27) | (1 << 28));

rdev->cp.rptr = RREG32(CP_RB_RPTR);
-   rdev->cp.wptr = RREG32(CP_RB_WPTR);

evergreen_cp_start(rdev);
rdev->cp.ready = true;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 559dbd4..e3489ee 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1182,7 +1182,8 @@ int cayman_cp_resume(struct radeon_device *rdev)

/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB0_CNTL, tmp | RB_RPTR_WR_ENA);
-   WREG32(CP_RB0_WPTR, 0);
+   rdev->cp.wptr = 0;
+   WREG32(CP_RB0_WPTR, rdev->cp.wptr);

/* set the wb address wether it's enabled or not */
WREG32(CP_RB0_RPTR_ADDR, (rdev->wb.gpu_addr + RADEON_WB_CP_RPTR_OFFSET) 
& 0xFFFC);
@@ -1202,7 +1203,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
WREG32(CP_RB0_BASE, rdev->cp.gpu_addr >> 8);

rdev->cp.rptr = RREG32(CP_RB0_RPTR);
-   rdev->cp.wptr = RREG32(CP_RB0_WPTR);

/* ring1  - compute only */
/* Set ring buffer size */
@@ -1215,7 +1215,8 @@ int cayman_cp_resume(struct radeon_device *rdev)

/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB1_CNTL, tmp | RB_RPTR_WR_ENA);
-   WREG32(CP_RB1_WPTR, 0);
+   rdev->cp1.wptr = 0;
+   WREG32(CP_RB1_WPTR, rdev->cp1.wptr);

/* set the wb address wether it's enabled or not */
WREG32(CP_RB1_RPTR_ADDR, (rdev->wb.gpu_addr + 
RADEON_WB_CP1_RPTR_OFFSET) & 0xFFFC);
@@ -1227,7 +1228,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
WREG32(CP_RB1_BASE, rdev->cp1.gpu_addr >> 8);

rdev->cp1.rptr = RREG32(CP_RB1_RPTR);
-   rdev->cp1.wptr = RREG32(CP_RB1_WPTR);

/* ring2 - compute only */
/* Set ring buffer size */
@@ -1240,7 +1240,8 @@ int cayman_cp_resume(struct radeon_device *rdev)

/* Initialize the ring buffer's read and write pointers */
WREG32(CP_RB2_CNTL, tmp | RB_RPTR_WR_ENA);
-   WREG32(CP_RB2_WPTR, 0);
+   rdev->cp2.wptr = 0;
+   WREG32(CP_RB2_WPTR, rdev->cp2.wptr);

/* set the wb address wether it's enabled or not */
WREG32(CP_RB2_RPTR_ADDR, (rdev->wb.gpu_addr + 
RADEON_WB_CP2_RPTR_OFFSET) & 0xFFFC);
@@ -1252,7 +1253,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
WREG32(CP_RB2_BASE, rdev->cp2.gpu_addr >> 8);

rdev->cp2.rptr = RREG32(CP_RB2_RPTR);
-   rdev->cp2.wptr = RREG32(CP_RB2_WPTR);

/* start the rings */
cayman_cp_start(rdev);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index f2204cb..11e44a3 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -990,7 +990,8 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
/* Force read & write ptr to 0 */
WREG32(RADEON_CP_RB_CNTL, tmp | RADEON_RB_RPTR_WR_ENA | 
RADEON_RB_NO_UPDATE);
WREG32(RADEON_CP_RB_RPTR_WR, 0);
-   WREG32(RADEON_CP_RB_WPTR, 0);
+   rdev->cp.wptr = 0;
+   WREG32(RADEON_CP_RB_WPTR, rdev->cp.wptr);

/* set the wb address whether it's enabled or not */
WREG32(R_00070C_CP_RB_RPTR_ADDR,
@@ -1007,9 +1008,6 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
WREG32(RADEON_CP_RB_CNTL, tmp);
udelay(10);
rdev->cp.rptr = RREG32(RADEON_CP_RB_RPTR);
-   rdev->cp.wptr = RREG32(RADEON_CP_RB_WPTR);
-   /* protect against crazy HW on resume */
-   rdev->cp.wptr &= rdev->cp.ptr_mask;
/* Set cp mode to bus mastering & enable cp*/
WREG32(RADEON_CP_CSQ_MODE,
   REG_SET(RADEON_INDIRECT2_START, indirect2_start) |
diff --git a/

[BUG] drm/radeon: locking problems with page_flip

2011-09-13 Thread Michel Dänzer 
On Die, 2011-09-13 at 05:49 +0200, Witold Baryluk wrote: 
> 
> I yeasterday discovered pretty nasty issue in radeon / drm code,
> and page_flip locking code on my ThinkPad T43.

Does the patch below fix the problem?

[Bug 40826] New: RV_770/90 regression by - r600g: simplify deducing chip family

2011-09-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=40826

   Summary: RV_770/90 regression by - r600g: simplify deducing
chip family
   Product: Mesa
   Version: unspecified
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: lists at andyfurniss.entadsl.com


rv_770 (it's a 790 really) all mesa demos I've tried misrender in some way
since -

commit 915227b0aa228fd203618adbb35930e994658087
Author: Marek Olk 
Date:   Sun Sep 11 14:57:55 2011 +0200

r600g: simplify deducing chip family

reverting this + power cycle to resolve card state fixes.

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

[Bug 40826] RV_770/90 regression by - r600g: simplify deducing chip family

2011-09-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=40826

--- Comment #1 from Marek Ol??k  2011-09-13 04:10:29 PDT 
---
This should be fixed now in Mesa master, can you test?

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

[Bug 40826] RV_770/90 regression by - r600g: simplify deducing chip family

2011-09-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=40826

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Andy Furniss  2011-09-13 
04:35:54 PDT ---
OK now, thanks.

-- 
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/7] ttm: Introduce ttm_page_alloc_func structure.

2011-09-13 Thread Konrad Rzeszutek Wilk 
Which has the function members for all of the current page pool
operations defined. The old calls (ttm_put_pages, ttm_get_pages, etc)
are plumbed through little functions which lookup in the ttm_page_alloc_func
the appropiate implementation and call it.

There is currently only one page pool code so the default registration
goes to 'ttm_page_alloc_default'. The subsequent patch
"ttm: Provide a DMA aware TTM page pool code." introduces the one
to be used when the SWIOTLB code is turned on (that implementation
is a union of the default TTM pool code with the DMA pool code).

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/ttm/ttm_memory.c |3 ++
 drivers/gpu/drm/ttm/ttm_page_alloc.c |   58 
 include/drm/ttm/ttm_page_alloc.h |   60 ++
 3 files changed, 113 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index e70ddd8..c7d97a5 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -356,6 +356,8 @@ static int ttm_mem_init_dma32_zone(struct ttm_mem_global 
*glob,
 }
 #endif

+struct ttm_page_alloc_func *ttm_page_alloc;
+
 int ttm_mem_global_init(struct ttm_mem_global *glob)
 {
struct sysinfo si;
@@ -394,6 +396,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
   "Zone %7s: Available graphics memory: %llu kiB.\n",
   zone->name, (unsigned long long) zone->max_mem >> 10);
}
+   ttm_page_alloc = &ttm_page_alloc_default;
ttm_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE));
return 0;
 out_no_zone:
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index d948575..6a888f8 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -664,9 +664,9 @@ out:
  * On success pages list will hold count number of correctly
  * cached pages.
  */
-int ttm_get_pages(struct list_head *pages, int flags,
- enum ttm_caching_state cstate, unsigned count,
- dma_addr_t *dma_address)
+int __ttm_get_pages(struct list_head *pages, int flags,
+   enum ttm_caching_state cstate, unsigned count,
+   dma_addr_t *dma_address)
 {
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct page *p = NULL;
@@ -734,8 +734,8 @@ int ttm_get_pages(struct list_head *pages, int flags,
 }

 /* Put all pages in pages list to correct pool to wait for reuse */
-void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
-  enum ttm_caching_state cstate, dma_addr_t *dma_address)
+void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
+enum ttm_caching_state cstate, dma_addr_t *dma_address)
 {
unsigned long irq_flags;
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
@@ -785,7 +785,7 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool 
*pool, int flags,
pool->name = name;
 }

-int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
+int __ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 {
int ret;

@@ -822,7 +822,7 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
return 0;
 }

-void ttm_page_alloc_fini(void)
+void __ttm_page_alloc_fini(void)
 {
int i;

@@ -836,7 +836,7 @@ void ttm_page_alloc_fini(void)
_manager = NULL;
 }

-int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
+int __ttm_page_alloc_debugfs(struct seq_file *m, void *data)
 {
struct ttm_page_pool *p;
unsigned i;
@@ -856,4 +856,46 @@ int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
}
return 0;
 }
+
+struct ttm_page_alloc_func ttm_page_alloc_default = {
+   .get_pages  = __ttm_get_pages,
+   .put_pages  = __ttm_put_pages,
+   .alloc_init = __ttm_page_alloc_init,
+   .alloc_fini = __ttm_page_alloc_fini,
+   .debugfs= __ttm_page_alloc_debugfs,
+};
+
+int ttm_get_pages(struct list_head *pages, int flags,
+ enum ttm_caching_state cstate, unsigned count,
+ dma_addr_t *dma_address)
+{
+   if (ttm_page_alloc && ttm_page_alloc->get_pages)
+   return ttm_page_alloc->get_pages(pages, flags, cstate, count,
+dma_address);
+   return -1;
+}
+void ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
+  enum ttm_caching_state cstate, dma_addr_t *dma_address)
+{
+   if (ttm_page_alloc && ttm_page_alloc->put_pages)
+   ttm_page_alloc->put_pages(pages, page_count, flags, cstate,
+ dma_address);
+}
+int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
+{
+   if (ttm_page_a

[PATCH] TTM DMA v1.8

2011-09-13 Thread Konrad Rzeszutek Wilk 
Since v1.7: [https://lkml.org/lkml/2011/8/30/460]
 - Fixed checking the DMA address in radeon/nouveau code.
Since v1: [http://lwn.net/Articles/456246/]
 - Ran it through the gauntlet of SubmitChecklist and fixed issues
 - Made radeon/nouveau driver set coherent_dma (which is required for dmapool)

[.. and this is what I said in v1 post]:

Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.

After a bit of discussion on the mailing list
http://marc.info/?i=4D769726.2030307 at shipmail.org I started working on it, 
but
got waylaid by other things .. and finally I am able to post the RFC patches.

There was a lot of discussion about it and I am not sure if I captured
everybody's thoughts - if I did not - that is _not_ intentional - it has just
been quite some time..

Anyhow .. the patches explore what the "lib/dmapool.c" does - which is to have a
DMA pool that the device has associated with. I kind of married that code
along with drivers/gpu/drm/ttm/ttm_page_alloc.c to create a TTM DMA pool code.
The end result is DMA pool with extra features: can do write-combine, uncached,
writeback (and tracks them and sets back to WB when freed); tracks "cached"
pages that don't really need to be returned to a pool; and hooks up to
the shrinker code so that the pools can be shrunk.

If you guys think this set of patches make sense  - my future plans were
 1) Get this in large crowd of testing .. and if it works for a kernel release
 2) to move a bulk of this in the lib/dmapool.c (I spoke with Matthew Wilcox
about it and he is OK as long as I don't introduce performance regressions).

But before I do any of that a second set of eyes taking a look at these
patches would be most welcome.

In regards to testing, I've been running them non-stop for the last two weeks
(and found some issues which I've fixed up) - and been quite happy with how
they work. I finally got my Intel VT-d box online so will test that shortly.

Michel (thanks!) took a spin of the patches on his PowerPC and they did not
cause any regressions (wheew).

The patches are also located in a git tree:

 git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v1.8

 drivers/gpu/drm/nouveau/nouveau_mem.c|8 +-
 drivers/gpu/drm/nouveau/nouveau_sgdma.c  |3 +-
 drivers/gpu/drm/radeon/radeon_device.c   |6 +
 drivers/gpu/drm/radeon/radeon_gart.c |4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c  |3 +-
 drivers/gpu/drm/ttm/Makefile |3 +
 drivers/gpu/drm/ttm/ttm_bo.c |4 +-
 drivers/gpu/drm/ttm/ttm_memory.c |5 +
 drivers/gpu/drm/ttm/ttm_page_alloc.c |   63 ++-
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1317 ++
 drivers/gpu/drm/ttm/ttm_tt.c |5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |4 +-
 drivers/xen/swiotlb-xen.c|2 +-
 include/drm/ttm/ttm_bo_driver.h  |7 +-
 include/drm/ttm/ttm_page_alloc.h |  100 +++-
 include/linux/swiotlb.h  |7 +-
 lib/swiotlb.c|5 +-
 17 files changed, 1516 insertions(+), 30 deletions(-)

[PATCH 3/7] ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device.

2011-09-13 Thread Konrad Rzeszutek Wilk 
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-
 drivers/gpu/drm/radeon/radeon_ttm.c   |3 ++-
 drivers/gpu/drm/ttm/ttm_bo.c  |4 +++-
 drivers/gpu/drm/ttm/ttm_page_alloc.c  |   17 ++---
 drivers/gpu/drm/ttm/ttm_tt.c  |5 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |4 ++--
 include/drm/ttm/ttm_bo_driver.h   |7 ++-
 include/drm/ttm/ttm_page_alloc.h  |   16 
 8 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c 
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 5ee14d2..a2d7e35 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -417,7 +417,8 @@ nouveau_mem_vram_init(struct drm_device *dev)
ret = ttm_bo_device_init(&dev_priv->ttm.bdev,
 dev_priv->ttm.bo_global_ref.ref.object,
 &nouveau_bo_driver, DRM_FILE_PAGE_OFFSET,
-dma_bits <= 32 ? true : false);
+dma_bits <= 32 ? true : false,
+dev->dev);
if (ret) {
NV_ERROR(dev, "Error initialising bo driver: %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 60125dd..dbc6bcb 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -517,7 +517,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
r = ttm_bo_device_init(&rdev->mman.bdev,
   rdev->mman.bo_global_ref.ref.object,
   &radeon_bo_driver, DRM_FILE_PAGE_OFFSET,
-  rdev->need_dma32);
+  rdev->need_dma32,
+  rdev->dev);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2e618b5..0358889 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1527,12 +1527,14 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
   struct ttm_bo_global *glob,
   struct ttm_bo_driver *driver,
   uint64_t file_page_offset,
-  bool need_dma32)
+  bool need_dma32,
+  struct device *dev)
 {
int ret = -EINVAL;

rwlock_init(&bdev->vm_lock);
bdev->driver = driver;
+   bdev->dev = dev;

memset(bdev->man, 0, sizeof(bdev->man));

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 6a888f8..f9a4d83 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -666,7 +666,7 @@ out:
  */
 int __ttm_get_pages(struct list_head *pages, int flags,
enum ttm_caching_state cstate, unsigned count,
-   dma_addr_t *dma_address)
+   dma_addr_t *dma_address, struct device *dev)
 {
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct page *p = NULL;
@@ -724,7 +724,8 @@ int __ttm_get_pages(struct list_head *pages, int flags,
printk(KERN_ERR TTM_PFX
   "Failed to allocate extra pages "
   "for large request.");
-   ttm_put_pages(pages, 0, flags, cstate, NULL);
+   ttm_put_pages(pages, 0, flags, cstate, dma_address,
+ dev);
return r;
}
}
@@ -735,7 +736,8 @@ int __ttm_get_pages(struct list_head *pages, int flags,

 /* Put all pages in pages list to correct pool to wait for reuse */
 void __ttm_put_pages(struct list_head *pages, unsigned page_count, int flags,
-enum ttm_caching_state cstate, dma_addr_t *dma_address)
+enum ttm_caching_state cstate, dma_addr_t *dma_address,
+struct device *dev)
 {
unsigned long irq_flags;
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
@@ -867,19 +869,20 @@ struct ttm_page_alloc_func ttm_page_alloc_default = {

 int ttm_get_pages(struct list_head *pages, int flags,
  enum ttm_caching_state cstate, unsigned count,
- dma_addr_t *dma_address)
+ dma_addr_t *dma_address, struct device *dev)
 {
if (ttm_page_alloc && ttm_page_alloc->get_pages)
return ttm_page_alloc->get_pages(pages, flags, cstate, count,
-dma_addres

[PATCH 7/7] nouveau/radeon: Set coherent DMA mask

2011-09-13 Thread Konrad Rzeszutek Wilk 
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/nouveau/nouveau_mem.c  |5 +
 drivers/gpu/drm/radeon/radeon_device.c |6 ++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c 
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index a2d7e35..bb6ccbd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -408,6 +408,11 @@ nouveau_mem_vram_init(struct drm_device *dev)
if (ret)
return ret;

+   ret = pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(dma_bits));
+   if (ret) {
+   /* Reset to default value. */
+   pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(32));
+   }
dev_priv->fb_phys = pci_resource_start(dev->pdev, 1);

ret = nouveau_ttm_global_init(dev_priv);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 7cfaa7e..0c0a970 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -757,8 +757,14 @@ int radeon_device_init(struct radeon_device *rdev,
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
rdev->need_dma32 = true;
+   dma_bits = 32;
printk(KERN_WARNING "radeon: No suitable DMA available.\n");
}
+   r = pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
+   if (r) {
+   pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(32));
+   printk(KERN_WARNING "radeon: No coherent DMA available.\n");
+   }

/* Registers mapping */
/* TODO: block userspace mapping of io register */
-- 
1.7.4.1

[PATCH 6/7] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime.

2011-09-13 Thread Konrad Rzeszutek Wilk 
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.

In the future this parameter can be removed.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4 
 include/drm/ttm/ttm_page_alloc.h |4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 5a5739c..5909d28 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -51,6 +51,10 @@
 #include 
 #endif

+int __read_mostly dma_ttm_disable;
+MODULE_PARM_DESC(no_dma, "Disable TTM DMA pool");
+module_param_named(no_dma, dma_ttm_disable, bool, S_IRUGO);
+
 #define NUM_PAGES_TO_ALLOC (PAGE_SIZE/sizeof(struct page *))
 #define SMALL_ALLOCATION   16
 #define FREE_ALL_PAGES (~0U)
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 192c5f8..e75af77 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -103,10 +103,10 @@ extern struct ttm_page_alloc_func ttm_page_alloc_default;
 #ifdef CONFIG_SWIOTLB
 /* Defined in ttm_page_alloc_dma.c */
 extern struct ttm_page_alloc_func ttm_page_alloc_dma;
-
+extern int dma_ttm_disable;
 static inline bool ttm_page_alloc_need_dma(void)
 {
-   if (swiotlb_enabled()) {
+   if (!dma_ttm_disable && swiotlb_enabled()) {
ttm_page_alloc = &ttm_page_alloc_dma;
return true;
}
-- 
1.7.4.1

[PATCH 5/7] ttm: Provide a DMA aware TTM page pool code.

2011-09-13 Thread Konrad Rzeszutek Wilk 
In TTM world the pages for the graphic drivers are kept in three different
pools: write combined, uncached, and cached (write-back). When the pages
are used by the graphic driver the graphic adapter via its built in MMU
(or AGP) programs these pages in. The programming requires the virtual address
(from the graphic adapter perspective) and the physical address (either System 
RAM
or the memory on the card) which is obtained using the pci_map_* calls (which 
does the
virtual to physical - or bus address translation). During the graphic 
application's
"life" those pages can be shuffled around, swapped out to disk, moved from the
VRAM to System RAM or vice-versa. This all works with the existing TTM pool code
- except when we want to use the software IOTLB (SWIOTLB) code to "map" the 
physical
addresses to the graphic adapter MMU. We end up programming the bounce buffer's
physical address instead of the TTM pool memory's and get a non-worky driver.
There are two solutions:
1) using the DMA API to allocate pages that are screened by the DMA API, or
2) using the pci_sync_* calls to copy the pages from the bounce-buffer and back.

This patch fixes the issue by allocating pages using the DMA API. The second
is a viable option - but it has performance drawbacks and potential correctness
issues - think of the write cache page being bounced (SWIOTLB->TTM), the
WC is set on the TTM page and the copy from SWIOTLB not making it to the TTM
page until the page has been recycled in the pool (and used by another 
application).

The bounce buffer does not get activated often - only in cases where we have
a 32-bit capable card and we want to use a page that is allocated above the
4GB limit. The bounce buffer offers the solution of copying the contents
of that 4GB page to an location below 4GB and then back when the operation has 
been
completed (or vice-versa). This is done by using the 'pci_sync_*' calls.
Note: If you look carefully enough in the existing TTM page pool code you will
notice the GFP_DMA32 flag is used  - which should guarantee that the provided 
page
is under 4GB. It certainly is the case, except this gets ignored in two cases:
 - If user specifies 'swiotlb=force' which bounces _every_ page.
 - If user is using a Xen's PV Linux guest (which uses the SWIOTLB and the
   underlaying PFN's aren't necessarily under 4GB).

To not have this extra copying done the other option is to allocate the pages
using the DMA API so that there is not need to map the page and perform the
expensive 'pci_sync_*' calls.

This DMA API capable TTM pool requires for this the 'struct device' to
properly call the DMA API. It also has to track the virtual and bus address of
the page being handed out in case it ends up being swapped out or de-allocated -
to make sure it is de-allocated using the proper's 'struct device'.

Implementation wise the code keeps two lists: one that is attached to the
'struct device' (via the dev->dma_pools list) and a global one to be used when
the 'struct device' is unavailable (think shrinker code). The global list can
iterate over all of the 'struct device' and its associated dma_pool. The list
in dev->dma_pools can only iterate the device's dma_pool.
/[struct 
device_pool]\
/---| dev   
 |
   /+---| dma_pool  
 |
 /-+--\/
\/
 |struct device| /-->[struct dma_pool for WC][struct dma_pool for uncached]<-/--| dma_pool  
 |
 \-+--/ /   
\/
\--/
[Two pools associated with the device (WC and UC), and the parallel list
containing the 'struct dev' and 'struct dma_pool' entries]

The maximum amount of dma pools a device can have is six: write-combined,
uncached, and cached; then there are the DMA32 variants which are:
write-combined dma32, uncached dma32, and cached dma32.

Currently this code only gets activated when any variant of the SWIOTLB IOMMU
code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV
with PCI devices).

Signed-off-by: Konrad Rzeszutek Wilk 
Tested-by: Michel D?nzer 
---
 drivers/gpu/drm/ttm/Makefile |3 +
 drivers/gpu/drm/ttm/ttm_memory.c |2 +
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1313 ++
 include/drm/ttm/ttm_page_alloc.h |   32 +-
 4 files changed, 1346 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index f3cf6f0..8300bc0 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -7,4 +7,7 @@ ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_object.o ttm_lock.o t

[PATCH 4/7] swiotlb: Expose swiotlb_nr_tlb function to modules as swiotlb_enabled

2011-09-13 Thread Konrad Rzeszutek Wilk 
As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.

We also fix the spelling - it was swioltb instead of
swiotlb.

CC: FUJITA Tomonori 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/swiotlb-xen.c |2 +-
 include/linux/swiotlb.h   |7 ++-
 lib/swiotlb.c |5 +++--
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6e8c15a..cbcd8cc 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -149,7 +149,7 @@ void __init xen_swiotlb_init(int verbose)
int rc;
unsigned long nr_tbl;

-   nr_tbl = swioltb_nr_tbl();
+   nr_tbl = swiotlb_nr_tbl();
if (nr_tbl)
xen_io_tlb_nslabs = nr_tbl;
else {
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 445702c..014ff53 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -24,7 +24,12 @@ extern int swiotlb_force;

 extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int 
verbose);
-extern unsigned long swioltb_nr_tbl(void);
+extern unsigned long swiotlb_nr_tbl(void);
+
+static inline bool swiotlb_enabled(void)
+{
+   return !!swiotlb_nr_tbl();
+}

 /*
  * Enumeration for sync targets
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 99093b3..058935e 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -110,11 +110,11 @@ setup_io_tlb_npages(char *str)
 __setup("swiotlb=", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */

-unsigned long swioltb_nr_tbl(void)
+unsigned long swiotlb_nr_tbl(void)
 {
return io_tlb_nslabs;
 }
-
+EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
  volatile void *address)
@@ -321,6 +321,7 @@ void __init swiotlb_free(void)
free_bootmem_late(__pa(io_tlb_start),
  PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
}
+   io_tlb_nslabs = 0;
 }

 static int is_swiotlb_buffer(phys_addr_t paddr)
-- 
1.7.4.1

[PATCH 1/7] ttm/radeon/nouveau: Check the DMA address from TTM against known value.

2011-09-13 Thread Konrad Rzeszutek Wilk 
. instead of checking against the DMA_ERROR_CODE value which is
per-platform specific. The zero value is a known invalid value
that the TTM layer sets on the dma_address array if it is not
used (ttm_tt_alloc_page_directory calls drm_calloc_large which
creates a page with GFP_ZERO).

We can't use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).

Also update the comments in the header about the true state
of that parameter.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 +--
 drivers/gpu/drm/radeon/radeon_gart.c|4 +---
 include/drm/ttm/ttm_page_alloc.h|4 ++--
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c 
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 82fad91..9b570c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -42,8 +42,7 @@ nouveau_sgdma_populate(struct ttm_backend *be, unsigned long 
num_pages,

nvbe->nr_pages = 0;
while (num_pages--) {
-   /* this code path isn't called and is incorrect anyways */
-   if (0) { /*dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE)*/
+   if (dma_addrs[nvbe->nr_pages] != 0) {
nvbe->pages[nvbe->nr_pages] =
dma_addrs[nvbe->nr_pages];
nvbe->ttm_alloced[nvbe->nr_pages] = true;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index a533f52..068ba09 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -181,9 +181,7 @@ int radeon_gart_bind(struct radeon_device *rdev, unsigned 
offset,
p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);

for (i = 0; i < pages; i++, p++) {
-   /* we reverted the patch using dma_addr in TTM for now but this
-* code stops building on alpha so just comment it out for now 
*/
-   if (0) { /*dma_addr[i] != DMA_ERROR_CODE) */
+   if (dma_addr[i] != 0) {
rdev->gart.ttm_alloced[p] = true;
rdev->gart.pages_addr[p] = dma_addr[i];
} else {
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 8062890..0017b17 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -36,7 +36,7 @@
  * @flags: ttm flags for page allocation.
  * @cstate: ttm caching state for the page.
  * @count: number of pages to allocate.
- * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set).
+ * @dma_address: The DMA (bus) address of pages - (by default zero).
  */
 int ttm_get_pages(struct list_head *pages,
  int flags,
@@ -51,7 +51,7 @@ int ttm_get_pages(struct list_head *pages,
  * count.
  * @flags: ttm flags for page allocation.
  * @cstate: ttm caching state.
- * @dma_address: The DMA (bus) address of pages (if TTM_PAGE_FLAG_DMA32 set).
+ * @dma_address: The DMA (bus) address of pages (by default zero).
  */
 void ttm_put_pages(struct list_head *pages,
   unsigned page_count,
-- 
1.7.4.1

PGRAPH: unsupported chipset

2011-09-13 Thread Sérgio Basto 
Hi wiebittewas, dri-devel at lists.sourceforge.net, is the old ML
dri-devel at lists.freedesktop.org, is the new dri-devel. 
So I am redirect the email ...  

On Mon, 2011-09-12 at 22:17 +0200, wiebittewas wrote: 
> Hi!
> 
> here's a latop with a nvidia quadro 1000M, where the nouveau-driver
> tells on startup "PGRAPH: unsupported chipset, please report", which
> I'll do now. (this list was the only address I've found within the code)
> 
> because I haven't found any info, what information I should report, I'll
> try it:
> 
> a short patch gives, that the requested value would be 0xc1
> 
> here's the full lspci-out:
> ==
> 01:00.0 VGA compatible controller [0300]: nVidia Corporation Device
> [10de:0dfa] (rev a1) (prog-if 00 [VGA controller])
>   Subsystem: Dell Device [1028:14a3]
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0, Cache Line Size: 64 bytes
>   Interrupt: pin A routed to IRQ 16
>   Region 0: Memory at ec00 (32-bit, non-prefetchable) [size=16M]
>   Region 1: Memory at e000 (64-bit, prefetchable) [size=128M]
>   Region 3: Memory at e800 (64-bit, prefetchable) [size=32M]
>   Region 5: I/O ports at 7000 [size=128]
>   Expansion ROM at ed00 [disabled] [size=512K]
>   Capabilities: [60] Power Management version 3
>   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>   Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>   Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
>   Address:   Data: 
>   Capabilities: [78] Express (v1) Endpoint, MSI 00
>   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 
> unlimited, L1 <64us
>   ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
> Unsupported-
>   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>   MaxPayload 128 bytes, MaxReadReq 512 bytes
>   DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
> TransPend-
>   LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency 
> L0
> <256ns, L1 <4us
>   ClockPM+ Surprise- LLActRep- BwNot-
>   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>   LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive-
> BWMgmt- ABWMgmt-
>   Capabilities: [b4] Vendor Specific Information: Len=14 
>   Capabilities: [100 v1] Virtual Channel
>   Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>   Arb:Fixed- WRR32- WRR64- WRR128-
>   Ctrl:   ArbSelect=Fixed
>   Status: InProgress-
>   VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>   Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>   Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
>   Status: NegoPending- InProgress-
>   Capabilities: [128 v1] Power Budgeting 
>   Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1
> Len=024 
>   Kernel driver in use: nouveau
>   Kernel modules: nouveau, nvidiafb
> ==
> if you want more information, please tell me, how I'll extract it.
> 
> best regards
> 
> wiebittewas
> 
> 
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the 
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1 
> --
> ___
> Dri-devel mailing list
> Dri-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel

-- 
S?rgio M. B.

[PATCH] drm/radeon: Don't read from CP ring write pointer registers.

2011-09-13 Thread Alex Deucher 
2011/9/13 Michel D?nzer :
> From: Michel D?nzer 
>
> Apparently this doesn't always work reliably, e.g. at resume time.
>
> Just initialize to 0, so the ring is considered empty.
>
> Tested with hibernation on Sumo and Cayman cards.
>
> Should fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ .
>
> Signed-off-by: Michel D?nzer 

Looks good to me.

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/evergreen.c | ? ?4 ++--
> ?drivers/gpu/drm/radeon/ni.c ? ? ? ?| ? 12 ++--
> ?drivers/gpu/drm/radeon/r100.c ? ? ?| ? ?6 ++
> ?drivers/gpu/drm/radeon/r600.c ? ? ?| ? ?4 ++--
> ?4 files changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 15bd047..f2bd90a 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1378,7 +1378,8 @@ int evergreen_cp_resume(struct radeon_device *rdev)
> ? ? ? ?/* Initialize the ring buffer's read and write pointers */
> ? ? ? ?WREG32(CP_RB_CNTL, tmp | RB_RPTR_WR_ENA);
> ? ? ? ?WREG32(CP_RB_RPTR_WR, 0);
> - ? ? ? WREG32(CP_RB_WPTR, 0);
> + ? ? ? rdev->cp.wptr = 0;
> + ? ? ? WREG32(CP_RB_WPTR, rdev->cp.wptr);
>
> ? ? ? ?/* set the wb address wether it's enabled or not */
> ? ? ? ?WREG32(CP_RB_RPTR_ADDR,
> @@ -1403,7 +1404,6 @@ int evergreen_cp_resume(struct radeon_device *rdev)
> ? ? ? ?WREG32(CP_DEBUG, (1 << 27) | (1 << 28));
>
> ? ? ? ?rdev->cp.rptr = RREG32(CP_RB_RPTR);
> - ? ? ? rdev->cp.wptr = RREG32(CP_RB_WPTR);
>
> ? ? ? ?evergreen_cp_start(rdev);
> ? ? ? ?rdev->cp.ready = true;
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 559dbd4..e3489ee 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1182,7 +1182,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
>
> ? ? ? ?/* Initialize the ring buffer's read and write pointers */
> ? ? ? ?WREG32(CP_RB0_CNTL, tmp | RB_RPTR_WR_ENA);
> - ? ? ? WREG32(CP_RB0_WPTR, 0);
> + ? ? ? rdev->cp.wptr = 0;
> + ? ? ? WREG32(CP_RB0_WPTR, rdev->cp.wptr);
>
> ? ? ? ?/* set the wb address wether it's enabled or not */
> ? ? ? ?WREG32(CP_RB0_RPTR_ADDR, (rdev->wb.gpu_addr + 
> RADEON_WB_CP_RPTR_OFFSET) & 0xFFFC);
> @@ -1202,7 +1203,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
> ? ? ? ?WREG32(CP_RB0_BASE, rdev->cp.gpu_addr >> 8);
>
> ? ? ? ?rdev->cp.rptr = RREG32(CP_RB0_RPTR);
> - ? ? ? rdev->cp.wptr = RREG32(CP_RB0_WPTR);
>
> ? ? ? ?/* ring1 ?- compute only */
> ? ? ? ?/* Set ring buffer size */
> @@ -1215,7 +1215,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
>
> ? ? ? ?/* Initialize the ring buffer's read and write pointers */
> ? ? ? ?WREG32(CP_RB1_CNTL, tmp | RB_RPTR_WR_ENA);
> - ? ? ? WREG32(CP_RB1_WPTR, 0);
> + ? ? ? rdev->cp1.wptr = 0;
> + ? ? ? WREG32(CP_RB1_WPTR, rdev->cp1.wptr);
>
> ? ? ? ?/* set the wb address wether it's enabled or not */
> ? ? ? ?WREG32(CP_RB1_RPTR_ADDR, (rdev->wb.gpu_addr + 
> RADEON_WB_CP1_RPTR_OFFSET) & 0xFFFC);
> @@ -1227,7 +1228,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
> ? ? ? ?WREG32(CP_RB1_BASE, rdev->cp1.gpu_addr >> 8);
>
> ? ? ? ?rdev->cp1.rptr = RREG32(CP_RB1_RPTR);
> - ? ? ? rdev->cp1.wptr = RREG32(CP_RB1_WPTR);
>
> ? ? ? ?/* ring2 - compute only */
> ? ? ? ?/* Set ring buffer size */
> @@ -1240,7 +1240,8 @@ int cayman_cp_resume(struct radeon_device *rdev)
>
> ? ? ? ?/* Initialize the ring buffer's read and write pointers */
> ? ? ? ?WREG32(CP_RB2_CNTL, tmp | RB_RPTR_WR_ENA);
> - ? ? ? WREG32(CP_RB2_WPTR, 0);
> + ? ? ? rdev->cp2.wptr = 0;
> + ? ? ? WREG32(CP_RB2_WPTR, rdev->cp2.wptr);
>
> ? ? ? ?/* set the wb address wether it's enabled or not */
> ? ? ? ?WREG32(CP_RB2_RPTR_ADDR, (rdev->wb.gpu_addr + 
> RADEON_WB_CP2_RPTR_OFFSET) & 0xFFFC);
> @@ -1252,7 +1253,6 @@ int cayman_cp_resume(struct radeon_device *rdev)
> ? ? ? ?WREG32(CP_RB2_BASE, rdev->cp2.gpu_addr >> 8);
>
> ? ? ? ?rdev->cp2.rptr = RREG32(CP_RB2_RPTR);
> - ? ? ? rdev->cp2.wptr = RREG32(CP_RB2_WPTR);
>
> ? ? ? ?/* start the rings */
> ? ? ? ?cayman_cp_start(rdev);
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index f2204cb..11e44a3 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -990,7 +990,8 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
> ring_size)
> ? ? ? ?/* Force read & write ptr to 0 */
> ? ? ? ?WREG32(RADEON_CP_RB_CNTL, tmp | RADEON_RB_RPTR_WR_ENA | 
> RADEON_RB_NO_UPDATE);
> ? ? ? ?WREG32(RADEON_CP_RB_RPTR_WR, 0);
> - ? ? ? WREG32(RADEON_CP_RB_WPTR, 0);
> + ? ? ? rdev->cp.wptr = 0;
> + ? ? ? WREG32(RADEON_CP_RB_WPTR, rdev->cp.wptr);
>
> ? ? ? ?/* set the wb address whether it's enabled or not */
> ? ? ? ?WREG32(R_00070C_CP_RB_RPTR_ADDR,
> @@ -1007,9 +1008,6 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
> ring_size)
> ? ? ? ?WREG32(RADEON_CP_RB_CNTL, tmp);
> ? ? ? ?udelay(10);
> ? ? ? ?rdev->cp.rptr = RREG32(RADEON_CP_RB_RPTR);
> - ? ? ? rdev->cp.wptr = RREG32(RADEON_CP_RB_WPTR);
>

[Bug 36934] screen corruption after running a game

2011-09-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #11 from almos  2011-09-13 14:59:31 PDT ---
(In reply to comment #10)
> (In reply to comment #7)
> > A couple of random things to try would be radeon.agpmode=4 and =-1, 
> > disabling
> > tiling, ...
> 
> Have you tried any of these?

Now I tried radeon.agpmode=-1 for a couple of days, but this issue didn't
appear. I could only reproduce the corruption of the image mentioned in comment
9. Usually it takes several days of uptime for the corruption to start to
appear noticeably, so the experiment might have been too short. I'll try it
again later.

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

[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250

2011-09-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=40790

Nicholas Miell  changed:

   What|Removed |Added

  Attachment #51059|0   |1
is obsolete||

--- Comment #2 from Nicholas Miell  2011-09-13 15:38:19 
PDT ---
Created an attachment (id=51166)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51166)
updated results

With http://lists.freedesktop.org/archives/mesa-dev/2011-September/011977.html
applied, the DRI2SwapBuffers error goes away and there's opportunity to fail
even more tests.

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

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-13 Thread Rob Clark 
On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae  wrote:
> Hi Thomas.
>
>> -Original Message-
>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>> Sent: Monday, September 12, 2011 3:32 PM
>> To: Rob Clark
>> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-
>> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>
>> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
>> > On 09/10/2011 07:31 PM, Rob Clark wrote:
>> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
>> >> Hellstrom ?wrote:
>> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
>>  This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
>>  only FIMD yet but we will add HDMI support also in the future.
>> 
>>  from now on, I will remove RFC prefix because I think we have got
>>  comments
>>  enough.
>> 
>>  this patch is based on git repository below:
>>  git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>>  branch name: drm-next
>>  commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
>> 
>>  you can refer to our working repository below:
>>  http://git.infradead.org/users/kmpark/linux-2.6-samsung
>>  branch name: samsung-drm
>> 
>>  We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>>  based on Linux framebuffer) but couldn't so because lowlevel codes
>>  of s3c-fb.c are included internally and so FIMD module of this
>>  driver has
>>  its own lowlevel codes.
>> 
>>  We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
>>  for buffer allocation. by using DMA API, we could use CMA later.
>> 
>>  Refer to this link for CMA(Continuous Memory Allocator):
>>  http://lkml.org/lkml/2011/7/20/45
>> 
>>  this driver supports only physically continuous memory(non-iommu).
>> 
>>  Links to previous versions of the patchset:
>>  v1:< ? ?https://lwn.net/Articles/454380/>
>>  v2:< ? ?http://www.spinics.net/lists/kernel/msg1224275.html>
>>  v3:< ? ?http://www.gossamer-threads.com/lists/linux/kernel/1423684>
>> 
>>  Changelog v2:
>>  DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
>> 
>>  ? ? ?this feature maps user address space to physical memory region
>>  ? ? ?once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
>> 
>>  DRM: code clean and add exception codes.
>> 
>>  Changelog v3:
>>  DRM: Support multiple irq.
>> 
>>  ? ? ?FIMD and HDMI have their own irq handler but DRM Framework can
>>  regiter
>>  ? ? ?only one irq handler this patch supports mutiple irq for
>>  Samsung SoC.
>> 
>>  DRM: Consider modularization.
>> 
>>  ? ? ?each DRM, FIMD could be built as a module.
>> 
>>  DRM: Have indenpendent crtc object.
>> 
>>  ? ? ?crtc isn't specific to SoC Platform so this patch gets a crtc
>>  ? ? ?to be used as common object.
>>  ? ? ?created crtc could be attached to any encoder object.
>> 
>>  DRM: code clean and add exception codes.
>> 
>>  Changelog v4:
>>  DRM: remove is_defult from samsung_fb.
>> 
>>  ? ? ?is_default isn't used for default framebuffer.
>> 
>>  DRM: code refactoring to fimd module.
>>  ? ? ?this patch is be considered with multiple display objects and
>>  ? ? ?would use its own request_irq() to register a irq handler
>>  instead of
>>  ? ? ?drm framework's one.
>> 
>>  DRM: remove find_samsung_drm_gem_object()
>> 
>>  DRM: move kernel private data structures and definitions to driver
>>  folder.
>> 
>>  ? ? ?samsung_drm.h would contain only public information for
> userspace
>>  ? ? ?ioctl interface.
>> 
>>  DRM: code refactoring to gem modules.
>>  ? ? ?buffer module isn't dependent of gem module anymore.
>> 
>>  DRM: fixed security issue.
>> 
>>  DRM: remove encoder porinter from specific connector.
>> 
>>  ? ? ?samsung connector doesn't need to have generic encoder.
>> 
>>  DRM: code clean and add exception codes.
>> 
>>  Signed-off-by: Inki Dae
>>  Signed-off-by: Joonyoung Shim
>>  Signed-off-by: SeungWoo Kim
>>  Signed-off-by: kyungmin.park
>>  ---
>> 
>>  +static struct drm_ioctl_desc samsung_ioctls[] = {
>>  + ? ? ? DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>>  samsung_drm_gem_create_ioctl,
>>  + ? ? ? ? ? ? ? ? ? ? ? DRM_UNLOCKED | DRM_AUTH),
>> 
>> >>> Hi!
>> >>>
>> >>> With reference my previous security comment.
>> >>>
>> >>> Let's say you have a compromised video player running as a DRM
>> >>> client, that
>> >>> tries to repeatedly allocate huge GEM buffers...
>> >>>
>> >>> What will happen when all DMA memory is exhausted? Will this cause
>> >>> other
>> >>> device drivers to see an OOM, or only DRM?
>> >>>
>> >>> The old DRI model