[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

On Thu, 2011-06-09 at 09:21 +0100, Alan Cox wrote: > On Thu, 09 Jun 2011 14:05:59 +1000 > Dave Airlie wrote: > > > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: > > > To properly support the various plane formats supported by different > > > hardware, the kernel must know the pixel

[PATCH 14/15] gma500: nuke the PSB debug stuff

On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: > On Thu, 9 Jun 2011 03:10:03 +0200 > Patrik Jakobsson wrote: > > > Hi Alan > > > > Just a thought. Shouldn't we use the DRM macros for printing debug info? > > Linux has perfectly good printing functions and using them means we can > use

[Bug 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)

https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #2 from Alexandre Demers 2011-06-09 19:58:59 PDT --- Since it only happens when I use Diablo 2 with Glide, it is probably related to the Glide to OpenGL wrapper. If indeed the extension is not supported in r600g, then it is related

[PATCH 0/3] alpha, drm: Update Alpha DRM support

On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote: > > This patch set fixes Alpha-specific support in the DRM code, > allowing Radeon KMS and the MGA driver to work properly on > Alpha-based machines. > > Jay > > Jay Estabrook (3): > ?alpha, drm: Update Alpha DRM support > ?alpha, drm: Cleanup

[PATCH 3/3] alpha, drm: Add Alpha support to Radeon DRM code

Alpha needs to have the system bus address for the device's local memory available, so that it can be returned to user-level, where it may be used in an mmap(). So, we make bus.addr hold the ioremap() return for kernel use, and then we can modify bus.base appropriately. Signed-off-by: Jay

[PATCH 2/3] alpha, drm: Remove obsolete Alpha support in MGA DRM code

Remove an obsolete Alpha adjustment in the drm for MGA on Alpha. Signed-off-by: Jay Estabrook --- drivers/gpu/drm/mga/mga_drv.h | 19 --- 1 file changed, 19 deletions(-) diff -Naurp a/drivers/gpu/drm/mga/mga_drv.h b/drivers/gpu/drm/mga/mga_drv.h ---

[PATCH 1/3] alpha, drm: Cleanup Alpha support in DRM generic code

Remove an obsolete Alpha adjustment, and modify another, to go with the current Alpha architecture support. Signed-off-by: Jay Estabrook --- drivers/gpu/drm/drm_bufs.c|3 --- drivers/gpu/drm/drm_vm.c |2 +- 2 files changed, 1 insertion(+), 4 deletions(-) diff -Naurp

[PATCH 0/3] alpha, drm: Update Alpha DRM support

This patch set fixes Alpha-specific support in the DRM code, allowing Radeon KMS and the MGA driver to work properly on Alpha-based machines. Jay Jay Estabrook (3): alpha, drm: Update Alpha DRM support alpha, drm: Cleanup Alpha support in DRM generic code alpha, drm: Remove obsolete Alpha

Radeon drm: Hang with posting GPU when PCI card is primary

> [ 10.169900] [drm] radeon kernel modesetting enabled. > [ 10.170270] radeon :02:00.0: enabling device (0080 -> 0083) > [ 10.170816] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 > [ 10.171044] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, > low) -> IRQ 11 > [

Modeline problem with Radeon KMS

> > So it decides this modeline is usable for the console while it is not. > > Ah, ok. yeah, that mode has a much higher clock than those chips can > handle. Where is that mode even coming from? I don't see it in the > EDID. The attached patch should filter out that mode. It works, thank

[PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl

On Fri, 2011-06-03 at 12:54 +0200, Sascha Hauer wrote: > The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers. > That is because the framebuffers for each file are in the filp_head > member of struct drm_framebuffer, not in the head member. > > Signed-off-by: Sascha Hauer > ---

[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: > To properly support the various plane formats supported by different > hardware, the kernel must know the pixel format of a framebuffer object. > So add a new ioctl taking a format argument corresponding to a fourcc > name from videodev2.h.

[PATCH 14/15] gma500: nuke the PSB debug stuff

On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote: > On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: >> On Thu, 9 Jun 2011 03:10:03 +0200 >> Patrik Jakobsson wrote: >> >> > Hi Alan >> > >> > Just a thought. Shouldn't we use the DRM macros for printing debug info? >> >> Linux has perfectly good

[PATCH 14/15] gma500: nuke the PSB debug stuff

> Yes, my concern was about drm.debug and use of all the DRM portability stuff > (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...) > > The portability might not be important at this point but I just wanted to > raise > the question so I know what is right / wrong. The gma500 driver

[PATCH 14/15] gma500: nuke the PSB debug stuff

> Though if psb wants to be different to other drm drivers it can lead the > way, though it'll be a total nightmare for all the people who follow > documentation on how to debug drm drivers using drm.debug=1,2,4,8. for > various code paths. Actually it seems to work out nicely because you can

[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

> > You also don't need a headwer with a complete list of fourcc names in it, > > that is the half the point of FourCC. > > #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8 > RGB-3-3-2 */ > > See that V4L2 and v4l2? I'd rather not have them used in the drm They are just

[PATCH 1/4] drm: add plane support

On 06/08/2011 08:54 PM, Jesse Barnes wrote: > On Wed, 8 Jun 2011 11:41:17 +0200 > Marcus Lorentzon wrote: > > >> On 06/07/2011 11:01 PM, Jesse Barnes wrote: >> >>> On Tue, 7 Jun 2011 13:07:39 -0700 >>> Jesse Barnes wrote: >>> >>> >>> +/* Planes blend with or override

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #10 from Harald Judt 2011-06-09 10:36:13 PDT --- Bug 27523 seems similar, but not identical to this one. https://bugs.freedesktop.org/show_bug.cgi?id=27523 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[PATCH] drm/gem: add hooks to notify driver when object handle is created/destroyed

On Thu, 2011-06-09 at 10:24 +1000, skeggsb at gmail.com wrote: > From: Ben Skeggs > > Nouveau is going to use these hooks to map/unmap objects from a client's > private GPU address space. Forgot the v2 notes.. inlined below.. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/drm_gem.c |

[PATCH] drm/gem: add hooks to notify driver when object handle is created/destroyed

From: Ben Skeggs Nouveau is going to use these hooks to map/unmap objects from a client's private GPU address space. Signed-off-by: Ben Skeggs --- drivers/gpu/drm/drm_gem.c | 21 +++-- include/drm/drmP.h|2 ++ 2 files changed, 21

[Bug 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)

https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #1 from Ian Romanick 2011-06-09 10:18:17 PDT --- That enum is GL_FRAGMENT_SHADER_ATI. If that driver doesn't support GL_ATI_fragment_shader, and I believe that only the r200 driver does, this is an application bug. I'll leave it

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #9 from Harald Judt 2011-06-09 10:13:49 PDT --- > However, it's a bit better now, as it did not happen during normal > desktop usage (till now). I spoke too soon. Problem is still there :-( -- Configure bugmail:

[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

On Thu, 09 Jun 2011 14:05:59 +1000 Dave Airlie wrote: > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: > > To properly support the various plane formats supported by different > > hardware, the kernel must know the pixel format of a framebuffer object. > > So add a new ioctl taking a

[PATCH 14/15] gma500: nuke the PSB debug stuff

On Thu, 9 Jun 2011 03:10:03 +0200 Patrik Jakobsson wrote: > Hi Alan > > Just a thought. Shouldn't we use the DRM macros for printing debug info? Linux has perfectly good printing functions and using them means we can use dev_dbg() which supports things like nice runtime switching.

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #8 from almos 2011-06-09 07:59:43 PDT --- (In reply to comment #6) > > I don't consider Hyper-Z ready yet but thanks for testing it. > > It is enabled by default now, is it by accident? Perhaps you mean that it always reports this?

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #7 from Marek Ol??k 2011-06-09 07:21:05 PDT --- (In reply to comment #6) > > I don't consider Hyper-Z ready yet but thanks for testing it. > > It is enabled by default now, is it by accident? It's disabled. There are some annoying

[Bug 37168] Regression: Kernel hard-lock when running Second Life

https://bugs.freedesktop.org/show_bug.cgi?id=37168 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #5 from Sven

[Bug 37032] DRM_RADEON=m with CONFIG_FB=y fails

https://bugzilla.kernel.org/show_bug.cgi?id=37032 Andrew Morton changed: What|Removed |Added CC||akpm at linux-foundation.org

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #6 from Fabio Pedretti 2011-06-09 04:37:34 PDT --- > I don't consider Hyper-Z ready yet but thanks for testing it. It is enabled by default now, is it by accident? -- Configure bugmail:

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #17 from Henri Verbeet 2011-06-09 04:30:29 PDT --- I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to Wine first for that to work. -- Configure bugmail:

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #16 from Henri Verbeet 2011-06-09 04:27:59 PDT --- (In reply to comment #15) > Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? > > So using something like

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #15 from Sven Arvidsson 2011-06-09 04:02:32 PDT --- Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod" would cause it to fall back to

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #14 from Henri Verbeet 2011-06-09 03:57:31 PDT --- (In reply to comment #10) > Is there a way to disable the shader model 3.0 in Wine/DX9? Not at the moment, but I'm considering adding a registry key to limit the maximum exposed

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #13 from Marek Ol??k 2011-06-09 03:38:24 PDT --- (In reply to comment #12) > (In reply to comment #10) > > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 > > error messages seem to be unfixable hardware

[PATCH 14/15] gma500: nuke the PSB debug stuff

Hi Alan Just a thought. Shouldn't we use the DRM macros for printing debug info? -Patrik On Wed, Jun 8, 2011 at 12:15 PM, Alan Cox wrote: > From: Alan Cox > > Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal > drivers if and when we need debug on stuff. > >

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #12 from almos 2011-06-09 02:31:46 PDT --- (In reply to comment #10) > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 > error messages seem to be unfixable hardware limitations. OK, but why does it

[Bug 37075] objview demo has messed up geometry with r300g

https://bugs.freedesktop.org/show_bug.cgi?id=37075 almos changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #8 from almos 2011-06-09

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

https://bugs.freedesktop.org/show_bug.cgi?id=38022 Harald Judt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[PATCH] drm: Honour O_NONBLOCK on the device for reading events

On Wed, 8 Jun 2011 20:14:01 +0100 Chris Wilson wrote: > Otherwise drmHandleEvent will block if accidentally read too often... > > Signed-off-by: Chris Wilson > Cc: Phillip Haddad > --- > drivers/gpu/drm/drm_fops.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

https://bugs.freedesktop.org/show_bug.cgi?id=38022 Harald Judt h.j...@gmx.at changed: What|Removed |Added Status|RESOLVED|REOPENED

Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

On Thu, 9 Jun 2011 03:10:03 +0200 Patrik Jakobsson patrik.r.jakobs...@gmail.com wrote: Hi Alan Just a thought. Shouldn't we use the DRM macros for printing debug info? Linux has perfectly good printing functions and using them means we can use dev_dbg() which supports things like nice

Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

On Thu, 09 Jun 2011 14:05:59 +1000 Dave Airlie airl...@redhat.com wrote: On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: To properly support the various plane formats supported by different hardware, the kernel must know the pixel format of a framebuffer object. So add a new ioctl

[Bug 37075] objview demo has messed up geometry with r300g

https://bugs.freedesktop.org/show_bug.cgi?id=37075 almos aaalmo...@gmail.com changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #8 from

Re: [PATCH 1/4] drm: add plane support

On 06/08/2011 08:54 PM, Jesse Barnes wrote: On Wed, 8 Jun 2011 11:41:17 +0200 Marcus Lorentzonmarcus.xm.lorent...@stericsson.com wrote: On 06/07/2011 11:01 PM, Jesse Barnes wrote: On Tue, 7 Jun 2011 13:07:39 -0700 Jesse Barnesjbar...@virtuousgeek.org wrote: +/* Planes

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #12 from almos aaalmo...@gmail.com 2011-06-09 02:31:46 PDT --- (In reply to comment #10) The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 error messages seem to be unfixable hardware limitations. OK, but

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #13 from Marek Olšák mar...@gmail.com 2011-06-09 03:38:24 PDT --- (In reply to comment #12) (In reply to comment #10) The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 error messages seem to be unfixable

Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: On Thu, 9 Jun 2011 03:10:03 +0200 Patrik Jakobsson patrik.r.jakobs...@gmail.com wrote: Hi Alan Just a thought. Shouldn't we use the DRM macros for printing debug info? Linux has perfectly good printing functions and using them means

Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

On Thu, 2011-06-09 at 09:21 +0100, Alan Cox wrote: On Thu, 09 Jun 2011 14:05:59 +1000 Dave Airlie airl...@redhat.com wrote: On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: To properly support the various plane formats supported by different hardware, the kernel must know the

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #14 from Henri Verbeet hverb...@gmail.com 2011-06-09 03:57:31 PDT --- (In reply to comment #10) Is there a way to disable the shader model 3.0 in Wine/DX9? Not at the moment, but I'm considering adding a registry key to limit the

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #15 from Sven Arvidsson s...@whiz.se 2011-06-09 04:02:32 PDT --- Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? So using something like MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_texture_lod would cause it to

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #16 from Henri Verbeet hverb...@gmail.com 2011-06-09 04:27:59 PDT --- (In reply to comment #15) Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? So using something like

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #17 from Henri Verbeet hverb...@gmail.com 2011-06-09 04:30:29 PDT --- I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to Wine first for that to work. -- Configure bugmail:

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #6 from Fabio Pedretti fabio@libero.it 2011-06-09 04:37:34 PDT --- I don't consider Hyper-Z ready yet but thanks for testing it. It is enabled by default now, is it by accident? -- Configure bugmail:

Re: Modeline problem with Radeon KMS

So it decides this modeline is usable for the console while it is not. Ah, ok. yeah, that mode has a much higher clock than those chips can handle. Where is that mode even coming from? I don't see it in the EDID. The attached patch should filter out that mode. It works, thank you! Now

Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote: On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: On Thu, 9 Jun 2011 03:10:03 +0200 Patrik Jakobsson wrote: Hi Alan Just a thought. Shouldn't we use the DRM macros for printing debug info? Linux has perfectly good printing functions

Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format

You also don't need a headwer with a complete list of fourcc names in it, that is the half the point of FourCC. #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8 RGB-3-3-2 */ See that V4L2 and v4l2? I'd rather not have them used in the drm They are just helpers.

Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

Though if psb wants to be different to other drm drivers it can lead the way, though it'll be a total nightmare for all the people who follow documentation on how to debug drm drivers using drm.debug=1,2,4,8. for various code paths. Actually it seems to work out nicely because you can debug

Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

Yes, my concern was about drm.debug and use of all the DRM portability stuff (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...) The portability might not be important at this point but I just wanted to raise the question so I know what is right / wrong. The gma500 driver uses a

[Bug 37168] Regression: Kernel hard-lock when running Second Life

https://bugs.freedesktop.org/show_bug.cgi?id=37168 Sven Arvidsson s...@whiz.se changed: What|Removed |Added CC||s...@whiz.se --- Comment

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #7 from Marek Olšák mar...@gmail.com 2011-06-09 07:21:05 PDT --- (In reply to comment #6) I don't consider Hyper-Z ready yet but thanks for testing it. It is enabled by default now, is it by accident? It's disabled. There are

[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #8 from almos aaalmo...@gmail.com 2011-06-09 07:59:43 PDT --- (In reply to comment #6) I don't consider Hyper-Z ready yet but thanks for testing it. It is enabled by default now, is it by accident? Perhaps you mean that it always

Re: Radeon drm: Hang with posting GPU when PCI card is primary

[ 10.169900] [drm] radeon kernel modesetting enabled. [ 10.170270] radeon :02:00.0: enabling device (0080 - 0083) [ 10.170816] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [ 10.171044] radeon :02:00.0: PCI INT A - Link[LNKA] - GSI 11 (level, low) - IRQ 11 [ 10.172664]

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #9 from Harald Judt h.j...@gmx.at 2011-06-09 10:13:49 PDT --- However, it's a bit better now, as it did not happen during normal desktop usage (till now). I spoke too soon. Problem is still there :-( -- Configure bugmail:

[Bug 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)

https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #1 from Ian Romanick i...@freedesktop.org 2011-06-09 10:18:17 PDT --- That enum is GL_FRAGMENT_SHADER_ATI. If that driver doesn't support GL_ATI_fragment_shader, and I believe that only the r200 driver does, this is an application

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #10 from Harald Judt h.j...@gmx.at 2011-06-09 10:36:13 PDT --- Bug 27523 seems similar, but not identical to this one. https://bugs.freedesktop.org/show_bug.cgi?id=27523 -- Configure bugmail:

[PATCH 3/3] alpha, drm: Add Alpha support to Radeon DRM code

Alpha needs to have the system bus address for the device's local memory available, so that it can be returned to user-level, where it may be used in an mmap(). So, we make bus.addr hold the ioremap() return for kernel use, and then we can modify bus.base appropriately. Signed-off-by: Jay

[PATCH 0/3] alpha, drm: Update Alpha DRM support

This patch set fixes Alpha-specific support in the DRM code, allowing Radeon KMS and the MGA driver to work properly on Alpha-based machines. Jay Jay Estabrook (3): alpha, drm: Update Alpha DRM support alpha, drm: Cleanup Alpha support in DRM generic code alpha, drm: Remove obsolete Alpha

[PATCH 1/3] alpha, drm: Cleanup Alpha support in DRM generic code

Remove an obsolete Alpha adjustment, and modify another, to go with the current Alpha architecture support. Signed-off-by: Jay Estabrook jay.estabr...@gmail.com --- drivers/gpu/drm/drm_bufs.c|3 --- drivers/gpu/drm/drm_vm.c |2 +- 2 files changed, 1 insertion(+), 4 deletions(-)

[PATCH 2/3] alpha, drm: Remove obsolete Alpha support in MGA DRM code

Remove an obsolete Alpha adjustment in the drm for MGA on Alpha. Signed-off-by: Jay Estabrook jay.estabr...@gmail.com --- drivers/gpu/drm/mga/mga_drv.h | 19 --- 1 file changed, 19 deletions(-) diff -Naurp a/drivers/gpu/drm/mga/mga_drv.h b/drivers/gpu/drm/mga/mga_drv.h ---

Re: [PATCH 0/3] alpha, drm: Update Alpha DRM support

On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook jay.estabr...@gmail.com wrote: This patch set fixes Alpha-specific support in the DRM code, allowing Radeon KMS and the MGA driver to work properly on Alpha-based machines. Jay Jay Estabrook (3):  alpha, drm: Update Alpha DRM support  alpha,

[Bug 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)

https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com 2011-06-09 19:58:59 PDT --- Since it only happens when I use Diablo 2 with Glide, it is probably related to the Glide to OpenGL wrapper. If indeed the extension is not supported

[Bug 33912] [RV515] Kernel .35 onwards, Random X freezes while scrolling

https://bugzilla.kernel.org/show_bug.cgi?id=33912 Vish drkv...@yahoo.com changed: What|Removed |Added Kernel Version|.35 .36 .37 .38 |.35, .36, .37, .38, .39 ---

[Bug 33912] [RV515] Kernel .35 onwards, Random X freezes while scrolling

https://bugzilla.kernel.org/show_bug.cgi?id=33912 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC|