[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Huacai Chen
On Fri, Jun 22, 2012 at 5:39 PM, Arnaud Patard
 wrote:
>
> Hi,
>
> Huacai Chen  writes:
>
>> 1, Handle io prot correctly for MIPS.
>> 2, Define SAREA_MAX as the size of one page.
>> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>> ? ?when use swiotlb, GPU reset occurs at resume from suspend).
>>
>> Signed-off-by: Huacai Chen 
>> Signed-off-by: Hongliang Tao 
>> Signed-off-by: Hua Yan 
>> Reviewed-by: Michel D?nzer 
>> Reviewed-by: Alex Deucher 
>> Reviewed-by: Lucas Stach 
>> Reviewed-by: j.glisse 
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ?| ? ?2 +-
>> ?drivers/gpu/drm/radeon/radeon_ttm.c | ? ?6 +++---
>> ?drivers/gpu/drm/ttm/ttm_bo_util.c ? | ? ?2 +-
>> ?include/drm/drm_sarea.h ? ? ? ? ? ? | ? ?2 ++
>> ?4 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
>> vm_area_struct *vma)
>> ? ? ? ? ? ? ? tmp = pgprot_writecombine(tmp);
>> ? ? ? else
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>> ? ? ? tmp = pgprot_noncached(tmp);
>
> btw, would it be a good idea to use uncached accelerated instead ?
I have tried uncached accelerated, there will be random points in the
monitor, it seems a hw issue...

>
> Arnaud


[Bug 51344] massive corruption on RV410

2012-06-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=51344

--- Comment #2 from Tormod Volden  2012-06-22 
11:50:37 PDT ---
Created attachment 63359
  --> https://bugs.freedesktop.org/attachment.cgi?id=63359
screenshot (no xorg.conf options)

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


[Bug 51344] massive corruption on RV410

2012-06-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=51344

--- Comment #1 from Tormod Volden  2012-06-22 
11:22:39 PDT ---
Created attachment 63357
  --> https://bugs.freedesktop.org/attachment.cgi?id=63357
dmesg output

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


[Bug 51344] massive corruption on RV410

2012-06-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=51344

Tormod Volden  changed:

   What|Removed |Added

Summary|massive corruption on RV515 |massive corruption on RV410

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


[Bug 51344] New: massive corruption on RV515

2012-06-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=51344

 Bug #: 51344
   Summary: massive corruption on RV515
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: bugzi11.fdo.tormod at xoxy.net


Created attachment 63356
  --> https://bugs.freedesktop.org/attachment.cgi?id=63356
Xorg.0.log

This happened early May on drm-next somewhere between 4f256e8..d3029b4, and is
still there in 3.5rc3 (and in current drm-next).

Things are smeared out vertically. Looks like desktop background is not
corrupted. By turning off "EXABitmaps" there is less corruption.

I haven't done git bisecting, only download bisecting from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/ and
v3.4-rc6-295-g4f256e8 from May 8th was good and v3.4-rc6-315-gd3029b4 from May
10th was bad. Unfortunately the build from May 9th has been deleted in the
meantime so I can not narrow it down further this way. So the commits in
question should be:

d3029b4 drm/radeon/kms: fix warning on 32-bit in atomic fence printing
f2e3922 drm/radeon: make the ib an inline object
f237750 drm/radeon: remove r600 blit mutex v2
68470ae drm/radeon: move the semaphore from the fence into the ib
7c0d409 drm/radeon: immediately free ttm-move semaphore
c507f7e drm/radeon: rip out the ib pool
a8c0594 drm/radeon: simplify semaphore handling v2
c3b7fe8 drm/radeon: multiple ring allocator v3
0085c950 drm/radeon: use one wait queue for all rings add fence_wait_any v2
557017a drm/radeon: define new SA interface v3
2e0d991 drm/radeon: make sa bo a stand alone object
e6661a9 drm/radeon: keep start and end offset in the SA
711a972 drm/radeon: add sub allocator debugfs file
a651c55 drm/radeon: add proper locking to the SA v3
dd8bea2 drm/radeon: use inline functions to calc sa_bo addr
8a47cc9 drm/radeon: rework locking ring emission mutex in fence deadlock
detection v2
3b7a2b2 drm/radeon: rework fence handling, drop fence list v7
bb63556 drm/radeon: convert fence to uint64_t v4
d6999bc drm/radeon: replace the per ring mutex with a global one
133f4cb drm/radeon: fix possible lack of synchronization btw ttm and other ring

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
Radeon Mobility X700 (PCIE) [1002:5653]

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


[PATCH] DRM: exynos: return NULL if exynos_pages_to_sg fails

2012-06-22 Thread Subash Patel
From: Subash Patel 

exynos_pages_to_sg() internally calls sg_kmalloc() which can return
no pages when the system is under high memory crunch. One such instance
is chromeos-install in the chromeos. This patch adds check for the return
value of the function in subject to return NULL on failure.

Signed-off-by: Subash Patel 
CC: dri-devel at lists.freedesktop.org
CC: linux-samsung-soc at vger.kernel.org
CC: linaro-mm-sig at lists.linaro.org
CC: inki.dae at samsung.com
CC: airlied at redhat.com
CC: olofj at chromium.org
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 97325c1..c908a29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -87,6 +87,10 @@ static struct sg_table *
npages = buf->size / buf->page_size;

sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
+   if (!sgt) {
+   DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
+   goto err_unlock;
+   }
nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);

DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
@@ -241,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,


sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
-   if (IS_ERR(sgt)) {
+   if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
-- 
1.7.9.5



[PATCH] DRM: exynos: return NULL if exynos_pages_to_sg fails

2012-06-22 Thread "Subash Patel (ಸುಭಾಷ್)"
Hi Olof,

I will then rework this patch commit message and send it. I will copy 
Samsung-soc list (dri-devel is already in copy)

Regards,
Subash

On 06/22/2012 05:47 PM, Olof Johansson wrote:
> Hi,
>
> On Fri, Jun 22, 2012 at 5:41 PM, Subash Patel  > wrote:
>
> From: Subash Patel  >
>
> exynos_pages_to_sg() internally calls sg_kmalloc() which can return
> no pages when the system is under high memory crunch. One such instance
> is chromeos-install in the chromeos. This patch adds check for the
> return
> value of the function in subject to return NULL on failure.
>
> BUG=chrome-os-partner:9481
> TEST=built, ran on snow and tried chromeos-install without a crash
>
> Change-Id: I0abda74beaedae002a17de9962d7a462a2a7c2fb
> Signed-off-by: Subash Patel  >
>
>
> No BUG/TEST/Change-Id on a public patch, please. Also, I didn't see this
> posted on neither samsung-soc, nor the dri-devel list?
>
>
> -Olof
>


Re: [PATCH] DRM: exynos: return NULL if exynos_pages_to_sg fails

2012-06-22 Thread Olof Johansson
Hi,

On Fri, Jun 22, 2012 at 5:41 PM, Subash Patel  wrote:

> From: Subash Patel 
>
> exynos_pages_to_sg() internally calls sg_kmalloc() which can return
> no pages when the system is under high memory crunch. One such instance
> is chromeos-install in the chromeos. This patch adds check for the return
> value of the function in subject to return NULL on failure.
>
> BUG=chrome-os-partner:9481
> TEST=built, ran on snow and tried chromeos-install without a crash
>
> Change-Id: I0abda74beaedae002a17de9962d7a462a2a7c2fb
> Signed-off-by: Subash Patel 
>

No BUG/TEST/Change-Id on a public patch, please. Also, I didn't see this
posted on neither samsung-soc, nor the dri-devel list?


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


Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Huacai Chen
On Fri, Jun 22, 2012 at 7:11 PM, Ralf Baechle  wrote:
> On Fri, Jun 22, 2012 at 06:55:40PM +0800, Huacai Chen wrote:
>
>> > btw, would it be a good idea to use uncached accelerated instead ?
>> I have tried uncached accelerated, there will be random points in the
>> monitor, it seems a hw issue...
>
> Have you flushed the pages from memory before switching their cache mode
> to uncached accelerated?  The MIPS architecture defines the result of
> mixing cache modes as UNPREDICTABLE so be careful to flush caches before
> switching cache mode of a page.
Not because of flushing, CPU designing team told us a method but very
complex, and that method will cause other performance drop. So, we
won't use uncached accelerate mode.
>
>  Ralf
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] DRM: exynos: return NULL if exynos_pages_to_sg fails

2012-06-22 Thread Olof Johansson
Hi,

On Fri, Jun 22, 2012 at 5:41 PM, Subash Patel  wrote:

> From: Subash Patel 
>
> exynos_pages_to_sg() internally calls sg_kmalloc() which can return
> no pages when the system is under high memory crunch. One such instance
> is chromeos-install in the chromeos. This patch adds check for the return
> value of the function in subject to return NULL on failure.
>
> BUG=chrome-os-partner:9481
> TEST=built, ran on snow and tried chromeos-install without a crash
>
> Change-Id: I0abda74beaedae002a17de9962d7a462a2a7c2fb
> Signed-off-by: Subash Patel 
>

No BUG/TEST/Change-Id on a public patch, please. Also, I didn't see this
posted on neither samsung-soc, nor the dri-devel list?


-Olof
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120622/82943505/attachment.html>


[PATCH] DRM: exynos: return NULL if exynos_pages_to_sg fails

2012-06-22 Thread Subash Patel
From: Subash Patel 

exynos_pages_to_sg() internally calls sg_kmalloc() which can return
no pages when the system is under high memory crunch. One such instance
is chromeos-install in the chromeos. This patch adds check for the return
value of the function in subject to return NULL on failure.

BUG=chrome-os-partner:9481
TEST=built, ran on snow and tried chromeos-install without a crash

Change-Id: I0abda74beaedae002a17de9962d7a462a2a7c2fb
Signed-off-by: Subash Patel 
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 97325c1..c908a29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -87,6 +87,10 @@ static struct sg_table *
npages = buf->size / buf->page_size;

sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
+   if (!sgt) {
+   DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
+   goto err_unlock;
+   }
nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);

DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
@@ -241,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,


sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
-   if (IS_ERR(sgt)) {
+   if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
-- 
1.7.9.5



[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Huacai Chen
On Fri, Jun 22, 2012 at 1:25 PM, Lucas Stach  wrote:
> Hello Huacai,
>
> Am Freitag, den 22.06.2012, 11:01 +0800 schrieb Huacai Chen:
>> 1, Handle io prot correctly for MIPS.
>> 2, Define SAREA_MAX as the size of one page.
>> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>> ? ?when use swiotlb, GPU reset occurs at resume from suspend).
>>
> I still think this is wrong. You say Loongson needs SWIOTLB, but when
> it's actually used you ignore it in the radeon driver code.
>
> I looked up why you are using SWIOTLB and I don't agree with you that it
> is needed. SWIOTLB just gives you bounce pages for DMA memory above
> DMA32 and therefore papers over your >4GB DMA platform bug in some
> cases, while hurting performance.
>
> Please fix your DMA platform code so that region DMA is an alias for
> region DMA32. It should allow you to drop all those ugly workarounds.
>
Hi, Lucas, I disable SWIOTLB and still make sure DMA <4G, radeon and
sound card seems work fine, but OHCI still can't work. From git log
arch/mips/cavium-octeon/dma-octeon.c, it seems Cavium also need
SWIOTLB to avoid OHCI issue.

>> Signed-off-by: Huacai Chen 
>> Signed-off-by: Hongliang Tao 
>> Signed-off-by: Hua Yan 
>> Reviewed-by: Michel D?nzer 
>> Reviewed-by: Alex Deucher 
>> Reviewed-by: Lucas Stach 
>> Reviewed-by: j.glisse 
>
> You should probably only stick this tag on your patches after the people
> you are naming explicitly gave their r-b for a specific version of a
> patch.
>
> Thanks,
> Lucas
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ?| ? ?2 +-
>> ?drivers/gpu/drm/radeon/radeon_ttm.c | ? ?6 +++---
>> ?drivers/gpu/drm/ttm/ttm_bo_util.c ? | ? ?2 +-
>> ?include/drm/drm_sarea.h ? ? ? ? ? ? | ? ?2 ++
>> ?4 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
>> vm_area_struct *vma)
>> ? ? ? ? ? ? ? tmp = pgprot_writecombine(tmp);
>> ? ? ? else
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>> ? ? ? tmp = pgprot_noncached(tmp);
>> ?#endif
>> ? ? ? return tmp;
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>> index c94a225..f49bdd1 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>> @@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>> ? ? ? }
>> ?#endif
>>
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>> ? ? ? if (swiotlb_nr_tbl()) {
>> ? ? ? ? ? ? ? return ttm_dma_populate(>t->ttm, rdev->dev);
>> ? ? ? }
>> @@ -676,7 +676,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>> ? ? ? }
>> ?#endif
>>
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>> ? ? ? if (swiotlb_nr_tbl()) {
>> ? ? ? ? ? ? ? ttm_dma_unpopulate(>t->ttm, rdev->dev);
>> ? ? ? ? ? ? ? return;
>> @@ -906,7 +906,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
>> *rdev)
>> ? ? ? radeon_mem_types_list[i].show = &ttm_page_alloc_debugfs;
>> ? ? ? radeon_mem_types_list[i].driver_features = 0;
>> ? ? ? radeon_mem_types_list[i++].data = NULL;
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>> ? ? ? if (swiotlb_nr_tbl()) {
>> ? ? ? ? ? ? ? sprintf(radeon_mem_types_names[i], "ttm_dma_page_pool");
>> ? ? ? ? ? ? ? radeon_mem_types_list[i].name = radeon_mem_types_names[i];
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index f8187ea..0df71ea 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
>> tmp)
>> ? ? ? else
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> ?#endif
>> -#if defined(__sparc__)
>> +#if defined(__sparc__) || defined(__mips__)
>> ? ? ? if (!(caching_flags & TTM_PL_FLAG_CACHED))
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> ?#endif
>> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
>> index ee5389d..1d1a858 100644
>> --- a/include/drm/drm_sarea.h
>> +++ b/include/drm/drm_sarea.h
>> @@ -37,6 +37,8 @@
>> ?/* SAREA area needs to be at least a page */
>> ?#if defined(__alpha__)
>> ?#define SAREA_MAX ? ? ? ? ? ? ? ? ? ? ? 0x2000U
>> +#elif defined(__mips__)
>> +#define SAREA_MAX ? ? ? ? ? ? ? ? ? ? ? 0x4000U
>> ?#elif defined(__ia64__)
>> ?#define SAREA_MAX ? ? ? ? ? ? ? ? ? ? ? 0x1U ? ? /* 64kB */
>> ?#else
>
>


[PATCH] lib/scatterlist: do not re-write gfp_flags in __sg_alloc_table

2012-06-22 Thread Mandeep Singh Baines
We are seeing a lot of sg_alloc_table allocation failures using the
new drm prime infrastructure. We isolated the cause to code in
__sg_alloc_table that was re-writing the gfp_flags.

There is a comment in the code that suggest that there is an
assumption about the allocation coming from a memory pool. This was
likely true when sg lists were primarily used for disk I/O.

Change-Id: I459169f56e4a9aa859661b22ec9d4e6925f99e85
Signed-off-by: Mandeep Singh Baines 
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Jens Axboe 
Cc: Paul Gortmaker 
Cc: Cong Wang 
Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: Sumit Semwal 
Cc: Inki Dae 
Cc: Dave Airlie 
Cc: Sonny Rao 
Cc: Olof Johansson 
---
 lib/scatterlist.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 6096e89..d09bdd8 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -279,14 +279,6 @@ int __sg_alloc_table(struct sg_table *table, unsigned int 
nents,
if (!left)
sg_mark_end(&sg[sg_size - 1]);
 
-   /*
-* only really needed for mempool backed sg allocations (like
-* SCSI), a possible improvement here would be to pass the
-* table pointer into the allocator and let that clear these
-* flags
-*/
-   gfp_mask &= ~__GFP_WAIT;
-   gfp_mask |= __GFP_HIGH;
prv = sg;
} while (left);
 
-- 
1.7.7.3

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


[PATCH] lib/scatterlist: do not re-write gfp_flags in __sg_alloc_table

2012-06-22 Thread Mandeep Singh Baines
We are seeing a lot of sg_alloc_table allocation failures using the
new drm prime infrastructure. We isolated the cause to code in
__sg_alloc_table that was re-writing the gfp_flags.

There is a comment in the code that suggest that there is an
assumption about the allocation coming from a memory pool. This was
likely true when sg lists were primarily used for disk I/O.

Change-Id: I459169f56e4a9aa859661b22ec9d4e6925f99e85
Signed-off-by: Mandeep Singh Baines 
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: Jens Axboe 
Cc: Paul Gortmaker 
Cc: Cong Wang 
Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: Sumit Semwal 
Cc: Inki Dae 
Cc: Dave Airlie 
Cc: Sonny Rao 
Cc: Olof Johansson 
---
 lib/scatterlist.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 6096e89..d09bdd8 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -279,14 +279,6 @@ int __sg_alloc_table(struct sg_table *table, unsigned int 
nents,
if (!left)
sg_mark_end(&sg[sg_size - 1]);

-   /*
-* only really needed for mempool backed sg allocations (like
-* SCSI), a possible improvement here would be to pass the
-* table pointer into the allocator and let that clear these
-* flags
-*/
-   gfp_mask &= ~__GFP_WAIT;
-   gfp_mask |= __GFP_HIGH;
prv = sg;
} while (left);

-- 
1.7.7.3



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

2012-06-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #62159|0   |1
is obsolete||

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


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

2012-06-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #62158|0   |1
is obsolete||

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


[PATCH 4/5] DRM: add i.MX IPUv3 base driver

2012-06-22 Thread Shawn Guo
On Thu, Jun 14, 2012 at 03:43:26PM +0200, Sascha Hauer wrote:
...
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

This seems not needed at all.

> +#include 
> +#include 
> +#include 

...

> +void ipu_ch_param_set_field(struct ipu_ch_param __iomem *base, u32 wbs, u32 
> v)

Rename it to ipu_ch_param_write_field ...

> +{
> + u32 bit = (wbs >> 8) % 160;
> + u32 size = wbs & 0xff;
> + u32 word = (wbs >> 8) / 160;
> + u32 i = bit / 32;
> + u32 ofs = bit % 32;
> + u32 mask = (1 << size) - 1;
> + u32 val;
> +
> + pr_debug("%s %d %d %d\n", __func__, word, bit , size);
> +
> + val = readl(&base->word[word].data[i]);
> + val &= ~(mask << ofs);
> + val |= v << ofs;
> + writel(val, &base->word[word].data[i]);
> +
> + if ((bit + size - 1) / 32 > i) {
> + val = readl(&base->word[word].data[i + 1]);
> + val &= ~(mask >> (mask ? (32 - ofs) : 0));
> + val |= v >> (ofs ? (32 - ofs) : 0);
> + writel(val, &base->word[word].data[i + 1]);
> + }
> +}
> +EXPORT_SYMBOL_GPL(ipu_ch_param_set_field);
> +
> +u32 ipu_ch_param_read_field(struct ipu_ch_param __iomem *base, u32 wbs)

... or rename this to ipu_ch_param_get_field for a better couple?

> +{
> + u32 bit = (wbs >> 8) % 160;
> + u32 size = wbs & 0xff;
> + u32 word = (wbs >> 8) / 160;
> + u32 i = bit / 32;
> + u32 ofs = bit % 32;
> + u32 mask = (1 << size) - 1;
> + u32 val = 0;
> +
> + pr_debug("%s %d %d %d\n", __func__, word, bit , size);
> +
> + val = (readl(&base->word[word].data[i]) >> ofs) & mask;
> +
> + if ((bit + size - 1) / 32 > i) {
> + u32 tmp;
> + tmp = readl(&base->word[word].data[i + 1]);
> + tmp &= mask >> (ofs ? (32 - ofs) : 0);
> + val |= tmp << (ofs ? (32 - ofs) : 0);
> + }
> +
> + return val;
> +}
> +EXPORT_SYMBOL_GPL(ipu_ch_param_read_field);

...

> +static int ipu_reset(struct ipu_soc *ipu)
> +{
> + int timeout = 1;

We may want to use a better timeout mechanism.

> +
> + ipu_cm_write(ipu, 0x807F, IPU_MEM_RST);
> +
> + while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
> + if (!timeout--)
> + return -ETIME;
> + udelay(100);
> + }
> +
> + mdelay(300);
> +
> + return 0;
> +}

...

> +static int ipu_irq_init(struct ipu_soc *ipu)
> +{
> + int i;
> +
> + ipu->irq_start = irq_alloc_descs(-1, 0, IPU_NUM_IRQS, 0);

We may want to give a try on linear irqdomain, so that irqdesc will
only be allocated for those in-use irqs, and we do not have to maintain
irq_base.

> + if (ipu->irq_start < 0)
> + return ipu->irq_start;
> +
> + for (i = ipu->irq_start; i < ipu->irq_start + IPU_NUM_IRQS; i++) {
> + irq_set_chip_and_handler(i, &ipu_irq_chip, handle_level_irq);
> + set_irq_flags(i, IRQF_VALID);
> + irq_set_chip_data(i, ipu);
> + }
> +
> + irq_set_chained_handler(ipu->irq_sync, ipu_irq_handler);
> + irq_set_handler_data(ipu->irq_sync, ipu);
> + irq_set_chained_handler(ipu->irq_err, ipu_err_irq_handler);
> + irq_set_handler_data(ipu->irq_err, ipu);
> +
> + return 0;
> +}

...

> +static int __devinit ipu_probe(struct platform_device *pdev)
> +{
> + const struct of_device_id *of_id =
> + of_match_device(imx_ipu_dt_ids, &pdev->dev);
> + struct ipu_soc *ipu;
> + struct resource *res;
> + unsigned long ipu_base;
> + int i, ret, irq_sync, irq_err;
> + struct ipu_devtype *devtype;
> +
> + devtype = of_id->data;
> +
> + dev_info(&pdev->dev, "Initializing %s\n", devtype->name);
> +
> + irq_sync = platform_get_irq(pdev, 0);
> + irq_err = platform_get_irq(pdev, 1);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + dev_info(&pdev->dev, "irq_sync: %d irq_err: %d\n",
> + irq_sync, irq_err);
> +
> + if (!res || irq_sync < 0 || irq_err < 0)
> + return -ENODEV;
> +
> + ipu_base = res->start;
> +
> + ipu = devm_kzalloc(&pdev->dev, sizeof(*ipu), GFP_KERNEL);
> + if (!ipu)
> + return -ENODEV;
> +
> + for (i = 0; i < 64; i++)
> + ipu->channel[i].ipu = ipu;
> + ipu->devtype = devtype;
> + ipu->ipu_type = devtype->type;
> +
> + spin_lock_init(&ipu->lock);
> + mutex_init(&ipu->channel_lock);
> +
> + dev_info(&pdev->dev, "cm_reg:   0x%08lx\n",
> + ipu_base + devtype->cm_ofs);
> + dev_info(&pdev->dev, "idmac:0x%08lx\n",
> + ipu_base + devtype->cm_ofs + IPU_CM_IDMAC_REG_OFS);
> + dev_info(&pdev->dev, "cpmem:0x%08lx\n",
> + ipu_base + devtype->cpmem_ofs);
> + dev_info(&pdev->dev, "disp0:0x%08lx\n",
> + ipu_base + devtype->disp

[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Huacai Chen
On Fri, Jun 22, 2012 at 1:25 PM, Lucas Stach  wrote:
> Hello Huacai,
>
> Am Freitag, den 22.06.2012, 11:01 +0800 schrieb Huacai Chen:
>> 1, Handle io prot correctly for MIPS.
>> 2, Define SAREA_MAX as the size of one page.
>> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>> ? ?when use swiotlb, GPU reset occurs at resume from suspend).
>>
> I still think this is wrong. You say Loongson needs SWIOTLB, but when
> it's actually used you ignore it in the radeon driver code.
>
> I looked up why you are using SWIOTLB and I don't agree with you that it
> is needed. SWIOTLB just gives you bounce pages for DMA memory above
> DMA32 and therefore papers over your >4GB DMA platform bug in some
> cases, while hurting performance.
>
> Please fix your DMA platform code so that region DMA is an alias for
> region DMA32. It should allow you to drop all those ugly workarounds.
>
Hmm, you are probably right, I think I should have a discuss with the
original author of this part of code.

>> Signed-off-by: Huacai Chen 
>> Signed-off-by: Hongliang Tao 
>> Signed-off-by: Hua Yan 
>> Reviewed-by: Michel D?nzer 
>> Reviewed-by: Alex Deucher 
>> Reviewed-by: Lucas Stach 
>> Reviewed-by: j.glisse 
>
> You should probably only stick this tag on your patches after the people
> you are naming explicitly gave their r-b for a specific version of a
> patch.
>
> Thanks,
> Lucas
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ?| ? ?2 +-
>> ?drivers/gpu/drm/radeon/radeon_ttm.c | ? ?6 +++---
>> ?drivers/gpu/drm/ttm/ttm_bo_util.c ? | ? ?2 +-
>> ?include/drm/drm_sarea.h ? ? ? ? ? ? | ? ?2 ++
>> ?4 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
>> vm_area_struct *vma)
>> ? ? ? ? ? ? ? tmp = pgprot_writecombine(tmp);
>> ? ? ? else
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>> ? ? ? tmp = pgprot_noncached(tmp);
>> ?#endif
>> ? ? ? return tmp;
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>> index c94a225..f49bdd1 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>> @@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>> ? ? ? }
>> ?#endif
>>
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>> ? ? ? if (swiotlb_nr_tbl()) {
>> ? ? ? ? ? ? ? return ttm_dma_populate(>t->ttm, rdev->dev);
>> ? ? ? }
>> @@ -676,7 +676,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>> ? ? ? }
>> ?#endif
>>
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>> ? ? ? if (swiotlb_nr_tbl()) {
>> ? ? ? ? ? ? ? ttm_dma_unpopulate(>t->ttm, rdev->dev);
>> ? ? ? ? ? ? ? return;
>> @@ -906,7 +906,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
>> *rdev)
>> ? ? ? radeon_mem_types_list[i].show = &ttm_page_alloc_debugfs;
>> ? ? ? radeon_mem_types_list[i].driver_features = 0;
>> ? ? ? radeon_mem_types_list[i++].data = NULL;
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>> ? ? ? if (swiotlb_nr_tbl()) {
>> ? ? ? ? ? ? ? sprintf(radeon_mem_types_names[i], "ttm_dma_page_pool");
>> ? ? ? ? ? ? ? radeon_mem_types_list[i].name = radeon_mem_types_names[i];
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index f8187ea..0df71ea 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
>> tmp)
>> ? ? ? else
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> ?#endif
>> -#if defined(__sparc__)
>> +#if defined(__sparc__) || defined(__mips__)
>> ? ? ? if (!(caching_flags & TTM_PL_FLAG_CACHED))
>> ? ? ? ? ? ? ? tmp = pgprot_noncached(tmp);
>> ?#endif
>> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
>> index ee5389d..1d1a858 100644
>> --- a/include/drm/drm_sarea.h
>> +++ b/include/drm/drm_sarea.h
>> @@ -37,6 +37,8 @@
>> ?/* SAREA area needs to be at least a page */
>> ?#if defined(__alpha__)
>> ?#define SAREA_MAX ? ? ? ? ? ? ? ? ? ? ? 0x2000U
>> +#elif defined(__mips__)
>> +#define SAREA_MAX ? ? ? ? ? ? ? ? ? ? ? 0x4000U
>> ?#elif defined(__ia64__)
>> ?#define SAREA_MAX ? ? ? ? ? ? ? ? ? ? ? 0x1U ? ? /* 64kB */
>> ?#else
>
>


[PATCH] mgag200: Fix a memory leak in mgag200fb_create()

2012-06-22 Thread devendra.aaru
On Fri, Jun 22, 2012 at 3:43 AM, Jesper Juhl  wrote:
> First we allocate memory for 'sysram' with vmalloc() and subsequently
> we allocate for 'info' with framebuffer_alloc(). If the second
> allocation fails we return -ENOMEM, but neglect to vfree() the memory
> we previously allocated for 'sysram', thus leaking it.
>
Hi Jesper,

> Signed-off-by: Jesper Juhl 
> ---
> ?drivers/gpu/drm/mgag200/mgag200_fb.c | 4 +++-
> ?1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
> b/drivers/gpu/drm/mgag200/mgag200_fb.c
> index 880d336..3c837e5 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_fb.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
> @@ -156,8 +156,10 @@ static int mgag200fb_create(struct mga_fbdev *mfbdev,
> ? ? ? ? ? ? ? ?return -ENOMEM;
>
> ? ? ? ?info = framebuffer_alloc(0, device);
> - ? ? ? if (info == NULL)
> + ? ? ? if (info == NULL) {
> + ? ? ? ? ? ? ? vfree(sysram);
> ? ? ? ? ? ? ? ?return -ENOMEM;
> + ? ? ? }
>
> ? ? ? ?info->par = mfbdev;
>
This looks ok. but what about the error path?
there are more leaks at error paths. mgag200_framebuffer_init failcase
and the functions below like,
fb_alloc_cmap,
alloc_apertures,
?

> --
> 1.7.11
>
>
> --
> Jesper Juhl  ? ? ? http://www.chaosbits.net/
> Don't top-post http://www.catb.org/jargon/html/T/top-post.html
> Plain text mails only, please.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/


[PATCH 2/5] DRM i.MX: Add parallel display support

2012-06-22 Thread Shawn Guo
On Thu, Jun 14, 2012 at 03:43:24PM +0200, Sascha Hauer wrote:
> +static int __devinit imx_pd_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + const u8 *edidp;
> + struct imx_parallel_display *imxpd;
> + int ret;
> + u32 crtcs[2];

It seems used nowhere.

> + const char *fmt;
> + struct device_node *crtc_node;

Ditto.

> +
> + imxpd = devm_kzalloc(&pdev->dev, sizeof(*imxpd), GFP_KERNEL);
> + if (!imxpd)
> + return -ENOMEM;
> +
> + edidp = of_get_property(np, "edid", &imxpd->edid_len);
> + if (edidp)
> + imxpd->edid = kmemdup(edidp, imxpd->edid_len, GFP_KERNEL);
> +
> + ret = of_property_read_string(np, "interface_pix_fmt", &fmt);
> + if (!ret) {
> + if (!strcmp(fmt, "rgb24"))
> + imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB24;
> + else if (!strcmp(fmt, "rgb565"))
> + imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
> + }
> +
> + imxpd->dev = &pdev->dev;
> +
> + ret = imx_pd_register(imxpd);
> + if (ret)
> + return ret;
> +
> + ret = imx_drm_encoder_add_possible_crtcs(imxpd->imx_drm_encoder, np);
> +
> + platform_set_drvdata(pdev, imxpd);
> +
> + return 0;
> +}

-- 
Regards,
Shawn



[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Ralf Baechle
On Fri, Jun 22, 2012 at 06:55:40PM +0800, Huacai Chen wrote:

> > btw, would it be a good idea to use uncached accelerated instead ?
> I have tried uncached accelerated, there will be random points in the
> monitor, it seems a hw issue...

Have you flushed the pages from memory before switching their cache mode
to uncached accelerated?  The MIPS architecture defines the result of
mixing cache modes as UNPREDICTABLE so be careful to flush caches before
switching cache mode of a page.

  Ralf


[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Ralf Baechle
On Fri, Jun 22, 2012 at 11:39:19AM +0200, Arnaud Patard wrote:

> > --- a/drivers/gpu/drm/drm_vm.c
> > +++ b/drivers/gpu/drm/drm_vm.c
> > @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
> > vm_area_struct *vma)
> > tmp = pgprot_writecombine(tmp);
> > else
> > tmp = pgprot_noncached(tmp);
> > -#elif defined(__sparc__) || defined(__arm__)
> > +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
> > tmp = pgprot_noncached(tmp);
> 
> btw, would it be a good idea to use uncached accelerated instead ?

Not unconditionally.  Only some MIPS cores support uncached accelerated.
Basically you can only assume that cache modes 2 (uncached) (3 cachable
non-coherent) are supported.  On a SMP system use of 2 and 3 may be
unwise (SGI IP27 and IP35 may throw obscure exceptions to indicate their
dislike of these.) and on multi-processor systems there is mode 5, which
is cachable coherent.

The necessary logic is too complex to got into drm_io_prot() which already
is an #ifdef mess anyway so that function should be changed to call some
sort of architecutre specific hook so that function should be changed to
call some sort of architecture specific hook...

  Ralf


[Bug 51344] massive corruption on RV410

2012-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=51344

--- Comment #2 from Tormod Volden  2012-06-22 
11:50:37 PDT ---
Created attachment 63359
  --> https://bugs.freedesktop.org/attachment.cgi?id=63359
screenshot (no xorg.conf options)

-- 
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 V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Arnaud Patard (Rtp)

Hi,

Huacai Chen  writes:

> 1, Handle io prot correctly for MIPS.
> 2, Define SAREA_MAX as the size of one page.
> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>when use swiotlb, GPU reset occurs at resume from suspend).
>
> Signed-off-by: Huacai Chen 
> Signed-off-by: Hongliang Tao 
> Signed-off-by: Hua Yan 
> Reviewed-by: Michel D?nzer 
> Reviewed-by: Alex Deucher 
> Reviewed-by: Lucas Stach 
> Reviewed-by: j.glisse 
> Cc: dri-devel at lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_vm.c|2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c |6 +++---
>  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
>  include/drm/drm_sarea.h |2 ++
>  4 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 961ee08..3f06166 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
> vm_area_struct *vma)
>   tmp = pgprot_writecombine(tmp);
>   else
>   tmp = pgprot_noncached(tmp);
> -#elif defined(__sparc__) || defined(__arm__)
> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>   tmp = pgprot_noncached(tmp);

btw, would it be a good idea to use uncached accelerated instead ?

Arnaud


[Bug 51344] massive corruption on RV410

2012-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=51344

--- Comment #1 from Tormod Volden  2012-06-22 
11:22:39 PDT ---
Created attachment 63357
  --> https://bugs.freedesktop.org/attachment.cgi?id=63357
dmesg output

-- 
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 51344] massive corruption on RV410

2012-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=51344

Tormod Volden  changed:

   What|Removed |Added

Summary|massive corruption on RV515 |massive corruption on RV410

-- 
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 51344] New: massive corruption on RV515

2012-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=51344

 Bug #: 51344
   Summary: massive corruption on RV515
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: bugzi11.fdo.tor...@xoxy.net


Created attachment 63356
  --> https://bugs.freedesktop.org/attachment.cgi?id=63356
Xorg.0.log

This happened early May on drm-next somewhere between 4f256e8..d3029b4, and is
still there in 3.5rc3 (and in current drm-next).

Things are smeared out vertically. Looks like desktop background is not
corrupted. By turning off "EXABitmaps" there is less corruption.

I haven't done git bisecting, only download bisecting from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/ and
v3.4-rc6-295-g4f256e8 from May 8th was good and v3.4-rc6-315-gd3029b4 from May
10th was bad. Unfortunately the build from May 9th has been deleted in the
meantime so I can not narrow it down further this way. So the commits in
question should be:

d3029b4 drm/radeon/kms: fix warning on 32-bit in atomic fence printing
f2e3922 drm/radeon: make the ib an inline object
f237750 drm/radeon: remove r600 blit mutex v2
68470ae drm/radeon: move the semaphore from the fence into the ib
7c0d409 drm/radeon: immediately free ttm-move semaphore
c507f7e drm/radeon: rip out the ib pool
a8c0594 drm/radeon: simplify semaphore handling v2
c3b7fe8 drm/radeon: multiple ring allocator v3
0085c950 drm/radeon: use one wait queue for all rings add fence_wait_any v2
557017a drm/radeon: define new SA interface v3
2e0d991 drm/radeon: make sa bo a stand alone object
e6661a9 drm/radeon: keep start and end offset in the SA
711a972 drm/radeon: add sub allocator debugfs file
a651c55 drm/radeon: add proper locking to the SA v3
dd8bea2 drm/radeon: use inline functions to calc sa_bo addr
8a47cc9 drm/radeon: rework locking ring emission mutex in fence deadlock
detection v2
3b7a2b2 drm/radeon: rework fence handling, drop fence list v7
bb63556 drm/radeon: convert fence to uint64_t v4
d6999bc drm/radeon: replace the per ring mutex with a global one
133f4cb drm/radeon: fix possible lack of synchronization btw ttm and other ring

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
Radeon Mobility X700 (PCIE) [1002:5653]

-- 
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 V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Huacai Chen
1, Handle io prot correctly for MIPS.
2, Define SAREA_MAX as the size of one page.
3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
   when use swiotlb, GPU reset occurs at resume from suspend).

Signed-off-by: Huacai Chen 
Signed-off-by: Hongliang Tao 
Signed-off-by: Hua Yan 
Reviewed-by: Michel D?nzer 
Reviewed-by: Alex Deucher 
Reviewed-by: Lucas Stach 
Reviewed-by: j.glisse 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_vm.c|2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c |6 +++---
 drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
 include/drm/drm_sarea.h |2 ++
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..3f06166 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
vm_area_struct *vma)
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
-#elif defined(__sparc__) || defined(__arm__)
+#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
 #endif
return tmp;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index c94a225..f49bdd1 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
}
 #endif

-#ifdef CONFIG_SWIOTLB
+#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
if (swiotlb_nr_tbl()) {
return ttm_dma_populate(>t->ttm, rdev->dev);
}
@@ -676,7 +676,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
}
 #endif

-#ifdef CONFIG_SWIOTLB
+#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>t->ttm, rdev->dev);
return;
@@ -906,7 +906,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
*rdev)
radeon_mem_types_list[i].show = &ttm_page_alloc_debugfs;
radeon_mem_types_list[i].driver_features = 0;
radeon_mem_types_list[i++].data = NULL;
-#ifdef CONFIG_SWIOTLB
+#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
if (swiotlb_nr_tbl()) {
sprintf(radeon_mem_types_names[i], "ttm_dma_page_pool");
radeon_mem_types_list[i].name = radeon_mem_types_names[i];
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..0df71ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
else
tmp = pgprot_noncached(tmp);
 #endif
-#if defined(__sparc__)
+#if defined(__sparc__) || defined(__mips__)
if (!(caching_flags & TTM_PL_FLAG_CACHED))
tmp = pgprot_noncached(tmp);
 #endif
diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
index ee5389d..1d1a858 100644
--- a/include/drm/drm_sarea.h
+++ b/include/drm/drm_sarea.h
@@ -37,6 +37,8 @@
 /* SAREA area needs to be at least a page */
 #if defined(__alpha__)
 #define SAREA_MAX   0x2000U
+#elif defined(__mips__)
+#define SAREA_MAX   0x4000U
 #elif defined(__ia64__)
 #define SAREA_MAX   0x1U   /* 64kB */
 #else
-- 
1.7.7.3



[PATCH] drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

2012-06-22 Thread Daniel Vetter
On Fri, Jun 22, 2012 at 09:43:07AM +0200, Sjoerd Simons wrote:
> This box claims to have an LVDS interface but doesn't
> actually have one.
> 
> Signed-off-by: Sjoerd Simons 
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48


[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Christian König
Hello Huacai,


On 22.06.2012 07:59, Huacai Chen wrote:
> On Fri, Jun 22, 2012 at 1:25 PM, Lucas Stach  wrote:
>> Hello Huacai,
>>
>> Am Freitag, den 22.06.2012, 11:01 +0800 schrieb Huacai Chen:
[SNIP]
>>> Signed-off-by: Huacai Chen
>>> Signed-off-by: Hongliang Tao
>>> Signed-off-by: Hua Yan
>>> Reviewed-by: Michel D?nzer
>>> Reviewed-by: Alex Deucher
>>> Reviewed-by: Lucas Stach
>>> Reviewed-by: j.glisse
>> You should probably only stick this tag on your patches after the people
>> you are naming explicitly gave their r-b for a specific version of a
>> patch.
Yes indeed, a "Reviewed-by" line usually means that the person giving 
you that line has read your code and has none or very few negative 
comments about it, e.g. something like "change this and that and then 
its "Reviewed-by: ".

>>
>> Thanks,
>> Lucas
>>> Cc: dri-devel at lists.freedesktop.org
>>> ---
>>>   drivers/gpu/drm/drm_vm.c|2 +-
>>>   drivers/gpu/drm/radeon/radeon_ttm.c |6 +++---
>>>   drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
>>>   include/drm/drm_sarea.h |2 ++
>>>   4 files changed, 7 insertions(+), 5 deletions(-)

>>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c

I would suggest to either split the patches into seperate ones for drm, 
ttm & radeon or change the subject line, cause a subject line starting 
with "drm/radeon..." usually means that you have only changed something 
in the radeon driver.

In the unlikely case that you broke someones else code it would be quite 
surprising that a patch with a subject line indicating only drm/radeon 
changes breaks common drm code.

Otherwise it is nice to know that only a few define changes gets the 
driver going on a complete different CPU platform, keep up with the good 
work.

Regards,
Christian.

>>> index 961ee08..3f06166 100644
>>> --- a/drivers/gpu/drm/drm_vm.c
>>> +++ b/drivers/gpu/drm/drm_vm.c
>>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
>>> vm_area_struct *vma)
>>>tmp = pgprot_writecombine(tmp);
>>>else
>>>tmp = pgprot_noncached(tmp);
>>> -#elif defined(__sparc__) || defined(__arm__)
>>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>>>tmp = pgprot_noncached(tmp);
>>>   #endif
>>>return tmp;
>>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
>>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>>> index c94a225..f49bdd1 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>>> @@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>>>}
>>>   #endif
>>>
>>> -#ifdef CONFIG_SWIOTLB
>>> +#if defined(CONFIG_SWIOTLB)&&  !defined(CONFIG_CPU_LOONGSON3)
>>>if (swiotlb_nr_tbl()) {
>>>return ttm_dma_populate(>t->ttm, rdev->dev);
>>>}
>>> @@ -676,7 +676,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>>>}
>>>   #endif
>>>
>>> -#ifdef CONFIG_SWIOTLB
>>> +#if defined(CONFIG_SWIOTLB)&&  !defined(CONFIG_CPU_LOONGSON3)
>>>if (swiotlb_nr_tbl()) {
>>>ttm_dma_unpopulate(>t->ttm, rdev->dev);
>>>return;
>>> @@ -906,7 +906,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
>>> *rdev)
>>>radeon_mem_types_list[i].show =&ttm_page_alloc_debugfs;
>>>radeon_mem_types_list[i].driver_features = 0;
>>>radeon_mem_types_list[i++].data = NULL;
>>> -#ifdef CONFIG_SWIOTLB
>>> +#if defined(CONFIG_SWIOTLB)&&  !defined(CONFIG_CPU_LOONGSON3)
>>>if (swiotlb_nr_tbl()) {
>>>sprintf(radeon_mem_types_names[i], "ttm_dma_page_pool");
>>>radeon_mem_types_list[i].name = radeon_mem_types_names[i];
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
>>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>>> index f8187ea..0df71ea 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>>> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
>>> tmp)
>>>else
>>>tmp = pgprot_noncached(tmp);
>>>   #endif
>>> -#if defined(__sparc__)
>>> +#if defined(__sparc__) || defined(__mips__)
>>>if (!(caching_flags&  TTM_PL_FLAG_CACHED))
>>>tmp = pgprot_noncached(tmp);
>>>   #endif
>>> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
>>> index ee5389d..1d1a858 100644
>>> --- a/include/drm/drm_sarea.h
>>> +++ b/include/drm/drm_sarea.h
>>> @@ -37,6 +37,8 @@
>>>   /* SAREA area needs to be at least a page */
>>>   #if defined(__alpha__)
>>>   #define SAREA_MAX   0x2000U
>>> +#elif defined(__mips__)
>>> +#define SAREA_MAX   0x4000U
>>>   #elif defined(__ia64__)
>>>   #define SAREA_MAX   0x1U /* 64kB */
>>>   #else
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

2012-06-22 Thread Sjoerd Simons
This box claims to have an LVDS interface but doesn't
actually have one.

Signed-off-by: Sjoerd Simons 
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 08eb04c..9393860 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -777,6 +777,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "ZOTAC ZBOXSD-ID12/ID13",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "ZOTAC"),
+   DMI_MATCH(DMI_BOARD_NAME, "ZBOXSD-ID12/ID13"),
+   },
+   },

{ } /* terminating entry */
 };
-- 
1.7.10



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

2012-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Michel Dänzer  changed:

   What|Removed |Added

  Attachment #62159|0   |1
is obsolete||

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

2012-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Michel Dänzer  changed:

   What|Removed |Added

  Attachment #62158|0   |1
is obsolete||

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

2012-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Michel Dänzer  changed:

   What|Removed |Added

  Attachment #62157|0   |1
is obsolete||

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

2012-06-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #62157|0   |1
is obsolete||

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


[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Lucas Stach
Hello Huacai,

Am Freitag, den 22.06.2012, 11:01 +0800 schrieb Huacai Chen:
> 1, Handle io prot correctly for MIPS.
> 2, Define SAREA_MAX as the size of one page.
> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>when use swiotlb, GPU reset occurs at resume from suspend).
> 
I still think this is wrong. You say Loongson needs SWIOTLB, but when
it's actually used you ignore it in the radeon driver code.

I looked up why you are using SWIOTLB and I don't agree with you that it
is needed. SWIOTLB just gives you bounce pages for DMA memory above
DMA32 and therefore papers over your >4GB DMA platform bug in some
cases, while hurting performance.

Please fix your DMA platform code so that region DMA is an alias for
region DMA32. It should allow you to drop all those ugly workarounds.

> Signed-off-by: Huacai Chen 
> Signed-off-by: Hongliang Tao 
> Signed-off-by: Hua Yan 
> Reviewed-by: Michel D?nzer 
> Reviewed-by: Alex Deucher 
> Reviewed-by: Lucas Stach 
> Reviewed-by: j.glisse 

You should probably only stick this tag on your patches after the people
you are naming explicitly gave their r-b for a specific version of a
patch.

Thanks,
Lucas
> Cc: dri-devel at lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_vm.c|2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c |6 +++---
>  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
>  include/drm/drm_sarea.h |2 ++
>  4 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 961ee08..3f06166 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
> vm_area_struct *vma)
>   tmp = pgprot_writecombine(tmp);
>   else
>   tmp = pgprot_noncached(tmp);
> -#elif defined(__sparc__) || defined(__arm__)
> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>   tmp = pgprot_noncached(tmp);
>  #endif
>   return tmp;
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index c94a225..f49bdd1 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>   }
>  #endif
>  
> -#ifdef CONFIG_SWIOTLB
> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>   if (swiotlb_nr_tbl()) {
>   return ttm_dma_populate(>t->ttm, rdev->dev);
>   }
> @@ -676,7 +676,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>   }
>  #endif
>  
> -#ifdef CONFIG_SWIOTLB
> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>   if (swiotlb_nr_tbl()) {
>   ttm_dma_unpopulate(>t->ttm, rdev->dev);
>   return;
> @@ -906,7 +906,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
> *rdev)
>   radeon_mem_types_list[i].show = &ttm_page_alloc_debugfs;
>   radeon_mem_types_list[i].driver_features = 0;
>   radeon_mem_types_list[i++].data = NULL;
> -#ifdef CONFIG_SWIOTLB
> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>   if (swiotlb_nr_tbl()) {
>   sprintf(radeon_mem_types_names[i], "ttm_dma_page_pool");
>   radeon_mem_types_list[i].name = radeon_mem_types_names[i];
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index f8187ea..0df71ea 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
>   else
>   tmp = pgprot_noncached(tmp);
>  #endif
> -#if defined(__sparc__)
> +#if defined(__sparc__) || defined(__mips__)
>   if (!(caching_flags & TTM_PL_FLAG_CACHED))
>   tmp = pgprot_noncached(tmp);
>  #endif
> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
> index ee5389d..1d1a858 100644
> --- a/include/drm/drm_sarea.h
> +++ b/include/drm/drm_sarea.h
> @@ -37,6 +37,8 @@
>  /* SAREA area needs to be at least a page */
>  #if defined(__alpha__)
>  #define SAREA_MAX   0x2000U
> +#elif defined(__mips__)
> +#define SAREA_MAX   0x4000U
>  #elif defined(__ia64__)
>  #define SAREA_MAX   0x1U /* 64kB */
>  #else




Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Ralf Baechle
On Fri, Jun 22, 2012 at 11:39:19AM +0200, Arnaud Patard wrote:

> > --- a/drivers/gpu/drm/drm_vm.c
> > +++ b/drivers/gpu/drm/drm_vm.c
> > @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
> > vm_area_struct *vma)
> > tmp = pgprot_writecombine(tmp);
> > else
> > tmp = pgprot_noncached(tmp);
> > -#elif defined(__sparc__) || defined(__arm__)
> > +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
> > tmp = pgprot_noncached(tmp);
> 
> btw, would it be a good idea to use uncached accelerated instead ?

Not unconditionally.  Only some MIPS cores support uncached accelerated.
Basically you can only assume that cache modes 2 (uncached) (3 cachable
non-coherent) are supported.  On a SMP system use of 2 and 3 may be
unwise (SGI IP27 and IP35 may throw obscure exceptions to indicate their
dislike of these.) and on multi-processor systems there is mode 5, which
is cachable coherent.

The necessary logic is too complex to got into drm_io_prot() which already
is an #ifdef mess anyway so that function should be changed to call some
sort of architecutre specific hook so that function should be changed to
call some sort of architecture specific hook...

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


Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Ralf Baechle
On Fri, Jun 22, 2012 at 06:55:40PM +0800, Huacai Chen wrote:

> > btw, would it be a good idea to use uncached accelerated instead ?
> I have tried uncached accelerated, there will be random points in the
> monitor, it seems a hw issue...

Have you flushed the pages from memory before switching their cache mode
to uncached accelerated?  The MIPS architecture defines the result of
mixing cache modes as UNPREDICTABLE so be careful to flush caches before
switching cache mode of a page.

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


Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Huacai Chen
On Fri, Jun 22, 2012 at 5:39 PM, Arnaud Patard
 wrote:
>
> Hi,
>
> Huacai Chen  writes:
>
>> 1, Handle io prot correctly for MIPS.
>> 2, Define SAREA_MAX as the size of one page.
>> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>>    when use swiotlb, GPU reset occurs at resume from suspend).
>>
>> Signed-off-by: Huacai Chen 
>> Signed-off-by: Hongliang Tao 
>> Signed-off-by: Hua Yan 
>> Reviewed-by: Michel Dänzer 
>> Reviewed-by: Alex Deucher 
>> Reviewed-by: Lucas Stach 
>> Reviewed-by: j.glisse 
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_vm.c            |    2 +-
>>  drivers/gpu/drm/radeon/radeon_ttm.c |    6 +++---
>>  drivers/gpu/drm/ttm/ttm_bo_util.c   |    2 +-
>>  include/drm/drm_sarea.h             |    2 ++
>>  4 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
>> vm_area_struct *vma)
>>               tmp = pgprot_writecombine(tmp);
>>       else
>>               tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>>       tmp = pgprot_noncached(tmp);
>
> btw, would it be a good idea to use uncached accelerated instead ?
I have tried uncached accelerated, there will be random points in the
monitor, it seems a hw issue...

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


Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Rtp

Hi,

Huacai Chen  writes:

> 1, Handle io prot correctly for MIPS.
> 2, Define SAREA_MAX as the size of one page.
> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>when use swiotlb, GPU reset occurs at resume from suspend).
>
> Signed-off-by: Huacai Chen 
> Signed-off-by: Hongliang Tao 
> Signed-off-by: Hua Yan 
> Reviewed-by: Michel Dänzer 
> Reviewed-by: Alex Deucher 
> Reviewed-by: Lucas Stach 
> Reviewed-by: j.glisse 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_vm.c|2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c |6 +++---
>  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
>  include/drm/drm_sarea.h |2 ++
>  4 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 961ee08..3f06166 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
> vm_area_struct *vma)
>   tmp = pgprot_writecombine(tmp);
>   else
>   tmp = pgprot_noncached(tmp);
> -#elif defined(__sparc__) || defined(__arm__)
> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>   tmp = pgprot_noncached(tmp);

btw, would it be a good idea to use uncached accelerated instead ?

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


Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Huacai Chen
On Fri, Jun 22, 2012 at 1:25 PM, Lucas Stach  wrote:
> Hello Huacai,
>
> Am Freitag, den 22.06.2012, 11:01 +0800 schrieb Huacai Chen:
>> 1, Handle io prot correctly for MIPS.
>> 2, Define SAREA_MAX as the size of one page.
>> 3, Don't use swiotlb on Loongson machines (Loonson need swioitlb, but
>>    when use swiotlb, GPU reset occurs at resume from suspend).
>>
> I still think this is wrong. You say Loongson needs SWIOTLB, but when
> it's actually used you ignore it in the radeon driver code.
>
> I looked up why you are using SWIOTLB and I don't agree with you that it
> is needed. SWIOTLB just gives you bounce pages for DMA memory above
> DMA32 and therefore papers over your >4GB DMA platform bug in some
> cases, while hurting performance.
>
> Please fix your DMA platform code so that region DMA is an alias for
> region DMA32. It should allow you to drop all those ugly workarounds.
>
Hi, Lucas, I disable SWIOTLB and still make sure DMA <4G, radeon and
sound card seems work fine, but OHCI still can't work. From git log
arch/mips/cavium-octeon/dma-octeon.c, it seems Cavium also need
SWIOTLB to avoid OHCI issue.

>> Signed-off-by: Huacai Chen 
>> Signed-off-by: Hongliang Tao 
>> Signed-off-by: Hua Yan 
>> Reviewed-by: Michel Dänzer 
>> Reviewed-by: Alex Deucher 
>> Reviewed-by: Lucas Stach 
>> Reviewed-by: j.glisse 
>
> You should probably only stick this tag on your patches after the people
> you are naming explicitly gave their r-b for a specific version of a
> patch.
>
> Thanks,
> Lucas
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_vm.c            |    2 +-
>>  drivers/gpu/drm/radeon/radeon_ttm.c |    6 +++---
>>  drivers/gpu/drm/ttm/ttm_bo_util.c   |    2 +-
>>  include/drm/drm_sarea.h             |    2 ++
>>  4 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
>> index 961ee08..3f06166 100644
>> --- a/drivers/gpu/drm/drm_vm.c
>> +++ b/drivers/gpu/drm/drm_vm.c
>> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
>> vm_area_struct *vma)
>>               tmp = pgprot_writecombine(tmp);
>>       else
>>               tmp = pgprot_noncached(tmp);
>> -#elif defined(__sparc__) || defined(__arm__)
>> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>>       tmp = pgprot_noncached(tmp);
>>  #endif
>>       return tmp;
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>> index c94a225..f49bdd1 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>> @@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>>       }
>>  #endif
>>
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>>       if (swiotlb_nr_tbl()) {
>>               return ttm_dma_populate(>t->ttm, rdev->dev);
>>       }
>> @@ -676,7 +676,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>>       }
>>  #endif
>>
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>>       if (swiotlb_nr_tbl()) {
>>               ttm_dma_unpopulate(>t->ttm, rdev->dev);
>>               return;
>> @@ -906,7 +906,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
>> *rdev)
>>       radeon_mem_types_list[i].show = &ttm_page_alloc_debugfs;
>>       radeon_mem_types_list[i].driver_features = 0;
>>       radeon_mem_types_list[i++].data = NULL;
>> -#ifdef CONFIG_SWIOTLB
>> +#if defined(CONFIG_SWIOTLB) && !defined(CONFIG_CPU_LOONGSON3)
>>       if (swiotlb_nr_tbl()) {
>>               sprintf(radeon_mem_types_names[i], "ttm_dma_page_pool");
>>               radeon_mem_types_list[i].name = radeon_mem_types_names[i];
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index f8187ea..0df71ea 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
>> tmp)
>>       else
>>               tmp = pgprot_noncached(tmp);
>>  #endif
>> -#if defined(__sparc__)
>> +#if defined(__sparc__) || defined(__mips__)
>>       if (!(caching_flags & TTM_PL_FLAG_CACHED))
>>               tmp = pgprot_noncached(tmp);
>>  #endif
>> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
>> index ee5389d..1d1a858 100644
>> --- a/include/drm/drm_sarea.h
>> +++ b/include/drm/drm_sarea.h
>> @@ -37,6 +37,8 @@
>>  /* SAREA area needs to be at least a page */
>>  #if defined(__alpha__)
>>  #define SAREA_MAX                       0x2000U
>> +#elif defined(__mips__)
>> +#define SAREA_MAX                       0x4000U
>>  #elif defined(__ia64__)
>>  #define SAREA_MAX                       0x1U     /* 64kB */
>>  #else
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] mgag200: Fix a memory leak in mgag200fb_create()

2012-06-22 Thread devendra.aaru
On Fri, Jun 22, 2012 at 3:43 AM, Jesper Juhl  wrote:
> First we allocate memory for 'sysram' with vmalloc() and subsequently
> we allocate for 'info' with framebuffer_alloc(). If the second
> allocation fails we return -ENOMEM, but neglect to vfree() the memory
> we previously allocated for 'sysram', thus leaking it.
>
Hi Jesper,

> Signed-off-by: Jesper Juhl 
> ---
>  drivers/gpu/drm/mgag200/mgag200_fb.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
> b/drivers/gpu/drm/mgag200/mgag200_fb.c
> index 880d336..3c837e5 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_fb.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
> @@ -156,8 +156,10 @@ static int mgag200fb_create(struct mga_fbdev *mfbdev,
>                return -ENOMEM;
>
>        info = framebuffer_alloc(0, device);
> -       if (info == NULL)
> +       if (info == NULL) {
> +               vfree(sysram);
>                return -ENOMEM;
> +       }
>
>        info->par = mfbdev;
>
This looks ok. but what about the error path?
there are more leaks at error paths. mgag200_framebuffer_init failcase
and the functions below like,
fb_alloc_cmap,
alloc_apertures,
?

> --
> 1.7.11
>
>
> --
> Jesper Juhl        http://www.chaosbits.net/
> Don't top-post http://www.catb.org/jargon/html/T/top-post.html
> Plain text mails only, please.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

2012-06-22 Thread Sjoerd Simons
This box claims to have an LVDS interface but doesn't
actually have one.

Signed-off-by: Sjoerd Simons 
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 08eb04c..9393860 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -777,6 +777,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "ZOTAC ZBOXSD-ID12/ID13",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "ZOTAC"),
+   DMI_MATCH(DMI_BOARD_NAME, "ZBOXSD-ID12/ID13"),
+   },
+   },
 
{ } /* terminating entry */
 };
-- 
1.7.10

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


Re: [PATCH] drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

2012-06-22 Thread Daniel Vetter
On Fri, Jun 22, 2012 at 09:43:07AM +0200, Sjoerd Simons wrote:
> This box claims to have an LVDS interface but doesn't
> actually have one.
> 
> Signed-off-by: Sjoerd Simons 
Queued for -next, thanks for the patch.
-Daniel
-- 
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 V3 11/16] drm/radeon: Make radeon card usable for Loongson.

2012-06-22 Thread Christian König

Hello Huacai,


On 22.06.2012 07:59, Huacai Chen wrote:

On Fri, Jun 22, 2012 at 1:25 PM, Lucas Stach  wrote:

Hello Huacai,

Am Freitag, den 22.06.2012, 11:01 +0800 schrieb Huacai Chen:

[SNIP]

Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
Reviewed-by: Michel Dänzer
Reviewed-by: Alex Deucher
Reviewed-by: Lucas Stach
Reviewed-by: j.glisse

You should probably only stick this tag on your patches after the people
you are naming explicitly gave their r-b for a specific version of a
patch.
Yes indeed, a "Reviewed-by" line usually means that the person giving 
you that line has read your code and has none or very few negative 
comments about it, e.g. something like "change this and that and then 
its "Reviewed-by: ".




Thanks,
Lucas

Cc: dri-devel@lists.freedesktop.org
---
  drivers/gpu/drm/drm_vm.c|2 +-
  drivers/gpu/drm/radeon/radeon_ttm.c |6 +++---
  drivers/gpu/drm/ttm/ttm_bo_util.c   |2 +-
  include/drm/drm_sarea.h |2 ++
  4 files changed, 7 insertions(+), 5 deletions(-)



diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c


I would suggest to either split the patches into seperate ones for drm, 
ttm & radeon or change the subject line, cause a subject line starting 
with "drm/radeon..." usually means that you have only changed something 
in the radeon driver.


In the unlikely case that you broke someones else code it would be quite 
surprising that a patch with a subject line indicating only drm/radeon 
changes breaks common drm code.


Otherwise it is nice to know that only a few define changes gets the 
driver going on a complete different CPU platform, keep up with the good 
work.


Regards,
Christian.


index 961ee08..3f06166 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
vm_area_struct *vma)
   tmp = pgprot_writecombine(tmp);
   else
   tmp = pgprot_noncached(tmp);
-#elif defined(__sparc__) || defined(__arm__)
+#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
   tmp = pgprot_noncached(tmp);
  #endif
   return tmp;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index c94a225..f49bdd1 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -630,7 +630,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
   }
  #endif

-#ifdef CONFIG_SWIOTLB
+#if defined(CONFIG_SWIOTLB)&&  !defined(CONFIG_CPU_LOONGSON3)
   if (swiotlb_nr_tbl()) {
   return ttm_dma_populate(>t->ttm, rdev->dev);
   }
@@ -676,7 +676,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
   }
  #endif

-#ifdef CONFIG_SWIOTLB
+#if defined(CONFIG_SWIOTLB)&&  !defined(CONFIG_CPU_LOONGSON3)
   if (swiotlb_nr_tbl()) {
   ttm_dma_unpopulate(>t->ttm, rdev->dev);
   return;
@@ -906,7 +906,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
*rdev)
   radeon_mem_types_list[i].show =&ttm_page_alloc_debugfs;
   radeon_mem_types_list[i].driver_features = 0;
   radeon_mem_types_list[i++].data = NULL;
-#ifdef CONFIG_SWIOTLB
+#if defined(CONFIG_SWIOTLB)&&  !defined(CONFIG_CPU_LOONGSON3)
   if (swiotlb_nr_tbl()) {
   sprintf(radeon_mem_types_names[i], "ttm_dma_page_pool");
   radeon_mem_types_list[i].name = radeon_mem_types_names[i];
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..0df71ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
   else
   tmp = pgprot_noncached(tmp);
  #endif
-#if defined(__sparc__)
+#if defined(__sparc__) || defined(__mips__)
   if (!(caching_flags&  TTM_PL_FLAG_CACHED))
   tmp = pgprot_noncached(tmp);
  #endif
diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
index ee5389d..1d1a858 100644
--- a/include/drm/drm_sarea.h
+++ b/include/drm/drm_sarea.h
@@ -37,6 +37,8 @@
  /* SAREA area needs to be at least a page */
  #if defined(__alpha__)
  #define SAREA_MAX   0x2000U
+#elif defined(__mips__)
+#define SAREA_MAX   0x4000U
  #elif defined(__ia64__)
  #define SAREA_MAX   0x1U /* 64kB */
  #else



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



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


[PATCH] mgag200: Fix a memory leak in mgag200fb_create()

2012-06-22 Thread Jesper Juhl
First we allocate memory for 'sysram' with vmalloc() and subsequently
we allocate for 'info' with framebuffer_alloc(). If the second
allocation fails we return -ENOMEM, but neglect to vfree() the memory
we previously allocated for 'sysram', thus leaking it.

Signed-off-by: Jesper Juhl 
---
 drivers/gpu/drm/mgag200/mgag200_fb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 880d336..3c837e5 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -156,8 +156,10 @@ static int mgag200fb_create(struct mga_fbdev *mfbdev,
return -ENOMEM;

info = framebuffer_alloc(0, device);
-   if (info == NULL)
+   if (info == NULL) {
+   vfree(sysram);
return -ENOMEM;
+   }

info->par = mfbdev;

-- 
1.7.11


-- 
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.