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

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

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

The TTM DMA only gets turned on when the SWIOTLB is enabled - but we might also want to turn it off when SWIOTLB is on to use the non-DMA TTM pool code. In the future this parameter can be removed. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4

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

In TTM world the pages for the graphic drivers are kept in three different pools: write combined, uncached, and cached (write-back). When the pages are used by the graphic driver the graphic adapter via its built in MMU (or AGP) programs these pages in. The programming requires the virtual address

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

As a mechanism to detect whether SWIOTLB is enabled or not. And as such, we might as well wrap it within an 'swiotlb_enabled()' function that will call the swiotlb_nr_tlb. We also fix the spelling - it was swioltb instead of swiotlb. CC: FUJITA Tomonori Signed-off-by: Konrad Rzeszutek Wilk ---

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

We want to pass in the 'struct device' to the TTM layer so that the TTM DMA pool code (if enabled) can use it. The DMA API code needs the 'struct device' to do the DMA API operations. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-

[PATCH 2/7] ttm: Introduce ttm_page_alloc_func structure.

Which has the function members for all of the current page pool operations defined. The old calls (ttm_put_pages, ttm_get_pages, etc) are plumbed through little functions which lookup in the ttm_page_alloc_func the appropiate implementation and call it. There is currently only one page pool code

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

. instead of checking against the DMA_ERROR_CODE value which is per-platform specific. The zero value is a known invalid value that the TTM layer sets on the dma_address array if it is not used (ttm_tt_alloc_page_directory calls drm_calloc_large which creates a page with GFP_ZERO). We can't use

[PATCH] TTM DMA pool v1.7

Since v1: [http://lwn.net/Articles/456246/] - Ran it through the gauntlet of SubmitChecklist and fixed issues - Made radeon/nouveau driver set coherent_dma (which is required for dmapool) [.. and this is what I said in v1 post]: Way back in January this patchset:

[PATCH] drm: Fix the number of connector and encoder to cleanup functions

this seems like a better fix than decrementing the count in individual drivers, but would like to hear what some 'old timers' think ;-) BR, -R On Fri, Aug 26, 2011 at 9:06 PM, Joonyoung Shim wrote: > It is left out the code to decrease the number of connector and encoder > to the cleanup

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

> > + ? ? ? entry->vaddr = dma_alloc_writecombine(dev->dev, entry->size, > > + ? ? ? ? ? ? ? ? ? ? ? (dma_addr_t *)>paddr, GFP_KERNEL); > > + ? ? ? if (!entry->paddr) { > > + ? ? ? ? ? ? ? DRM_ERROR("failed to allocate buffer.\n"); > > + ? ? ? ? ? ? ? return -ENOMEM; > > + ? ? ? } > > + > > + ? ?

Review request to DRM Driver for Samsung SoC Exynos4210.

Hello Dave. > -Original Message- > From: Dave Airlie [mailto:airlied at gmail.com] > Sent: Tuesday, August 30, 2011 6:46 PM > To: Inki Dae > Cc: airlied at linux.ie; kyungmin.park at samsung.com; dri- > devel at lists.freedesktop.org; jy0922.shim at samsung.com; > sw0312.kim at

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

Hi Inki, Sorry for slightly overdue review.. it took a little while to go through the whole thing comments in-line below On Fri, Aug 26, 2011 at 6:47 AM, Inki Dae wrote: > This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables only > FIMD yet > but we will add HDMI support

[Bug 42112] radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 mrsteven at gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[PATCH] drm/radeon/kms: set a default max_pixel_clock

From: Dave Airlie On some Power rv100 cards, we have no ATY OF table, but we have no combios table either, and hence we refuse all modes on VGA-0 since we end up with a 0 max pixel clock. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_clocks.c |3 +++ 1

[Bug 42112] radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 --- Comment #3 from mrsteven at gmx.de 2011-08-30 20:11:29 --- Hmm, my internet connection is quite slow, but I hope it will work if I clone the stable tree with a line like this: git clone --depth=100

[Bug 42112] radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment

[Bug 42112] radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 --- Comment #1 from mrsteven at gmx.de 2011-08-30 19:15:13 --- Created an attachment (id=70932) --> (https://bugzilla.kernel.org/attachment.cgi?id=70932) Kernel log of me playing around with the external monitor I was trying to set the

[Bug 42112] New: radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 Summary: radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip Product: Drivers Version: 2.5 Kernel Version: 3.0.4 Platform: All

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #4 from Jean-Fran?ois Fortin Tam 2011-08-30 18:49:27 PDT --- Created an attachment (id=50738) --> (https://bugs.freedesktop.org/attachment.cgi?id=50738) glxinfo As requested. -- Configure bugmail:

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #3 from Jean-Fran?ois Fortin Tam 2011-08-30 18:48:54 PDT --- Created an attachment (id=50737) --> (https://bugs.freedesktop.org/attachment.cgi?id=50737) dmesg -- Configure bugmail:

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #2 from Jean-Fran?ois Fortin Tam 2011-08-30 18:48:39 PDT --- Created an attachment (id=50736) --> (https://bugs.freedesktop.org/attachment.cgi?id=50736) Xorg log -- Configure bugmail:

[PATCH v3] drm/radeon: Print gart initialization details on all chipsets

From: Tormod Volden This was previously done for r300 only. Use %016lX instead of %08X for printing the table address. Also fix typos in gart warning messages. Signed-off-by: Tormod Volden --- drivers/gpu/drm/radeon/evergreen.c |2 ++

[Bug 36072] celestia causes kernel oops when allocation a lot of memory (for textures)

https://bugzilla.kernel.org/show_bug.cgi?id=36072 --- Comment #2 from aceman 2011-08-30 18:15:47 --- This is getting worse. With kernel 3.0.3, mesa 7.11 I get the crash several seconds after starting celestia each time. Aug 30 00:01:03 coolbox kernel: [drm:radeon_cs_ioctl] *ERROR* Failed

Review request to DRM Driver for Samsung SoC Exynos4210.

On Tue, Aug 30, 2011 at 7:38 AM, Inki Dae wrote: > >> > Basically gem_dumb_* and gem_* are same operation. The difference >> between >> > them is that gem_dumb_ needs framebuffer information such width, height >> and >> > bpp to allocate buffer and gem_ needs only size. in case of gem_dumb_, >>

[PATCH] drm/radeon/kms: set a default max_pixel_clock

On Tue, Aug 30, 2011 at 3:23 PM, Dave Airlie wrote: > From: Dave Airlie > > On some Power rv100 cards, we have no ATY OF table, but we have > no combios table either, and hence we refuse all modes on VGA-0 > since we end up with a 0 max pixel clock. > > Signed-off-by: Dave Airlie Reviewed-by:

[PATCH] drm/radeon/kms: set a default max_pixel_clock

On Tue, Aug 30, 2011 at 3:23 PM, Dave Airlie wrote: > From: Dave Airlie > > On some Power rv100 cards, we have no ATY OF table, but we have > no combios table either, and hence we refuse all modes on VGA-0 > since we end up with a 0 max pixel clock. > > Signed-off-by: Dave Airlie Reviewed-by:

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 Benoit Jacob changed: What|Removed |Added Attachment #50707|0 |1 is obsolete|

[Bug 36934] screen corruption after running a game

https://bugs.freedesktop.org/show_bug.cgi?id=36934 --- Comment #9 from almos 2011-08-30 14:51:08 PDT --- Created an attachment (id=50722) --> (https://bugs.freedesktop.org/attachment.cgi?id=50722) corrupted image in firefox Now I found a good example of this corruption. When Firefox displays a

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #12 from Benoit Jacob 2011-08-30 14:36:51 PDT --- (In reply to comment #11) > > --- Comment #9 from Benoit Jacob 2011-08-30 > > 14:00:11 PDT --- > > The original version used an uninitialized value for the file descriptor it > >

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #11 from Julien Cristau 2011-08-30 14:33:54 PDT --- > --- Comment #9 from Benoit Jacob 2011-08-30 14:00:11 > PDT --- > The original version used an uninitialized value for the file descriptor it > was > writing to. This version

Review request to DRM Driver for Samsung SoC Exynos4210.

Hello Dave. Thank you for your comments. Below is my answers and questions. > -Original Message- > From: Dave Airlie [mailto:airlied at gmail.com] > Sent: Monday, August 29, 2011 11:27 PM > To: Inki Dae > Cc: airlied at linux.ie; kyungmin.park at samsung.com; dri- > devel at

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #10 from Benoit Jacob 2011-08-30 14:12:23 PDT --- (In reply to comment #9) > Created an attachment (id=50707) --> (https://bugs.freedesktop.org/attachment.cgi?id=50707) > Stand-alone version of Mozilla's glxtext, v2 > > The

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 Benoit Jacob changed: What|Removed |Added Attachment #50665|0 |1 is obsolete|

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #8 from Benoit Jacob 2011-08-30 13:56:59 PDT --- (In reply to comment #6) > Looks like this crash report came from me. With Nightly from today and Mesa > 7.12-devel (git-110f846) I still get "GLXtest process failed (received signal

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #7 from Benoit Jacob 2011-08-30 13:55:01 PDT --- Hi Jure :-) Thanks Ian and Michel, will use glXGetProcAddress. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail

Kernel almost hangs when CONFIG_DRM_RADEON=y

On Tue, 30 Aug 2011, Peter Zijlstra wrote: > On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > > So, hypothetically speaking, hpa suggested then that we could pass > > > firmware blobs over the linked list setup_data thing in

Kernel almost hangs when CONFIG_DRM_RADEON=y

On Tue, 30 Aug 2011, Borislav Petkov wrote: > On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > > So, hypothetically speaking, hpa suggested then that we could pass > > > firmware blobs over the linked list setup_data

[PATCH v2] drm/radeon: Print gart initialization details on all chipsets

2011/8/30 Michel D?nzer : >> This was previously done for r300 only. Use %p instead of %08X for >> printing the table address. > > sizeof(dma_addr_t) can be 8 even when sizeof(void*) is 4. Thanks, I will send a new patch, using "0x%016lX". Will that work for everybody? > While you're at it,

[git pull] drm fixes

Hi Linus, two radeon fixes, one core fix, all pretty trivial. Dave. The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at:

Review request to DRM Driver for Samsung SoC Exynos4210.

>> 2. I'm not sure why samsung_drm_fn_encoder exists, it looks like from >> the crtc mode set functions you call the encoder mode set functions, >> is it not possible to use the helper drm_crtc_helper_set_mode so that >> the crtc mode set is called then the encoder ones without having the >>

Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > So, hypothetically speaking, hpa suggested then that we could pass > > firmware blobs over the linked list setup_data thing in the real-mode > > kernel header and

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #1 from Michel D?nzer 2011-08-30 10:36:17 PDT --- Reminds me of bug 39714. Please attach the full Xorg.0.log and the output of dmesg and glxinfo. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ---

[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip

https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #21 from Anisse Astier 2011-08-30 10:12:34 --- I tried the patch from comment 12 on top of linus' tree (HEAD: 0f43dd546d991ca260d8a72d07f). I tried without the patch. Unfortunately, there was no change, and screen is still

[PATCH v2] drm/radeon: Print gart initialization details on all chipsets

DRM patches need to be submitted to the dri-devel list, moving there. On Die, 2011-08-30 at 00:17 +0200, Tormod Volden wrote: > From: Tormod Volden > > This was previously done for r300 only. Use %p instead of %08X for > printing the table address. sizeof(dma_addr_t) can be 8 even when

[Bug 40495] New: r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 Summary: r300 performance is slower on sleep resume Product: Mesa Version: 7.11 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority:

Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > So, hypothetically speaking, hpa suggested then that we could pass > > firmware blobs over the linked list setup_data thing in the real-mode > > kernel header and

Review request to DRM Driver for Samsung SoC Exynos4210.

CC Eric (freescale), Rob (TI) who working the DRM with other ARM SoCs. As Dave mentioned, Please review Samsung DRM codes. Thank you, Kyungmin Park -Original Message- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Monday, August 29, 2011 11:27 PM To: Inki Dae Cc: airlied at

[Bug 34929] [r300g] slowdown with r300g threading

https://bugs.freedesktop.org/show_bug.cgi?id=34929 Fabio Pedretti changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #11 from Fabio

[Bug 34218] [r300g] Unigine Sanctuary: some surfaces are reflecting too much light

https://bugs.freedesktop.org/show_bug.cgi?id=34218 --- Comment #9 from Henri Verbeet 2011-08-30 05:58:18 PDT --- (In reply to comment #8) > around this and llvmpipe is not affected at all. CCing Henri, maybe he can > bring some light about what his change did to uncover this bug in r300g >

[Bug 40443] gbm.h not included when it should be.

https://bugs.freedesktop.org/show_bug.cgi?id=40443 --- Comment #2 from Rovanion Luckey 2011-08-30 02:37:48 PDT --- Pulled mesa git today after stashing my local changes. It now compiles as it should. Great response time from you the developer, thanks! -- Configure bugmail:

[Bug 40476] No HDMI audio though ATi Radeon HD5730/1GB-VRAM card.

https://bugs.freedesktop.org/show_bug.cgi?id=40476 Michel D?nzer changed: What|Removed |Added Product|xorg|DRI Version|git

[Bug 40128] GPU lockup (waiting for 0x0002F05C last fence id 0x0002F05A), oops in radeon_ring_write, and screen turns off

https://bugs.freedesktop.org/show_bug.cgi?id=40128 --- Comment #6 from Michel D?nzer 2011-08-30 02:17:54 PDT --- (In reply to comment #4) > But it seems like this is happening only in amd64 builds. After being unable > to > find a solution for the problem I installed Debian stable x86, and the

Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, Aug 29, 2011 at 08:16:53PM +0200, Peter Zijlstra wrote: > On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote: > > > That would suck, suppose this radeon thing is the only console you've > > > got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come > > > up? > > > >

Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, 29 Aug 2011, Borislav Petkov wrote: > So, hypothetically speaking, hpa suggested then that we could pass > firmware blobs over the linked list setup_data thing in the real-mode > kernel header and parse_setup_data() can look at them and map them > somewhere later for the driver to find.

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and

Re: [PATCH v2] drm/radeon: Print gart initialization details on all chipsets

DRM patches need to be submitted to the dri-devel list, moving there. On Die, 2011-08-30 at 00:17 +0200, Tormod Volden wrote: From: Tormod Volden debian.tor...@gmail.com This was previously done for r300 only. Use %p instead of %08X for printing the table address. sizeof(dma_addr_t) can

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can

Re: [PATCH v2] drm/radeon: Print gart initialization details on all chipsets

2011/8/30 Michel Dänzer mic...@daenzer.net: This was previously done for r300 only. Use %p instead of %08X for printing the table address. sizeof(dma_addr_t) can be 8 even when sizeof(void*) is 4. Thanks, I will send a new patch, using 0x%016lX. Will that work for everybody? While you're at

[Bug 40128] GPU lockup (waiting for 0x0002F05C last fence id 0x0002F05A), oops in radeon_ring_write, and screen turns off

https://bugs.freedesktop.org/show_bug.cgi?id=40128 --- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-08-30 02:17:54 PDT --- (In reply to comment #4) But it seems like this is happening only in amd64 builds. After being unable to find a solution for the problem I installed Debian

[Bug 40476] No HDMI audio though ATi Radeon HD5730/1GB-VRAM card.

https://bugs.freedesktop.org/show_bug.cgi?id=40476 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Product|xorg|DRI

[Bug 40443] gbm.h not included when it should be.

https://bugs.freedesktop.org/show_bug.cgi?id=40443 --- Comment #2 from Rovanion Luckey rovanion.luc...@gmail.com 2011-08-30 02:37:48 PDT --- Pulled mesa git today after stashing my local changes. It now compiles as it should. Great response time from you the developer, thanks! -- Configure

Re: Review request to DRM Driver for Samsung SoC Exynos4210.

2. I'm not sure why samsung_drm_fn_encoder exists, it looks like from the crtc mode set functions you call the encoder mode set functions, is it not possible to use the helper drm_crtc_helper_set_mode so that the crtc mode set is called then the encoder ones without having the explicit calls?

[git pull] drm fixes

Hi Linus, two radeon fixes, one core fix, all pretty trivial. Dave. The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at:

[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip

https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #21 from Anisse Astier ani...@astier.eu 2011-08-30 10:12:34 --- I tried the patch from comment 12 on top of linus' tree (HEAD: 0f43dd546d991ca260d8a72d07f). I tried without the patch. Unfortunately, there was no change, and screen

RE: Review request to DRM Driver for Samsung SoC Exynos4210.

Hello Dave. -Original Message- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Tuesday, August 30, 2011 6:46 PM To: Inki Dae Cc: airl...@linux.ie; kyungmin.p...@samsung.com; dri- de...@lists.freedesktop.org; jy0922.s...@samsung.com; sw0312@samsung.com; eric.y.m...@gmail.com;

[Bug 34218] [r300g] Unigine Sanctuary: some surfaces are reflecting too much light

https://bugs.freedesktop.org/show_bug.cgi?id=34218 --- Comment #9 from Henri Verbeet hverb...@gmail.com 2011-08-30 05:58:18 PDT --- (In reply to comment #8) around this and llvmpipe is not affected at all. CCing Henri, maybe he can bring some light about what his change did to uncover this bug

[Bug 34929] [r300g] slowdown with r300g threading

https://bugs.freedesktop.org/show_bug.cgi?id=34929 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment

[Bug 40495] New: r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 Summary: r300 performance is slower on sleep resume Product: Mesa Version: 7.11 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority:

[PATCH v3] drm/radeon: Print gart initialization details on all chipsets

From: Tormod Volden debian.tor...@gmail.com This was previously done for r300 only. Use %016lX instead of %08X for printing the table address. Also fix typos in gart warning messages. Signed-off-by: Tormod Volden debian.tor...@gmail.com --- drivers/gpu/drm/radeon/evergreen.c |2 ++

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-08-30 10:36:17 PDT --- Reminds me of bug 39714. Please attach the full Xorg.0.log and the output of dmesg and glxinfo. -- Configure bugmail:

[Bug 36072] celestia causes kernel oops when allocation a lot of memory (for textures)

https://bugzilla.kernel.org/show_bug.cgi?id=36072 --- Comment #2 from aceman aceli...@atlas.sk 2011-08-30 18:15:47 --- This is getting worse. With kernel 3.0.3, mesa 7.11 I get the crash several seconds after starting celestia each time. Aug 30 00:01:03 coolbox kernel: [drm:radeon_cs_ioctl]

[Bug 42112] New: radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 Summary: radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip Product: Drivers Version: 2.5 Kernel Version: 3.0.4 Platform: All

[Bug 42112] radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 --- Comment #1 from mrste...@gmx.de 2011-08-30 19:15:13 --- Created an attachment (id=70932) -- (https://bugzilla.kernel.org/attachment.cgi?id=70932) Kernel log of me playing around with the external monitor I was trying to set the external

[PATCH] drm/radeon/kms: set a default max_pixel_clock

From: Dave Airlie airl...@redhat.com On some Power rv100 cards, we have no ATY OF table, but we have no combios table either, and hence we refuse all modes on VGA-0 since we end up with a 0 max pixel clock. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/radeon_clocks.c

Re: [PATCH] drm/radeon/kms: set a default max_pixel_clock

On Tue, Aug 30, 2011 at 3:23 PM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com On some Power rv100 cards, we have no ATY OF table, but we have no combios table either, and hence we refuse all modes on VGA-0 since we end up with a 0 max pixel clock. Signed-off-by:

[Bug 42112] radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 --- Comment #3 from mrste...@gmx.de 2011-08-30 20:11:29 --- Hmm, my internet connection is quite slow, but I hope it will work if I clone the stable tree with a line like this: git clone --depth=100

[Bug 42112] radeon driver (kms) fails to read EDID data from external LCD monitor with kernel 3.0.4 on a RV350 chip

https://bugzilla.kernel.org/show_bug.cgi?id=42112 mrste...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #7 from Benoit Jacob bja...@mozilla.com 2011-08-30 13:55:01 PDT --- Hi Jure :-) Thanks Ian and Michel, will use glXGetProcAddress. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #8 from Benoit Jacob bja...@mozilla.com 2011-08-30 13:56:59 PDT --- (In reply to comment #6) Looks like this crash report came from me. With Nightly from today and Mesa 7.12-devel (git-110f846) I still get GLXtest process failed

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 Benoit Jacob bja...@mozilla.com changed: What|Removed |Added Attachment #50665|0 |1 is obsolete|

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #10 from Benoit Jacob bja...@mozilla.com 2011-08-30 14:12:23 PDT --- (In reply to comment #9) Created an attachment (id=50707) -- (https://bugs.freedesktop.org/attachment.cgi?id=50707) Stand-alone version of Mozilla's glxtext, v2

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #11 from Julien Cristau jcris...@debian.org 2011-08-30 14:33:54 PDT --- --- Comment #9 from Benoit Jacob bja...@mozilla.com 2011-08-30 14:00:11 PDT --- The original version used an uninitialized value for the file descriptor it

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #12 from Benoit Jacob bja...@mozilla.com 2011-08-30 14:36:51 PDT --- (In reply to comment #11) --- Comment #9 from Benoit Jacob bja...@mozilla.com 2011-08-30 14:00:11 PDT --- The original version used an uninitialized value

[Bug 36934] screen corruption after running a game

https://bugs.freedesktop.org/show_bug.cgi?id=36934 --- Comment #9 from almos aaalmo...@gmail.com 2011-08-30 14:51:08 PDT --- Created an attachment (id=50722) -- (https://bugs.freedesktop.org/attachment.cgi?id=50722) corrupted image in firefox Now I found a good example of this corruption. When

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 Benoit Jacob bja...@mozilla.com changed: What|Removed |Added Attachment #50707|0 |1 is obsolete|

Re: Review request to DRM Driver for Samsung SoC Exynos4210.

On Tue, Aug 30, 2011 at 7:38 AM, Inki Dae inki@samsung.com wrote: Basically gem_dumb_* and gem_* are same operation. The difference between them is that gem_dumb_ needs framebuffer information such width, height and bpp to allocate buffer and gem_ needs only size. in case of

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

On Tue, 30 Aug 2011, Borislav Petkov wrote: On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

On Tue, 30 Aug 2011, Peter Zijlstra wrote: On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #2 from Jean-François Fortin Tam nekoh...@gmail.com 2011-08-30 18:48:39 PDT --- Created an attachment (id=50736) -- (https://bugs.freedesktop.org/attachment.cgi?id=50736) Xorg log -- Configure bugmail:

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #3 from Jean-François Fortin Tam nekoh...@gmail.com 2011-08-30 18:48:54 PDT --- Created an attachment (id=50737) -- (https://bugs.freedesktop.org/attachment.cgi?id=50737) dmesg -- Configure bugmail:

[Bug 40495] r300 performance is slower on sleep resume

https://bugs.freedesktop.org/show_bug.cgi?id=40495 --- Comment #4 from Jean-François Fortin Tam nekoh...@gmail.com 2011-08-30 18:49:27 PDT --- Created an attachment (id=50738) -- (https://bugs.freedesktop.org/attachment.cgi?id=50738) glxinfo As requested. -- Configure bugmail:

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

Hi Inki, Sorry for slightly overdue review.. it took a little while to go through the whole thing comments in-line below On Fri, Aug 26, 2011 at 6:47 AM, Inki Dae inki@samsung.com wrote: This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables only FIMD yet but we will add

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

+       entry-vaddr = dma_alloc_writecombine(dev-dev, entry-size, +                       (dma_addr_t *)entry-paddr, GFP_KERNEL); +       if (!entry-paddr) { +               DRM_ERROR(failed to allocate buffer.\n); +               return -ENOMEM; +       } + +      

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

+static void samsung_drm_connector_destroy(struct drm_connector *connector) +{ + struct samsung_drm_connector *samsung_connector = + to_samsung_connector(connector); + + DRM_DEBUG_KMS(%s\n, __FILE__); + + drm_sysfs_connector_remove(connector); +

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

. instead of checking against the DMA_ERROR_CODE value which is per-platform specific. The zero value is a known invalid value that the TTM layer sets on the dma_address array if it is not used (ttm_tt_alloc_page_directory calls drm_calloc_large which creates a page with GFP_ZERO). We can't use

[PATCH] TTM DMA pool v1.7

Since v1: [http://lwn.net/Articles/456246/] - Ran it through the gauntlet of SubmitChecklist and fixed issues - Made radeon/nouveau driver set coherent_dma (which is required for dmapool) [.. and this is what I said in v1 post]: Way back in January this patchset:

[PATCH 2/7] ttm: Introduce ttm_page_alloc_func structure.

Which has the function members for all of the current page pool operations defined. The old calls (ttm_put_pages, ttm_get_pages, etc) are plumbed through little functions which lookup in the ttm_page_alloc_func the appropiate implementation and call it. There is currently only one page pool code

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

We want to pass in the 'struct device' to the TTM layer so that the TTM DMA pool code (if enabled) can use it. The DMA API code needs the 'struct device' to do the DMA API operations. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-

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

As a mechanism to detect whether SWIOTLB is enabled or not. And as such, we might as well wrap it within an 'swiotlb_enabled()' function that will call the swiotlb_nr_tlb. We also fix the spelling - it was swioltb instead of swiotlb. CC: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp

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

The TTM DMA only gets turned on when the SWIOTLB is enabled - but we might also want to turn it off when SWIOTLB is on to use the non-DMA TTM pool code. In the future this parameter can be removed. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com ---

  1   2   >