asm/vga.h (was: Re: drm: Add support for platform devices to register as DRM devices)

On Fri, Aug 6, 2010 at 01:59, Linux Kernel Mailing List wrote: > Gitweb: ? ? > http://git.kernel.org/linus/dcdb167402cbdca1d021bdfa5f63995ee0a79317 > Commit: ? ? dcdb167402cbdca1d021bdfa5f63995ee0a79317 > Parent: ? ? 01d73a6967f12fe6c4bbde1834a9fe662264a2eb > Author: ? ? Jordan Crouse >

[PATCH] drm/i915: set LVDS connector status to unknown if the lid is closed

On Tue, Aug 10, 2010 at 7:16 PM, Andrei Paskevich wrote: > Currently, the LVDS connector on i915-equipped laptops > is always reported as connected, regardless of the lid > state and presence of external monitors. This was done > because of too many BIOSes reporting lid status in > an unreliable

[PATCH] drm/radeon/kms: avoid corner case issue with unmappable vram V2

On Tue, Aug 10, 2010 at 5:41 PM, wrote: > From: Jerome Glisse > > We should not allocate any object into unmappable vram if we > have no means to access them which on all GPU means having the > CP running and on newer GPU having the blit utility working. > > This patch limit the vram allocation

asm/vga.h (was: Re: drm: Add support for platform devices to register as DRM devices)

e: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100810/f99ea41c/attachment.pgp>

[PATCH] drm/radeon/kms: avoid corner case issue with unmappable vram V2

From: Jerome Glisse We should not allocate any object into unmappable vram if we have no means to access them which on all GPU means having the CP running and on newer GPU having the blit utility working. This patch limit the vram allocation to visible vram until we have

[PATCH] drm/radeon: Add early unregister of firmware fb's

Without this, we attempt the handover too late, the firmware fb might be accessing the chip simultaneously to us re-initializing various parts of it, which might frighten babies or cause all sort of nasty psychologic trauma to kitten. Signed-off-by: Benjamin Herrenschmidt ---

[PATCH] drm/radeon/kms: avoid corner case issue with unmappable vram

From: Jerome Glisse We should not allocate any object into unmappable vram if we have no means to access them which on all GPU means having the CP running and on newer GPU having the blit utility working. This patch limit the vram allocation to visible vram until we have

[PATCH] drm/radeon/kms: r600 CS parser fixes

Alex Deucher wrote: > - buffer offsets in the base regs are 256b aligned so > shift properly when comparing, fixed by Andre Maasikas > - mipmap size was calculated wrong when nlevel=0 > - texture bo offsets were used after the bo base address was added > - vertex resource size register is size -

[Bug 29495] New: [r300g] Shadowgrounds: character portraits rendered wrong

https://bugs.freedesktop.org/show_bug.cgi?id=29495 Summary: [r300g] Shadowgrounds: character portraits rendered wrong Product: Mesa Version: git Platform: Other URL:

i915 kernel Oops with 2.6.35 and glxinfo (or other GL programs)

On my laptop X hangs as soon as something uses OpenGL it seems. Running for example glxinfo or glxgears causes it to freeze. I have not had any issues like this before, and 2.6.34 works ok but not 2.6.35 I have pasted the Oops here: http://codepad.org/R9Nuheug I will include it with this email

[PATCH] drm/radeon/kms: use tracked values for sclk and mclk

Rather than calling get_memory_clock and get_engine_clock, used the tracked values from the pm code. Calling the tables adds additional latency in the modesetting and pm paths. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_clocks.c |8

[Bug 29445] Linux 2.6.34 kernel Radeon KMS driver freezes my computer sometimes

https://bugs.freedesktop.org/show_bug.cgi?id=29445 --- Comment #7 from 0453411800 at netti.fi 2010-08-10 11:11:45 PDT --- A little update... I've tried out all the different kernel options that I could think of as well as enable USB debugging output, usb_storage debugging output, ATA system

[Bug 28940] rv515 (Mobility x1400) Display corruption after some time

https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #3 from Nicos Gollan 2010-08-10 08:31:19 PDT --- It's still there in the 2.6.35 kernel. I noticed the following messages in dmesg when waking up from suspend-to-RAM: [1.463035] ATOM BIOS: M54CSP/M52CSP [27369.832013]

[Bug 28517] [r300g] loop unrolling fails (was: Savage 2 : characters are not rendered + another corruptions)

https://bugs.freedesktop.org/show_bug.cgi?id=28517 --- Comment #13 from Sven Arvidsson 2010-08-10 07:51:36 PDT --- Created an attachment (id=37768) --> (https://bugs.freedesktop.org/attachment.cgi?id=37768) Screenshot of oversized character I added a screenshot of the character, if that's

[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved

https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #25 from peterle at hottemptation.org 2010-08-10 04:22:23 PDT --- I mean "immediatley" -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the

[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved

https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #24 from peterle at hottemptation.org 2010-08-10 04:20:44 PDT --- I'am sorry, the patch doesn't fix 29384 and 27744. The system reacts like before, dmesg output is also exactly the same. To new hints/quesitions: With 2.6.34 I had no

[git pull] drm tree some more bits

I just updated the tree, I had to drop one of the cleanups for now, same tree has the initial mail. The following changes since commit 96576a9e1a0cdb8a43d3af5846be0948f52b4460: agp: intel-agp: do not use PCI resources before pci_enable_device() (2010-08-05 12:28:25 +1000) are available in

[Bug 28517] [r300g] loop unrolling fails (was: Savage 2 : characters are not rendered + another corruptions)

https://bugs.freedesktop.org/show_bug.cgi?id=28517 --- Comment #12 from Pavel Ondra?ka 2010-08-10 01:33:26 PDT --- Created an attachment (id=37759) --> (https://bugs.freedesktop.org/attachment.cgi?id=37759) RADEON_DEBUG=vp log with vs-if-loop.patch Characters are being rendered now with your

[Bug 29363] [r300g] Starcraft 2: "r300 VP: Compiler error"

https://bugs.freedesktop.org/show_bug.cgi?id=29363 Pavel Ondra?ka changed: What|Removed |Added Attachment #37528|0 |1 is obsolete|

[Bug 29363] [r300g] Starcraft 2: "r300 VP: Compiler error"

https://bugs.freedesktop.org/show_bug.cgi?id=29363 Pavel Ondra?ka changed: What|Removed |Added Attachment #37530|0 |1 is obsolete|

[PATCH 0/2] RFC: allow driver to plugin alternative to drm_mm

acked-by: Thomas Hellstr?m On 08/05/2010 03:09 PM, Ben Skeggs wrote: > From: Ben Skeggs > > In order to properly deal with GPU reordering of blocks in physical VRAM, > Nouveau needs to be able to have better control over VRAM allocations. > > Currently nouveau is extremely wasteful and forces

[git pull] drm tree some more bits

The main reason for this, is Ben got a nvidia fermi card and added modesetting support just before the window opened, there is no accel support, but having kms support for these GPUs is a good start. Its all the GTX4xx cards. The other bulk is because ajax moved a load of modes to their own

[PATCH] drm/radeon: Add early unregister of firmware fb's

Without this, we attempt the handover too late, the firmware fb might be accessing the chip simultaneously to us re-initializing various parts of it, which might frighten babies or cause all sort of nasty psychologic trauma to kitten. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

[Bug 29363] [r300g] Starcraft 2: r300 VP: Compiler error

https://bugs.freedesktop.org/show_bug.cgi?id=29363 Pavel Ondračka dra...@centrum.cz changed: What|Removed |Added Attachment #37530|0 |1 is obsolete|

[Bug 29363] [r300g] Starcraft 2: r300 VP: Compiler error

https://bugs.freedesktop.org/show_bug.cgi?id=29363 Pavel Ondračka dra...@centrum.cz changed: What|Removed |Added Attachment #37528|0 |1 is obsolete|

[Bug 28517] [r300g] loop unrolling fails (was: Savage 2 : characters are not rendered + another corruptions)

https://bugs.freedesktop.org/show_bug.cgi?id=28517 --- Comment #12 from Pavel Ondračka dra...@centrum.cz 2010-08-10 01:33:26 PDT --- Created an attachment (id=37759) -- (https://bugs.freedesktop.org/attachment.cgi?id=37759) RADEON_DEBUG=vp log with vs-if-loop.patch Characters are being

[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved

https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #24 from pete...@hottemptation.org 2010-08-10 04:20:44 PDT --- I'am sorry, the patch doesn't fix 29384 and 27744. The system reacts like before, dmesg output is also exactly the same. To new hints/quesitions: With 2.6.34 I had no

[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved

https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #25 from pete...@hottemptation.org 2010-08-10 04:22:23 PDT --- I mean immediatley -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee

[Bug 28517] [r300g] loop unrolling fails (was: Savage 2 : characters are not rendered + another corruptions)

https://bugs.freedesktop.org/show_bug.cgi?id=28517 --- Comment #13 from Sven Arvidsson s...@whiz.se 2010-08-10 07:51:36 PDT --- Created an attachment (id=37768) -- (https://bugs.freedesktop.org/attachment.cgi?id=37768) Screenshot of oversized character I added a screenshot of the character, if

i915 kernel Oops with 2.6.35 and glxinfo (or other GL programs)

On my laptop X hangs as soon as something uses OpenGL it seems. Running for example glxinfo or glxgears causes it to freeze. I have not had any issues like this before, and 2.6.34 works ok but not 2.6.35 I have pasted the Oops here: http://codepad.org/R9Nuheug I will include it with this email

[Bug 28940] rv515 (Mobility x1400) Display corruption after some time

https://bugs.freedesktop.org/show_bug.cgi?id=28940 --- Comment #3 from Nicos Gollan gt...@spearhead.de 2010-08-10 08:31:19 PDT --- It's still there in the 2.6.35 kernel. I noticed the following messages in dmesg when waking up from suspend-to-RAM: [1.463035] ATOM BIOS: M54CSP/M52CSP

[PATCH] drm/radeon/kms: use tracked values for sclk and mclk

Rather than calling get_memory_clock and get_engine_clock, used the tracked values from the pm code. Calling the tables adds additional latency in the modesetting and pm paths. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/radeon_clocks.c |8

[Bug 29445] Linux 2.6.34 kernel Radeon KMS driver freezes my computer sometimes

https://bugs.freedesktop.org/show_bug.cgi?id=29445 --- Comment #7 from 0453411...@netti.fi 2010-08-10 11:11:45 PDT --- A little update... I've tried out all the different kernel options that I could think of as well as enable USB debugging output, usb_storage debugging output, ATA system

asm/vga.h (was: Re: drm: Add support for platform devices to register as DRM devices)

On Fri, Aug 6, 2010 at 01:59, Linux Kernel Mailing List linux-ker...@vger.kernel.org wrote: Gitweb:     http://git.kernel.org/linus/dcdb167402cbdca1d021bdfa5f63995ee0a79317 Commit:     dcdb167402cbdca1d021bdfa5f63995ee0a79317 Parent:     01d73a6967f12fe6c4bbde1834a9fe662264a2eb Author:    

[PATCH] drm/radeon/kms: avoid corner case issue with unmappable vram V2

From: Jerome Glisse jgli...@redhat.com We should not allocate any object into unmappable vram if we have no means to access them which on all GPU means having the CP running and on newer GPU having the blit utility working. This patch limit the vram allocation to visible vram until we have

[PATCH] drm/i915: set LVDS connector status to unknown if the lid is closed

Currently, the LVDS connector on i915-equipped laptops is always reported as connected, regardless of the lid state and presence of external monitors. This was done because of too many BIOSes reporting lid status in an unreliable way. However, in a quite usual setup of a laptop attached to an

Re: [PATCH] drm/i915: set LVDS connector status to unknown if the lid is closed

On Tue, Aug 10, 2010 at 7:16 PM, Andrei Paskevich and...@tertium.org wrote: Currently, the LVDS connector on i915-equipped laptops is always reported as connected, regardless of the lid state and presence of external monitors. This was done because of too many BIOSes reporting lid status in