[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf

On Mon, Jul 09, 2012 at 03:13:25PM +0200, Henrik Rydberg wrote: > On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote: > > On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: > > > > Thanks for tracking down the source of this corruption. I don't have > > > > any such

Mesa shader compiling/optimizing process is too slow

I've done benchmarks and comparison between proprietary drivers and Mesa, Mesa seems to be up to 200x slower compiling the same shader, since i understand optimizing such part of code may take months or even more, i have thought to solve it this way: Upon calling glLinkProgram , an unoptimized

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 Chris Wilson changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 --- Comment #30 from stefan 2012-07-09 11:18:52 PDT --- Hi Daniel, (In reply to comment #29) > (In reply to comment #28) > > are there any news on this issue? > > The 3.4 and 3.5-rc series seem stable wrt this issue, > > but unfortunately

[RFC] drm/radeon: restoring ring commands in case of a lockup

On Mon, 2012-07-09 at 12:41 +0200, Christian K?nig wrote: > Hi, > > The following patchset tries to save and restore the not yet processed > commands > from the rings in case of a lockup and with that should make a userspace > problem with a single application far less problematic. > > The

[Bug 51870] r600_streamout=1 nothing change

https://bugs.freedesktop.org/show_bug.cgi?id=51870 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[PATCH 15/16] drm/radeon: implement ring commit tracking

On 09.07.2012 17:36, Jerome Glisse wrote: > On Mon, Jul 9, 2012 at 6:42 AM, Christian K?nig > wrote: >> Signed-off-by: Christian K?nig > Bit too complex to my taste, what about attached patch, it's lot > simpler. (Haven't tested > the patch but it should work) Cool idea! Depending on the

[PATCH 13/16] drm/radeon: move radeon_ib_ring_tests out of chipset code

On Mon, 2012-07-09 at 17:22 +0200, Christian K?nig wrote: > On 09.07.2012 17:06, Michel D?nzer wrote: > > On Mon, 2012-07-09 at 12:42 +0200, Christian K?nig wrote: > >> Making it easier to controlwhen it is executed. > >> > >> Signed-off-by: Christian K?nig > > [...] > >> diff --git

[PATCH 16/16] drm/radeon: implement ring saving on reset

On 09.07.2012 17:06, Michel D?nzer wrote: > On Mon, 2012-07-09 at 12:42 +0200, Christian K?nig wrote: >> Try to save whatever is on the rings when >> we encounter an lockup. >> >> Signed-off-by: Christian K?nig > [...] >> @@ -1005,20 +1010,43 @@ int radeon_gpu_reset(struct radeon_device *rdev) >>

[PATCH 13/16] drm/radeon: move radeon_ib_ring_tests out of chipset code

On 09.07.2012 17:06, Michel D?nzer wrote: > On Mon, 2012-07-09 at 12:42 +0200, Christian K?nig wrote: >> Making it easier to controlwhen it is executed. >> >> Signed-off-by: Christian K?nig > [...] >> diff --git a/drivers/gpu/drm/radeon/radeon_device.c >> b/drivers/gpu/drm/radeon/radeon_device.c

[PATCH 09/16] drm/radeon: make cp init on cayman more robust

On 09.07.2012 16:43, Jerome Glisse wrote: > On Mon, Jul 9, 2012 at 6:41 AM, Christian K?nig > wrote: >> It's not critical, but the current code isn't >> 100% correct. >> >> Signed-off-by: Christian K?nig >> --- >> drivers/gpu/drm/radeon/ni.c | 133 >>

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

This patch adds a exynos drm specific implementation of fb_mmap which supports mapping a non-contiguous buffer to user space. This new function does not assume that the frame buffer is contiguous and calls dma_mmap_writecombine for mapping the buffer to user space. dma_mmap_writecombine will be

[PATCH 13/16] drm/radeon: move radeon_ib_ring_tests out of chipset code

On Mon, 2012-07-09 at 12:42 +0200, Christian K?nig wrote: > Making it easier to controlwhen it is executed. > > Signed-off-by: Christian K?nig [...] > diff --git a/drivers/gpu/drm/radeon/radeon_device.c > b/drivers/gpu/drm/radeon/radeon_device.c > index 254fdb4..bbd0971 100644 > ---

[PATCH 16/16] drm/radeon: implement ring saving on reset

On Mon, 2012-07-09 at 12:42 +0200, Christian K?nig wrote: > Try to save whatever is on the rings when > we encounter an lockup. > > Signed-off-by: Christian K?nig [...] > @@ -1005,20 +1010,43 @@ int radeon_gpu_reset(struct radeon_device *rdev) > resched =

[PATCH v3] drm/exynos: use __free_page() to deallocate memory

this patch uses __free_page() to deallocate the pages allocated by alloc_page() and the pages doesn't need set_parge_dirty() and mark_page_accessed() because they aren't from page cache so removes them. this patch has a pair with previous patch below,

[PATCH v2] drm/exynos: use __free_page() to deallocate memory

this patch uses __free_page() to deallocate the pages allocated by alloc_page() and the pages doesn't need set_parge_dirty() and mark_page_accessed() because they aren't from page cache so removes them. this patch has a pair with previous patch below,

[PATCH 2/2] drm/exynos: fixed exception to page allocation failure

this patch corrects to deallocate the pages allocated already at alloc_page failure. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

[PATCH 1/2] drm/exynos: use __free_page() to deallocate memory

this patch uses __free_page() to deallocate the pages allocated by alloc_page() and the pages doesn't need set_parge_dirty() and mark_page_accessed() because they aren't from page cache so removes them. this patch has a pair with previous patch below,

[PATCH 0/2] fix memory deallocation and exception

this patch corrects to deallocate the pages allocated by alloc_page() and fixes exception to page allocation failure. Thanks. Inki Dae (2): drm/exynos: use __free_page() to deallocate memory drm/exynos: fixed exception to page allocation failure drivers/gpu/drm/exynos/exynos_drm_gem.c |

[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf

On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote: > On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: > > > Thanks for tracking down the source of this corruption. I don't have > > > any such hardware, so until someone can figure it out, I think we > > > should apply

[Bug 51870] r600_streamout=1 nothing change

https://bugs.freedesktop.org/show_bug.cgi?id=51870 Michel D?nzer changed: What|Removed |Added AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop

3.5-rc5: radeon acceleration regression on Transmeta system

> > > In 3.4, radeon worked with a glitch - window titles were see-throug (not > > > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables > > > acceleration on this system at all. Full dmesg below. > > > > Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32? >

[PATCH v2] drm/exynos: check if framebuffer and gem size are valid or not.

with addfb request by user, wrong framebuffer or gem size could be sent to kernel side so this could induce invalid memory access by dma of a device. this patch checks if framebuffer and gem size are valid or not to avoid this issue. Changelog v2: use fb->pitches instead of caculating it with

[git pull] drm/exynos: updated exynos-drm-fixes

Hi Dave, Please pull from git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes these patch sets below had already been posted several weeks ago for review and include some fixes and exceptions. thes patch sets are based on git repository below:

[PATCH 16/16] drm/radeon: implement ring saving on reset

Try to save whatever is on the rings when we encounter an lockup. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h|4 ++ drivers/gpu/drm/radeon/radeon_device.c | 44 drivers/gpu/drm/radeon/radeon_ring.c | 69

[PATCH 15/16] drm/radeon: implement ring commit tracking

Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h |3 +++ drivers/gpu/drm/radeon/radeon_ring.c | 39 -- 2 files changed, 40 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h

[PATCH 14/16] drm/radeon: make align a ring_init parameter

Instead of setting it directly from the chipset code. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c |3 ++- drivers/gpu/drm/radeon/ni.c |3 ++- drivers/gpu/drm/radeon/r100.c|3 +-- drivers/gpu/drm/radeon/r600.c|3 +--

[PATCH 13/16] drm/radeon: move radeon_ib_ring_tests out of chipset code

Making it easier to controlwhen it is executed. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/ni.c|4 drivers/gpu/drm/radeon/r100.c |4 drivers/gpu/drm/radeon/r300.c |4

[PATCH 12/16] drm/radeon: remove vm_manager start/suspend

Just restore the page table instead. Addressing three problem with this change: 1. Calling vm_manager_suspend in the suspend path is problematic cause it wants to wait for the VM use to end, which in case of a lockup never happens. 2. In case of a locked up memory controller unbinding

[PATCH 11/16] drm/radeon: remove r600_blit_suspend

Just reinitialize the shader content on resume instead. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c |1 - drivers/gpu/drm/radeon/evergreen_blit_kms.c | 40 +-- drivers/gpu/drm/radeon/ni.c |1 -

[PATCH 10/16] drm/radeon: remove ip_pool start/suspend

The IB pool is in gart memory, so it is completely superfluous to unpin / repin it on suspend / resume. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c | 17 ++--- drivers/gpu/drm/radeon/ni.c | 16 ++-- drivers/gpu/drm/radeon/r100.c

[PATCH 09/16] drm/radeon: make cp init on cayman more robust

It's not critical, but the current code isn't 100% correct. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/ni.c | 133 ++- 1 file changed, 56 insertions(+), 77 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c

[PATCH 08/16] drm/radeon: remove FIXME comment from chipset suspend

For a normal suspend/resume we allready wait for the rings to be empty, and for a suspend/reasume in case of a lockup we REALLY don't want to wait for anything. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c |1 - drivers/gpu/drm/radeon/ni.c|1 -

[PATCH 07/16] drm/radeon: fix fence init after resume

Start with last signaled fence number instead of last emitted one. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_fence.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index

[PATCH 06/16] drm/radeon: fix fence value access

It is possible that radeon_fence_process is called after writeback is disabled for suspend, leading to an invalid read of register 0x0. This fixes a problem for me where the fence value is temporary incremented by 0x1 on suspend/resume. Signed-off-by: Christian K?nig ---

[PATCH 05/16] drm/radeon: fix ring commit padding

We don't need to pad anything if the number of dwords written to the ring already matches the requirements. Fixes some "writting more dword to ring than expected" warnings. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_ring.c |7 +-- 1 file changed, 1 insertion(+), 6

[PATCH 04/16] drm/radeon: add an exclusive lock for GPU reset v2

From: Jerome Glisse GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

[PATCH 03/16] drm/radeon: fix fence related segfault in CS

Don't return success if scheduling the IB fails, otherwise we end up with an oops in ttm_eu_fence_buffer_objects. Signed-off-by: Christian K?nig Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_cs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 02/16] drm/radeon: add error handling to radeon_vm_unbind_locked

Waiting for a fence can fail for different reasons, the most common is a deadlock. Signed-off-by: Christian K?nig Reviewed-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_gart.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git

[PATCH 01/16] drm/radeon: add error handling to fence_wait_empty_locked

Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by: Christian K?nig Reviewed-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon.h |2 +- drivers/gpu/drm/radeon/radeon_fence.c | 33 +

[RFC] drm/radeon: restoring ring commands in case of a lockup

Hi, The following patchset tries to save and restore the not yet processed commands from the rings in case of a lockup and with that should make a userspace problem with a single application far less problematic. The first four patches are just stuff this patchset is based upon, followed by four

[PATCH 15/16] drm/radeon: implement ring commit tracking

On Mon, Jul 9, 2012 at 11:48 AM, Christian K?nig wrote: > On 09.07.2012 17:36, Jerome Glisse wrote: >> >> On Mon, Jul 9, 2012 at 6:42 AM, Christian K?nig >> wrote: >>> >>> Signed-off-by: Christian K?nig >> >> Bit too complex to my taste, what about attached patch, it's lot >> simpler. (Haven't

[RFC] drm/radeon: restoring ring commands in case of a lockup

On Mon, Jul 9, 2012 at 11:59 AM, Michel D?nzer wrote: > On Mon, 2012-07-09 at 12:41 +0200, Christian K?nig wrote: >> Hi, >> >> The following patchset tries to save and restore the not yet processed >> commands >> from the rings in case of a lockup and with that should make a userspace >> problem

[PATCH 15/16] drm/radeon: implement ring commit tracking

&= ring->track_mask; > + } > + seq_printf(m, "\n"); > i = (i + 1) & ring->ptr_mask; > } > return 0; > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-record-what-is-next-valid-wptr-for-each-r.patch Type: application/octet-stream Size: 7152 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120709/f0d368f6/attachment.obj>

[Bug 51870] r600_streamout=1 nothing change

https://bugs.freedesktop.org/show_bug.cgi?id=51870 --- Comment #2 from ErikAlesund 2012-07-09 11:13:09 UTC --- (In reply to comment #1) > Those environment variables aren't required anymore. GLSL 1.3 and streamout > are > enabled by default. The only thing missing is MSAA and there is no way

[PATCH 09/16] drm/radeon: make cp init on cayman more robust

On Mon, Jul 9, 2012 at 6:41 AM, Christian K?nig wrote: > It's not critical, but the current code isn't > 100% correct. > > Signed-off-by: Christian K?nig > --- > drivers/gpu/drm/radeon/ni.c | 133 > ++- > 1 file changed, 56 insertions(+), 77

[PATCH, RFC] i.MX DRM support

On Sun, Jul 08, 2012 at 08:35:55AM +0100, Dave Airlie wrote: > On Fri, Jul 6, 2012 at 11:58 PM, Greg Kroah-Hartman > wrote: > > On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote: > >> On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: > >> > Hi All, > >> > > >> > The

Mesa shader compiling/optimizing process is too slow

rk. Sounds like a fun project for someone. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120709/0b21e4c7/attachment.pgp>

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Fr?mmel changed: What|Removed |Added Attachment #75061|application/octet-stream|text/plain mime type|

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Fr?mmel changed: What|Removed |Added Attachment #75121|application/octet-stream|text/plain mime type|

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Fr?mmel changed: What|Removed |Added Attachment #75091|application/octet-stream|text/plain mime type|

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Fr?mmel changed: What|Removed |Added Attachment #75071|application/octet-stream|text/plain mime type|

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Fr?mmel changed: What|Removed |Added Attachment #75081|application/octet-stream|text/plain mime type|

[Bug 42984] scrabled video with nouveau drivers on mac mini (320m)

https://bugzilla.kernel.org/show_bug.cgi?id=42984 m.b.lankhorst at gmail.com changed: What|Removed |Added CC||m.b.lankhorst at gmail.com

question about drivers/gpu/drm/gma500/oaktrail_lvds.c

On Mon, 9 Jul 2012, Patrik Jakobsson wrote: > On Sun, Jul 8, 2012 at 10:16 PM, Alan Cox wrote: >> On Sun, 8 Jul 2012 10:39:43 +0200 (CEST) >> Julia Lawall wrote: >> >>> In the function oaktrail_lvds_mode_set, I don't think that the following >>> code makes any sense: >>> >>> /* Find

question about drivers/gpu/drm/gma500/oaktrail_lvds.c

On Sun, Jul 8, 2012 at 10:16 PM, Alan Cox wrote: > On Sun, 8 Jul 2012 10:39:43 +0200 (CEST) > Julia Lawall wrote: > >> In the function oaktrail_lvds_mode_set, I don't think that the following >> code makes any sense: >> >> /* Find the connector we're trying to set up */ >>

[PATCH 3/3] drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c: remove invalid reference to list iterator variable

From: Julia Lawall If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the list head, and not a meaningful structure. Thus this value should not be used after the end of the iterator. After

[PATCH 2/3] drivers/gpu/drm/gma500/oaktrail_crtc.c: remove invalid reference to list iterator variable

From: Julia Lawall If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the list head, and not a meaningful structure. Thus this value should not be used after the end of the iterator. A break

[PATCH 1/3] drivers/gpu/drm/gma500/mdfld_intel_display.c: remove invalid reference to list iterator variable

From: Julia Lawall If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the list head, and not a meaningful structure. Thus this value should not be used after the end of the iterator. A break

Re: question about drivers/gpu/drm/gma500/oaktrail_lvds.c

On Sun, 8 Jul 2012, Alan Cox wrote: On Sun, 8 Jul 2012 10:39:43 +0200 (CEST) Julia Lawall julia.law...@lip6.fr wrote: In the function oaktrail_lvds_mode_set, I don't think that the following code makes any sense: /* Find the connector we're trying to set up */

Re: [PATCH 4/7] drivers/gpu/drm: remove invalid reference to list iterator variable

On Sun, 8 Jul 2012, Paul Menzel wrote: Dear Julia, Am Sonntag, den 08.07.2012, 13:37 +0200 schrieb Julia Lawall: From: Julia Lawall julia.law...@lip6.fr If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the

[PATCH 2/3] drivers/gpu/drm/gma500/oaktrail_crtc.c: remove invalid reference to list iterator variable

From: Julia Lawall julia.law...@lip6.fr If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the list head, and not a meaningful structure. Thus this value should not be used after the end of the iterator. A break

[PATCH 1/3] drivers/gpu/drm/gma500/mdfld_intel_display.c: remove invalid reference to list iterator variable

From: Julia Lawall julia.law...@lip6.fr If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the list head, and not a meaningful structure. Thus this value should not be used after the end of the iterator. A break

[PATCH 3/3] drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c: remove invalid reference to list iterator variable

From: Julia Lawall julia.law...@lip6.fr If list_for_each_entry, etc complete a traversal of the list, the iterator variable ends up pointing to an address at an offset from the list head, and not a meaningful structure. Thus this value should not be used after the end of the iterator. After the

Re: question about drivers/gpu/drm/gma500/oaktrail_lvds.c

On Mon, 9 Jul 2012, Patrik Jakobsson wrote: On Sun, Jul 8, 2012 at 10:16 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Sun, 8 Jul 2012 10:39:43 +0200 (CEST) Julia Lawall julia.law...@lip6.fr wrote: In the function oaktrail_lvds_mode_set, I don't think that the following code makes any

[PATCH 0/2] fix memory deallocation and exception

this patch corrects to deallocate the pages allocated by alloc_page() and fixes exception to page allocation failure. Thanks. Inki Dae (2): drm/exynos: use __free_page() to deallocate memory drm/exynos: fixed exception to page allocation failure drivers/gpu/drm/exynos/exynos_drm_gem.c |

[PATCH 1/2] drm/exynos: use __free_page() to deallocate memory

this patch uses __free_page() to deallocate the pages allocated by alloc_page() and the pages doesn't need set_parge_dirty() and mark_page_accessed() because they aren't from page cache so removes them. this patch has a pair with previous patch below,

[PATCH 2/2] drm/exynos: fixed exception to page allocation failure

this patch corrects to deallocate the pages allocated already at alloc_page failure. Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff

[PATCH v2] drm/exynos: use __free_page() to deallocate memory

this patch uses __free_page() to deallocate the pages allocated by alloc_page() and the pages doesn't need set_parge_dirty() and mark_page_accessed() because they aren't from page cache so removes them. this patch has a pair with previous patch below,

[PATCH v3] drm/exynos: use __free_page() to deallocate memory

this patch uses __free_page() to deallocate the pages allocated by alloc_page() and the pages doesn't need set_parge_dirty() and mark_page_accessed() because they aren't from page cache so removes them. this patch has a pair with previous patch below,

[Bug 51870] r600_streamout=1 nothing change

https://bugs.freedesktop.org/show_bug.cgi?id=51870 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added AssignedTo|xorg-driver-...@lists.x.org

[Bug 42984] scrabled video with nouveau drivers on mac mini (320m)

https://bugzilla.kernel.org/show_bug.cgi?id=42984 m.b.lankho...@gmail.com m.b.lankho...@gmail.com changed: What|Removed |Added CC|

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Frömmel cfroem...@web.de changed: What|Removed |Added Attachment #75081|application/octet-stream|text/plain

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Frömmel cfroem...@web.de changed: What|Removed |Added Attachment #75071|application/octet-stream|text/plain

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Frömmel cfroem...@web.de changed: What|Removed |Added Attachment #75091|application/octet-stream|text/plain

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Frömmel cfroem...@web.de changed: What|Removed |Added Attachment #75121|application/octet-stream|text/plain

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Frömmel cfroem...@web.de changed: What|Removed |Added Attachment #75061|application/octet-stream|text/plain

Re: [PATCH, RFC] i.MX DRM support

On Sun, Jul 08, 2012 at 08:35:55AM +0100, Dave Airlie wrote: On Fri, Jul 6, 2012 at 11:58 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote: On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: Hi All, The

[PATCH 02/16] drm/radeon: add error handling to radeon_vm_unbind_locked

Waiting for a fence can fail for different reasons, the most common is a deadlock. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Michel Dänzer michel.daen...@amd.com --- drivers/gpu/drm/radeon/radeon_gart.c | 17 ++--- 1 file changed, 14 insertions(+), 3

[RFC] drm/radeon: restoring ring commands in case of a lockup

Hi, The following patchset tries to save and restore the not yet processed commands from the rings in case of a lockup and with that should make a userspace problem with a single application far less problematic. The first four patches are just stuff this patchset is based upon, followed by four

[PATCH 03/16] drm/radeon: fix fence related segfault in CS

Don't return success if scheduling the IB fails, otherwise we end up with an oops in ttm_eu_fence_buffer_objects. Signed-off-by: Christian König deathsim...@vodafone.de Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/radeon_cs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 01/16] drm/radeon: add error handling to fence_wait_empty_locked

Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Michel Dänzer michel.daen...@amd.com --- drivers/gpu/drm/radeon/radeon.h |2 +-

[PATCH 05/16] drm/radeon: fix ring commit padding

We don't need to pad anything if the number of dwords written to the ring already matches the requirements. Fixes some writting more dword to ring than expected warnings. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon_ring.c |7 +-- 1 file

[PATCH 06/16] drm/radeon: fix fence value access

It is possible that radeon_fence_process is called after writeback is disabled for suspend, leading to an invalid read of register 0x0. This fixes a problem for me where the fence value is temporary incremented by 0x1 on suspend/resume. Signed-off-by: Christian König

[PATCH 07/16] drm/radeon: fix fence init after resume

Start with last signaled fence number instead of last emitted one. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon_fence.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_fence.c

[PATCH 09/16] drm/radeon: make cp init on cayman more robust

It's not critical, but the current code isn't 100% correct. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/ni.c | 133 ++- 1 file changed, 56 insertions(+), 77 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c

[PATCH 08/16] drm/radeon: remove FIXME comment from chipset suspend

For a normal suspend/resume we allready wait for the rings to be empty, and for a suspend/reasume in case of a lockup we REALLY don't want to wait for anything. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c |1 - drivers/gpu/drm/radeon/ni.c

[PATCH 10/16] drm/radeon: remove ip_pool start/suspend

The IB pool is in gart memory, so it is completely superfluous to unpin / repin it on suspend / resume. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c | 17 ++--- drivers/gpu/drm/radeon/ni.c | 16 ++--

[PATCH 11/16] drm/radeon: remove r600_blit_suspend

Just reinitialize the shader content on resume instead. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c |1 - drivers/gpu/drm/radeon/evergreen_blit_kms.c | 40 +-- drivers/gpu/drm/radeon/ni.c |

[PATCH 04/16] drm/radeon: add an exclusive lock for GPU reset v2

From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

[PATCH 13/16] drm/radeon: move radeon_ib_ring_tests out of chipset code

Making it easier to controlwhen it is executed. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/ni.c|4 drivers/gpu/drm/radeon/r100.c |4 drivers/gpu/drm/radeon/r300.c

[PATCH 12/16] drm/radeon: remove vm_manager start/suspend

Just restore the page table instead. Addressing three problem with this change: 1. Calling vm_manager_suspend in the suspend path is problematic cause it wants to wait for the VM use to end, which in case of a lockup never happens. 2. In case of a locked up memory controller unbinding

[PATCH 14/16] drm/radeon: make align a ring_init parameter

Instead of setting it directly from the chipset code. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c |3 ++- drivers/gpu/drm/radeon/ni.c |3 ++- drivers/gpu/drm/radeon/r100.c|3 +-- drivers/gpu/drm/radeon/r600.c

[PATCH 15/16] drm/radeon: implement ring commit tracking

Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon.h |3 +++ drivers/gpu/drm/radeon/radeon_ring.c | 39 -- 2 files changed, 40 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h

[PATCH 16/16] drm/radeon: implement ring saving on reset

Try to save whatever is on the rings when we encounter an lockup. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon.h|4 ++ drivers/gpu/drm/radeon/radeon_device.c | 44 drivers/gpu/drm/radeon/radeon_ring.c | 69

[Bug 51870] r600_streamout=1 nothing change

https://bugs.freedesktop.org/show_bug.cgi?id=51870 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 51870] r600_streamout=1 nothing change

https://bugs.freedesktop.org/show_bug.cgi?id=51870 --- Comment #2 from ErikAlesund fallosist...@gmail.com 2012-07-09 11:13:09 UTC --- (In reply to comment #1) Those environment variables aren't required anymore. GLSL 1.3 and streamout are enabled by default. The only thing missing is MSAA

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 --- Comment #30 from stefan fdo.12.ben...@xoxy.net 2012-07-09 11:18:52 PDT --- Hi Daniel, (In reply to comment #29) (In reply to comment #28) are there any news on this issue? The 3.4 and 3.5-rc series seem stable wrt this issue, but

Re: 3.5-rc5: radeon acceleration regression on Transmeta system

In 3.4, radeon worked with a glitch - window titles were see-throug (not drawn). In 3.5-rc5, radeon driver seems to be more careful and disables acceleration on this system at all. Full dmesg below. Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32? That was a

[Bug 33309] [855GM] GPU freeze due to overlay hang

https://bugs.freedesktop.org/show_bug.cgi?id=33309 Chris Wilson ch...@chris-wilson.co.uk changed: What|Removed |Added Status|NEEDINFO|RESOLVED

  1   2   >