[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #1 from Michel Dänzer 2010-04-22 00:31:20 PDT --- Looks like Armagetron Advanced or SDL is doing crazy stuff from a signal handler... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] agp: use scratch page on memory remove and at GATT creation V4
On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote: > Convert most AGP chipset to use scratch page as default entries. > This help avoiding GPU querying 0 address and trigger computer > fault. With KMS and memory manager we bind/unbind AGP memory > constantly and it seems that some GPU are still doing AGP > traffic even after GPU report being idle with the memory segment. > > Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on : > - SIS 1039:0001 & 1039:0003 > - Intel 865 8086:2571 > > Compile tested for other bridges > > V2 enable scratch page on uninorth > V3 fix unbound check in uninorth insert memory (Michel Dänzer) > V4 rebase on top of drm-next branch with the lastest intel AGP >changeset (stable should use version V3 of the patch) Nope, v3 still contains the bogus changes to the intel gtt driver (only used by intel igds). In this patch, the intel parts look good. While looking add this I've found some more stuff to nit-pick over ;) Instead of splattering needs_scratch_page = true all over the agp drivers, why not do the changes in the agp core (and the few fixups required in the drivers) and simply kill this variable? If using a scratch page is required by upper layers (drm/radeon), then keeping around this "looks optional, but is very much a core requirement" thing lingering around is quite a call for trouble, IMHO. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] agp: use scratch page on memory remove and at GATT creation V4
On Thu, Apr 22, 2010 at 11:27:11AM +0200, Daniel Vetter wrote: > On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote: > > Convert most AGP chipset to use scratch page as default entries. > > This help avoiding GPU querying 0 address and trigger computer > > fault. With KMS and memory manager we bind/unbind AGP memory > > constantly and it seems that some GPU are still doing AGP > > traffic even after GPU report being idle with the memory segment. > > > > Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on : > > - SIS 1039:0001 & 1039:0003 > > - Intel 865 8086:2571 > > > > Compile tested for other bridges > > > > V2 enable scratch page on uninorth > > V3 fix unbound check in uninorth insert memory (Michel Dänzer) > > V4 rebase on top of drm-next branch with the lastest intel AGP > >changeset (stable should use version V3 of the patch) > > Nope, v3 still contains the bogus changes to the intel gtt driver (only > used by intel igds). In this patch, the intel parts look good. > > While looking add this I've found some more stuff to nit-pick over ;) > Instead of splattering needs_scratch_page = true all over the agp drivers, > why not do the changes in the agp core (and the few fixups required in the > drivers) and simply kill this variable? If using a scratch page is > required by upper layers (drm/radeon), then keeping around this "looks > optional, but is very much a core requirement" thing lingering around is > quite a call for trouble, IMHO. > > Yours, Daniel > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 V4 is ok it apply on top of drm-next, and no i don't kill needs_scratch_page because i don't want to touch Alpha AGP code (i think it should die, i don't think alpha got AGP hw we care about or even support). Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: r127 w/ KMS on PPC?
On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > > Any further reading would be tremendously helpful. > > > > It should be pretty easy to get kms going with r128 by integrating it > into the radeon drm and ddx. The hard part will be porting the r128 > 3D driver to kms. Also, kms support for r128-based macs will be a bit > trickier than x86 because the boards don't have an x86 video bios. > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > driver for properly setting up the cards without an x86 bios. Let me > know if you have any questions. I'm making good progress, moving stuff around, tacking on the KMS driver and its fops on top of the r128 drivers, fixing up things. I think it'll be a few days before the KMS stuff is integrated and even then it might crash first time it's loaded. -- http://www.munted.org.uk One very high maintenance cat living here. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: r127 w/ KMS on PPC?
On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > On Wed, Apr 21, 2010 at 6:26 PM, Alex Buell wrote: > > On Thu, 2010-04-22 at 07:55 +1000, Dave Airlie wrote: > >> > I'd like to step up for that, it'd let me learn a lot. I have > >> already > >> > extracted the r128 and its DRI from the 2.6.32 kernel tree and built > >> > them as modules and they both work just fine, with the binary > >> firmware. > >> > What's involved in making KMS work on PPC? I'm sure I need the KMS > >> > helpers and the TTM module as well right? > >> > >> For r128, it could actually re-use a lot of the radeon KMS code, in > >> fact nearly all of it. > >> > >> Alex Deucher started doing a UMS merge of radeon/r128 at one point > >> http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support > >> > >> the main things would be adding the differences in the bios parsing, > >> and modesetting paths to KMS first. > > > > I'll start digging into the Radeon, see what I can learn about KMS > > integration. For now I'll build the r128 out of the tree, simplifies > > things a bit. Is that OK? > > > > Any further reading would be tremendously helpful. > > > > It should be pretty easy to get kms going with r128 by integrating it > into the radeon drm and ddx. The hard part will be porting the r128 > 3D driver to kms. Also, kms support for r128-based macs will be a bit > trickier than x86 because the boards don't have an x86 video bios. > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > driver for properly setting up the cards without an x86 bios. Let me > know if you have any questions. Whilst hacking on the drm and r128 sources out of the tree I noticed a peculiarity of the build process. It turns out that if you build the r128 module separately after working on it, and insmod both drm and r128 modules, it spits out a lot missing drm_* symbols. However, if I build both drm and r128 modules then insmod both modules, it doesn't spit out any missing drm_* symbols. I don't quite understand why this happens, but for now I just start the build in the drm directory instead. -- http://www.munted.org.uk One very high maintenance cat living here. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: r127 w/ KMS on PPC?
On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > On Wed, Apr 21, 2010 at 6:26 PM, Alex Buell wrote: > > On Thu, 2010-04-22 at 07:55 +1000, Dave Airlie wrote: > >> > I'd like to step up for that, it'd let me learn a lot. I have > >> already > >> > extracted the r128 and its DRI from the 2.6.32 kernel tree and built > >> > them as modules and they both work just fine, with the binary > >> firmware. > >> > What's involved in making KMS work on PPC? I'm sure I need the KMS > >> > helpers and the TTM module as well right? > >> > >> For r128, it could actually re-use a lot of the radeon KMS code, in > >> fact nearly all of it. > >> > >> Alex Deucher started doing a UMS merge of radeon/r128 at one point > >> http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support > >> > >> the main things would be adding the differences in the bios parsing, > >> and modesetting paths to KMS first. > > > > I'll start digging into the Radeon, see what I can learn about KMS > > integration. For now I'll build the r128 out of the tree, simplifies > > things a bit. Is that OK? > > > > Any further reading would be tremendously helpful. > > > > It should be pretty easy to get kms going with r128 by integrating it > into the radeon drm and ddx. The hard part will be porting the r128 > 3D driver to kms. Also, kms support for r128-based macs will be a bit > trickier than x86 because the boards don't have an x86 video bios. > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > driver for properly setting up the cards without an x86 bios. Let me > know if you have any questions. Also, I was wondering why these chipset specific _drm.h files are kept in include/drm/ i.e. r128_drm.h, radeon_drm.h and mga_drm.h instead of being within the drivers/gpu/drm/*/ directories? -- http://www.munted.org.uk One very high maintenance cat living here. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: r127 w/ KMS on PPC?
On Thu, Apr 22, 2010 at 01:46:46PM +0100, Alex Buell wrote: > On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > > On Wed, Apr 21, 2010 at 6:26 PM, Alex Buell > > wrote: > > > On Thu, 2010-04-22 at 07:55 +1000, Dave Airlie wrote: > > >> > I'd like to step up for that, it'd let me learn a lot. I have > > >> already > > >> > extracted the r128 and its DRI from the 2.6.32 kernel tree and built > > >> > them as modules and they both work just fine, with the binary > > >> firmware. > > >> > What's involved in making KMS work on PPC? I'm sure I need the KMS > > >> > helpers and the TTM module as well right? > > >> > > >> For r128, it could actually re-use a lot of the radeon KMS code, in > > >> fact nearly all of it. > > >> > > >> Alex Deucher started doing a UMS merge of radeon/r128 at one point > > >> http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support > > >> > > >> the main things would be adding the differences in the bios parsing, > > >> and modesetting paths to KMS first. > > > > > > I'll start digging into the Radeon, see what I can learn about KMS > > > integration. For now I'll build the r128 out of the tree, simplifies > > > things a bit. Is that OK? > > > > > > Any further reading would be tremendously helpful. > > > > > > > It should be pretty easy to get kms going with r128 by integrating it > > into the radeon drm and ddx. The hard part will be porting the r128 > > 3D driver to kms. Also, kms support for r128-based macs will be a bit > > trickier than x86 because the boards don't have an x86 video bios. > > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > > driver for properly setting up the cards without an x86 bios. Let me > > know if you have any questions. > > Also, I was wondering why these chipset specific _drm.h files are kept > in include/drm/ i.e. r128_drm.h, radeon_drm.h and mga_drm.h instead of > being within the drivers/gpu/drm/*/ directories? Because we install them along other kernel header file (ie they are included in kernel-header package of distribution) Maybe we should move non public header out of include/drm but i don't think it's really needed. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #2 from Luke-Jr 2010-04-22 06:56:17 PDT --- My uneducated guess is that radeonFlush is triggering a SIGSEGV and libSDL is trying to shutdown sanely as a result, which creates a loop since the radeonFlush is already in the shutdown procedure. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] agp: use scratch page on memory remove and at GATT creation V4
On Thu, Apr 22, 2010 at 6:30 AM, Jerome Glisse wrote: > On Thu, Apr 22, 2010 at 11:27:11AM +0200, Daniel Vetter wrote: >> On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote: >> > Convert most AGP chipset to use scratch page as default entries. >> > This help avoiding GPU querying 0 address and trigger computer >> > fault. With KMS and memory manager we bind/unbind AGP memory >> > constantly and it seems that some GPU are still doing AGP >> > traffic even after GPU report being idle with the memory segment. >> > >> > Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on : >> > - SIS 1039:0001 & 1039:0003 >> > - Intel 865 8086:2571 >> > >> > Compile tested for other bridges >> > >> > V2 enable scratch page on uninorth >> > V3 fix unbound check in uninorth insert memory (Michel Dänzer) >> > V4 rebase on top of drm-next branch with the lastest intel AGP >> > changeset (stable should use version V3 of the patch) >> >> Nope, v3 still contains the bogus changes to the intel gtt driver (only >> used by intel igds). In this patch, the intel parts look good. >> >> While looking add this I've found some more stuff to nit-pick over ;) >> Instead of splattering needs_scratch_page = true all over the agp drivers, >> why not do the changes in the agp core (and the few fixups required in the >> drivers) and simply kill this variable? If using a scratch page is >> required by upper layers (drm/radeon), then keeping around this "looks >> optional, but is very much a core requirement" thing lingering around is >> quite a call for trouble, IMHO. >> >> Yours, Daniel >> -- >> Daniel Vetter >> Mail: dan...@ffwll.ch >> Mobile: +41 (0)79 365 57 48 > > V4 is ok it apply on top of drm-next, and no i don't kill > needs_scratch_page because i don't want to touch Alpha AGP > code (i think it should die, i don't think alpha got AGP > hw we care about or even support). > > Cheers, > Jerome (Working) AGP is only available on high-end systems [1]. I've been working on Alpha things for two years now, and I've talked to only a single person with one of these systems, and he worked at HP at the time. I'd certainly like to keep these supported, in the case someone decides to donate one to me. :) If you want to have any changes against Alpha AGP checked, Ivan Kokshaysky is your guy. Matt [1] http://alphalinux.org/wiki/index.php/User:Mattst88/Alphas_with_AGP ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #3 from Michel Dänzer 2010-04-22 07:04:02 PDT --- Can you get another backtrace showing what signal it is, with debugging symbols for at least r300_dri.so? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786
--- Comment #4 from Luke-Jr 2010-04-22
07:29:08 PDT ---
Program received signal SIGSEGV, Segmentation fault.
0x71d2fd79 in radeonFlush (ctx=0xbe72e0) at radeon_common.c:1107
1107if ((ctx->DrawBuffer->Name == 0) && radeon->front_buffer_dirty)
{
(gdb) bt
#0 0x71d2fd79 in radeonFlush (ctx=0xbe72e0) at radeon_common.c:1107
#1 0x71d20ae5 in radeon_firevertices (radeon=0xbe0a60) at
radeon_cmdbuf.h:118
#2 0x71d20a10 in r300DeleteTexture (ctx=0xbe72e0, texObj=0x12404d0)
at r300_tex.c:262
#3 0x71de3559 in _mesa_reference_texobj (ptr=0xbf2930, tex=0x0)
at main/texobj.c:345
#4 0x71de8963 in _mesa_free_texture_data (ctx=0xbe72e0) at
main/texstate.c:788
#5 0x71d511c5 in _mesa_free_context_data (ctx=0xbe72e0) at
main/context.c:972
#6 0x71d5137c in _mesa_destroy_context (ctx=0xbe72e0) at
main/context.c:1028
#7 0x71d2c0d7 in radeonDestroyContext (driContextPriv=0xbd6450)
at radeon_common_context.c:328
#8 0x71cfcf1d in driDestroyContext (pcp=0xbd6450) at
../common/dri_util.c:546
#9 0x7703f8c6 in driDestroyContext (context=0xb83290, psc=0xbd5fc0,
dpy=0xa8ac10) at dri_glx.c:482
#10 0x77007810 in DestroyContext (dpy=0xa8ac10, gc=0xbe08b0) at
glxcmds.c:556
#11 0x770079b0 in glXDestroyContext (dpy=0xa8ac10, gc=0xbe08b0) at
glxcmds.c:592
#12 0x76b9df22 in ?? () from /usr/lib/libSDL-1.2.so.0
#13 0x76ba1cfe in ?? () from /usr/lib/libSDL-1.2.so.0
#14 0x76ba1f17 in ?? () from /usr/lib/libSDL-1.2.so.0
#15 0x76b92902 in SDL_VideoQuit () from /usr/lib/libSDL-1.2.so.0
#16 0x76b6c16d in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#17 0x0042a1e9 in main ()
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786
--- Comment #5 from Luke-Jr 2010-04-22
07:31:36 PDT ---
1107 if ((ctx->DrawBuffer->Name == 0) &&
radeon->front_buffer_dirty) {
- 0x7f3f1063ad6e :mov-0x28(%rbp),%rax
- 0x7f3f1063ad72 :mov0xf8(%rax),%rax
SEGV>- 0x7f3f1063ad79 :mov0x28(%rax),%eax
- 0x7f3f1063ad7c :test %eax,%eax
- 0x7f3f1063ad7e :jne0x7f3f1063ae25
- 0x7f3f1063ad84 :mov-0x18(%rbp),%rax
- 0x7f3f1063ad88 :movzbl 0x552(%rax),%eax
- 0x7f3f1063ad8f :test %al,%al
- 0x7f3f1063ad91 :je 0x7f3f1063ae25
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #6 from Luke-Jr 2010-04-22 07:36:00 PDT --- ctx->DrawBuffer is a NULL pointer -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27796] New: atombios stuck in loop
https://bugs.freedesktop.org/show_bug.cgi?id=27796
Summary: atombios stuck in loop
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: pjsa...@hotmail.com
Created an attachment (id=35239)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35239)
bios
I am having problems with lock up in X i loose all input devices
Switching back from the console, i see the following on the screen
atombios stuck in loop
I am using fedora and the version of Xorg is 1.8.0-7.
LSPCI
01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility
X1600] (prog-if 00 [VGA controller])
Subsystem: Apple Computer Inc. MacBook Pro
Flags: bus master, fast devsel, latency 0, IRQ 28
Memory at c000 (32-bit, prefetchable) [size=256M]
I/O ports at 3000 [size=256]
Memory at d830 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at d832 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: radeon
Kernel modules: radeon
EXTRACT FROM /var/log/messages
Apr 22 10:59:51 localhost kernel: INFO: task Xorg:1792 blocked for more than
120 seconds.
Apr 22 10:59:51 localhost kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 22 10:59:51 localhost kernel: Xorg D 3856 1792
1789 0x00400088
Apr 22 10:59:51 localhost kernel: 8800b06cdbc8 0046
8800b06cdb90 8800b06cdb8c
Apr 22 10:59:51 localhost kernel: 8800b06cdb38
1402 8800b06cdfd8
Apr 22 10:59:51 localhost kernel: 8800b06cdfd8 fb80
001d5e80 8800b072a888
Apr 22 10:59:51 localhost kernel: Call Trace:
Apr 22 10:59:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: []
__mutex_lock_common+0x24e/0x392
Apr 22 10:59:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: [] ?
lock_release_holdtime+0x34/0xe3
Apr 22 10:59:51 localhost kernel: []
mutex_lock_nested+0x3e/0x43
Apr 22 10:59:51 localhost kernel: []
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: [] ? might_fault+0x5c/0xac
Apr 22 10:59:51 localhost kernel: [] ? _lock_kernel+0x7d/0x95
Apr 22 10:59:51 localhost kernel: [] drm_ioctl+0x28f/0x373
[drm]
Apr 22 10:59:51 localhost kernel: [] ?
radeon_cs_ioctl+0x0/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: [] ?
sched_clock_local+0x1c/0x82
Apr 22 10:59:51 localhost kernel: [] ?
do_setitimer+0x1b1/0x1e2
Apr 22 10:59:51 localhost kernel: [] ?
sched_clock_cpu+0xc3/0xce
Apr 22 10:59:51 localhost kernel: [] ?
trace_hardirqs_off+0xd/0xf
Apr 22 10:59:51 localhost kernel: [] vfs_ioctl+0x32/0xa6
Apr 22 10:59:51 localhost kernel: [] do_vfs_ioctl+0x490/0x4d6
Apr 22 10:59:51 localhost kernel: [] sys_ioctl+0x56/0x79
Apr 22 10:59:51 localhost kernel: []
system_call_fastpath+0x16/0x1b
Apr 22 10:59:51 localhost kernel: 1 lock held by Xorg/1792:
Apr 22 10:59:51 localhost kernel: #0: (&rdev->cs_mutex){+.+.+.}, at:
[] radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: INFO: task Xorg:1792 blocked for more than
120 seconds.
Apr 22 11:01:51 localhost kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 22 11:01:51 localhost kernel: Xorg D 3856 1792
1789 0x00400088
Apr 22 11:01:51 localhost kernel: 8800b06cdbc8 0046
8800b06cdb90 8800b06cdb8c
Apr 22 11:01:51 localhost kernel: 8800b06cdb38
1402 8800b06cdfd8
Apr 22 11:01:51 localhost kernel: 8800b06cdfd8 fb80
001d5e80 8800b072a888
Apr 22 11:01:51 localhost kernel: Call Trace:
Apr 22 11:01:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: []
__mutex_lock_common+0x24e/0x392
Apr 22 11:01:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: [] ?
lock_release_holdtime+0x34/0xe3
Apr 22 11:01:51 localhost kernel: []
mutex_lock_nested+0x3e/0x43
Apr 22 11:01:51 localhost kernel: []
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: [] ? might_fault+0x5c/0xac
Apr 22 11:01:51 localhost kernel: [] ? _lock_kernel+0x7d/0x95
Apr 22 11:01:51 localhost kernel: [] drm_ioctl+0x28f/0x373
[drm]
Apr 22 11:01:51 localhost kernel: [] ?
radeon_cs_ioctl+0x0/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: [] ?
sched_clock_local+0x1c/0x82
Apr 22 11:01:51 localhost kernel: [] ?
do_setitimer+0x1b1/0x1e2
Apr 22 11:01:51 localhost kernel: [] ?
sched_clock_cpu+0xc3/0xce
Apr 22 11:01:51 localhost kern
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 Luke-Jr changed: What|Removed |Added See Also||http://bugzilla.libsdl.org/ ||show_bug.cgi?id=991 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: 9800 SE has only one quadpipe
>From 386db39adb34e0c5ea1ca3a0341062bed177e3cd Mon Sep 17 00:00:00 2001
From: Tormod Volden
Date: Thu, 22 Apr 2010 16:57:32 -0400
Subject: [PATCH] drm/radeon: 9800 SE has only one quadpipe
Although these cards have 2 pipelines on the silicon only
the first passed the QA and the other should be disabled.
http://www.digital-daily.com/video/ati-radeon9800se/
http://www.rojakpot.com/showarticle.aspx?artno=101&pgno=1
agd5f: add some other SE cards as well; fix up kms
Signed-off-by: Tormod Volden
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r300.c |5 ++---
drivers/gpu/drm/radeon/r420.c |6 ++
drivers/gpu/drm/radeon/radeon_cp.c |9 +++--
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index bb005bf..590f6a8 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -328,13 +328,12 @@ void r300_gpu_init(struct radeon_device *rdev)
{
uint32_t gb_tile_config, tmp;
- /* FIXME: rv380 one pipes ? */
if ((rdev->family == CHIP_R300 && rdev->pdev->device != 0x4144) ||
- (rdev->family == CHIP_R350)) {
+ (rdev->family == CHIP_R350 && rdev->pdev->device != 0x4148)) {
/* r300,r350 */
rdev->num_gb_pipes = 2;
} else {
- /* rv350,rv370,rv380,r300 AD */
+ /* rv350,rv370,rv380,r300 AD, r350 AH */
rdev->num_gb_pipes = 1;
}
rdev->num_z_pipes = 1;
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 3759d83..be092d2 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -59,6 +59,12 @@ void r420_pipes_init(struct radeon_device *rdev)
/* get max number of pipes */
gb_pipe_select = RREG32(0x402C);
num_pipes = ((gb_pipe_select >> 12) & 3) + 1;
+
+ /* SE chips have 1 pipe */
+ if ((rdev->pdev->device == 0x5e4c) ||
+ (rdev->pdev->device == 0x5e4f))
+ num_pipes = 1;
+
rdev->num_gb_pipes = num_pipes;
tmp = 0;
switch (num_pipes) {
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 419630d..2f042a3 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -435,14 +435,19 @@ static void radeon_init_pipes(struct drm_device *dev)
if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R420) {
gb_pipe_sel = RADEON_READ(R400_GB_PIPE_SELECT);
dev_priv->num_gb_pipes = ((gb_pipe_sel >> 12) & 0x3) + 1;
+ /* SE cards have 1 pipe */
+ if ((dev->pdev->device == 0x5e4c) ||
+ (dev->pdev->device == 0x5e4f))
+ dev_priv->num_gb_pipes = 1;
} else {
/* R3xx */
if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R300 &&
dev->pdev->device != 0x4144) ||
- ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R350)) {
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R350 &&
+dev->pdev->device != 0x4148)) {
dev_priv->num_gb_pipes = 2;
} else {
- /* RV3xx/R300 AD */
+ /* RV3xx/R300 AD/R350 AH */
dev_priv->num_gb_pipes = 1;
}
}
--
1.5.6.3
From 386db39adb34e0c5ea1ca3a0341062bed177e3cd Mon Sep 17 00:00:00 2001
From: Tormod Volden
Date: Thu, 22 Apr 2010 16:57:32 -0400
Subject: [PATCH] drm/radeon: 9800 SE has only one quadpipe
Although these cards have 2 pipelines on the silicon only
the first passed the QA and the other should be disabled.
http://www.digital-daily.com/video/ati-radeon9800se/
http://www.rojakpot.com/showarticle.aspx?artno=101&pgno=1
agd5f: add some other SE cards as well; fix up kms
Signed-off-by: Tormod Volden
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r300.c |5 ++---
drivers/gpu/drm/radeon/r420.c |6 ++
drivers/gpu/drm/radeon/radeon_cp.c |9 +++--
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index bb005bf..590f6a8 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -328,13 +328,12 @@ void r300_gpu_init(struct radeon_device *rdev)
{
uint32_t gb_tile_config, tmp;
- /* FIXME: rv380 one pipes ? */
if ((rdev->family == CHIP_R300 && rdev->pdev->device != 0x4144) ||
- (rdev->family == CHIP_R350)) {
+ (rdev->family == CHIP_R350 && rdev->pdev->device != 0x4148)) {
/* r300,r350 */
rdev->num_gb_pipes = 2;
} else {
- /* rv350,rv370,rv380,r300 AD */
+ /* rv350,rv370,rv380,r300 AD, r350 AH */
rdev->num_gb_pipes = 1;
}
rdev->num
[Bug 27739] build in a separate directory includes config.h from source directory
https://bugs.freedesktop.org/show_bug.cgi?id=27739 Kristian Høgsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Kristian Høgsberg 2010-04-22 17:01:31 PDT --- What you're doing is not supported. I get configure: error: source directory already configured; run "make distclean" there first when I try to configure in a build-dir with an already configured source dir. Doing make distclean removes the config.h in the source dir. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms/evergreen: fix LUT setup
>From 5038380b37afe6d79612a5665d46d54086812496 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 22 Apr 2010 22:58:50 -0400
Subject: [PATCH] drm/radeon/kms/evergreen: fix LUT setup
Must have gotten broken during an earlier rebase.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 243c1c4..ce5163e 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -86,12 +86,12 @@ static void evergreen_crtc_load_lut(struct drm_crtc *crtc)
WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_GREEN +
radeon_crtc->crtc_offset, 0x);
WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_RED + radeon_crtc->crtc_offset,
0x);
- WREG32(EVERGREEN_DC_LUT_RW_MODE, radeon_crtc->crtc_id);
- WREG32(EVERGREEN_DC_LUT_WRITE_EN_MASK, 0x0007);
+ WREG32(EVERGREEN_DC_LUT_RW_MODE + radeon_crtc->crtc_offset, 0);
+ WREG32(EVERGREEN_DC_LUT_WRITE_EN_MASK + radeon_crtc->crtc_offset,
0x0007);
- WREG32(EVERGREEN_DC_LUT_RW_INDEX, 0);
+ WREG32(EVERGREEN_DC_LUT_RW_INDEX + radeon_crtc->crtc_offset, 0);
for (i = 0; i < 256; i++) {
- WREG32(EVERGREEN_DC_LUT_30_COLOR,
+ WREG32(EVERGREEN_DC_LUT_30_COLOR + radeon_crtc->crtc_offset,
(radeon_crtc->lut_r[i] << 20) |
(radeon_crtc->lut_g[i] << 10) |
(radeon_crtc->lut_b[i] << 0));
--
1.5.6.3
From 5038380b37afe6d79612a5665d46d54086812496 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 22 Apr 2010 22:58:50 -0400
Subject: [PATCH] drm/radeon/kms/evergreen: fix LUT setup
Must have gotten broken during an earlier rebase.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 243c1c4..ce5163e 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -86,12 +86,12 @@ static void evergreen_crtc_load_lut(struct drm_crtc *crtc)
WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_GREEN + radeon_crtc->crtc_offset,
0x);
WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_RED + radeon_crtc->crtc_offset,
0x);
- WREG32(EVERGREEN_DC_LUT_RW_MODE, radeon_crtc->crtc_id);
- WREG32(EVERGREEN_DC_LUT_WRITE_EN_MASK, 0x0007);
+ WREG32(EVERGREEN_DC_LUT_RW_MODE + radeon_crtc->crtc_offset, 0);
+ WREG32(EVERGREEN_DC_LUT_WRITE_EN_MASK + radeon_crtc->crtc_offset,
0x0007);
- WREG32(EVERGREEN_DC_LUT_RW_INDEX, 0);
+ WREG32(EVERGREEN_DC_LUT_RW_INDEX + radeon_crtc->crtc_offset, 0);
for (i = 0; i < 256; i++) {
- WREG32(EVERGREEN_DC_LUT_30_COLOR,
+ WREG32(EVERGREEN_DC_LUT_30_COLOR + radeon_crtc->crtc_offset,
(radeon_crtc->lut_r[i] << 20) |
(radeon_crtc->lut_g[i] << 10) |
(radeon_crtc->lut_b[i] << 0));
--
1.5.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms/evergreen: No EnableYUV table
>From 3b4696859be2c0ae2f1821cf1df4a5857b59ac7f Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Fri, 23 Apr 2010 02:26:55 -0400
Subject: [PATCH] drm/radeon/kms/evergreen: No EnableYUV table
DCE4 cards don't have an EnableYUV table.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 559c9ce..256036b 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1321,7 +1321,7 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
radeon_encoder->pixel_clock = adjusted_mode->clock;
- if (ASIC_IS_AVIVO(rdev)) {
+ if (ASIC_IS_AVIVO(rdev) && !ASIC_IS_DCE4(rdev)) {
if (radeon_encoder->active_device & (ATOM_DEVICE_CV_SUPPORT |
ATOM_DEVICE_TV_SUPPORT))
atombios_yuv_setup(encoder, true);
else
--
1.5.6.3
From 3b4696859be2c0ae2f1821cf1df4a5857b59ac7f Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Fri, 23 Apr 2010 02:26:55 -0400
Subject: [PATCH] drm/radeon/kms/evergreen: No EnableYUV table
DCE4 cards don't have an EnableYUV table.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 559c9ce..256036b 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1321,7 +1321,7 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
radeon_encoder->pixel_clock = adjusted_mode->clock;
- if (ASIC_IS_AVIVO(rdev)) {
+ if (ASIC_IS_AVIVO(rdev) && !ASIC_IS_DCE4(rdev)) {
if (radeon_encoder->active_device & (ATOM_DEVICE_CV_SUPPORT |
ATOM_DEVICE_TV_SUPPORT))
atombios_yuv_setup(encoder, true);
else
--
1.5.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm radeon fixes
Some minor fixes to the radeon KMS driver three evergreen related one for earlier cards. The following changes since commit b78315f051de8d207bead90470aa216c0617572b: Jesse Barnes (1): drm: delay vblank cleanup until after driver unload are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (2): drm/radeon/kms/evergreen: fix LUT setup drm/radeon/kms/evergreen: No EnableYUV table Dave Airlie (1): drm/radeon/kms: don't print error for legal crtcs. Tormod Volden (1): drm/radeon: 9800 SE has only one quadpipe drivers/gpu/drm/radeon/r300.c|5 ++--- drivers/gpu/drm/radeon/r420.c|6 ++ drivers/gpu/drm/radeon/radeon_cp.c |9 +++-- drivers/gpu/drm/radeon/radeon_display.c |8 drivers/gpu/drm/radeon/radeon_encoders.c |2 +- drivers/gpu/drm/radeon/radeon_kms.c |6 +++--- 6 files changed, 23 insertions(+), 13 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
r127 w/ KMS on PPC?
On Wed, 2010-04-21 at 22:36 +0100, Alex Buell wrote: > On Wed, 2010-04-21 at 16:02 -0400, Matt Turner wrote: > > On Wed, Apr 21, 2010 at 3:51 PM, Alex Buell > > wrote: > > > Does the r128 dri driver supports KMS in the kernel on PPC? I've a G3 > > > iMac 600 here working very well with OpenGL but was wondering if it > > > could support KMS, in which case it would be quite nice. > > > > > > Thanks > > > > There's been some talk about an r128 KMS driver, but nothing has been > > done that I know of. > > I'd like to step up for that, it'd let me learn a lot. I have already > extracted the r128 and its DRI from the 2.6.32 kernel tree and built > them as modules and they both work just fine, with the binary firmware. > What's involved in making KMS work on PPC? I'm sure I need the KMS > helpers and the TTM module as well right? For r128, it could actually re-use a lot of the radeon KMS code, in fact nearly all of it. Alex Deucher started doing a UMS merge of radeon/r128 at one point http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support the main things would be adding the differences in the bios parsing, and modesetting paths to KMS first. Dave.
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #1 from Michel D?nzer 2010-04-22 00:31:20 PDT --- Looks like Armagetron Advanced or SDL is doing crazy stuff from a signal handler... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] agp: use scratch page on memory remove and at GATT creation V4
On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote: > Convert most AGP chipset to use scratch page as default entries. > This help avoiding GPU querying 0 address and trigger computer > fault. With KMS and memory manager we bind/unbind AGP memory > constantly and it seems that some GPU are still doing AGP > traffic even after GPU report being idle with the memory segment. > > Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on : > - SIS 1039:0001 & 1039:0003 > - Intel 865 8086:2571 > > Compile tested for other bridges > > V2 enable scratch page on uninorth > V3 fix unbound check in uninorth insert memory (Michel D?nzer) > V4 rebase on top of drm-next branch with the lastest intel AGP >changeset (stable should use version V3 of the patch) Nope, v3 still contains the bogus changes to the intel gtt driver (only used by intel igds). In this patch, the intel parts look good. While looking add this I've found some more stuff to nit-pick over ;) Instead of splattering needs_scratch_page = true all over the agp drivers, why not do the changes in the agp core (and the few fixups required in the drivers) and simply kill this variable? If using a scratch page is required by upper layers (drm/radeon), then keeping around this "looks optional, but is very much a core requirement" thing lingering around is quite a call for trouble, IMHO. Yours, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] agp: use scratch page on memory remove and at GATT creation V4
On Thu, Apr 22, 2010 at 11:27:11AM +0200, Daniel Vetter wrote: > On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote: > > Convert most AGP chipset to use scratch page as default entries. > > This help avoiding GPU querying 0 address and trigger computer > > fault. With KMS and memory manager we bind/unbind AGP memory > > constantly and it seems that some GPU are still doing AGP > > traffic even after GPU report being idle with the memory segment. > > > > Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on : > > - SIS 1039:0001 & 1039:0003 > > - Intel 865 8086:2571 > > > > Compile tested for other bridges > > > > V2 enable scratch page on uninorth > > V3 fix unbound check in uninorth insert memory (Michel D?nzer) > > V4 rebase on top of drm-next branch with the lastest intel AGP > >changeset (stable should use version V3 of the patch) > > Nope, v3 still contains the bogus changes to the intel gtt driver (only > used by intel igds). In this patch, the intel parts look good. > > While looking add this I've found some more stuff to nit-pick over ;) > Instead of splattering needs_scratch_page = true all over the agp drivers, > why not do the changes in the agp core (and the few fixups required in the > drivers) and simply kill this variable? If using a scratch page is > required by upper layers (drm/radeon), then keeping around this "looks > optional, but is very much a core requirement" thing lingering around is > quite a call for trouble, IMHO. > > Yours, Daniel > -- > Daniel Vetter > Mail: daniel at ffwll.ch > Mobile: +41 (0)79 365 57 48 V4 is ok it apply on top of drm-next, and no i don't kill needs_scratch_page because i don't want to touch Alpha AGP code (i think it should die, i don't think alpha got AGP hw we care about or even support). Cheers, Jerome
r127 w/ KMS on PPC?
On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > > Any further reading would be tremendously helpful. > > > > It should be pretty easy to get kms going with r128 by integrating it > into the radeon drm and ddx. The hard part will be porting the r128 > 3D driver to kms. Also, kms support for r128-based macs will be a bit > trickier than x86 because the boards don't have an x86 video bios. > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > driver for properly setting up the cards without an x86 bios. Let me > know if you have any questions. I'm making good progress, moving stuff around, tacking on the KMS driver and its fops on top of the r128 drivers, fixing up things. I think it'll be a few days before the KMS stuff is integrated and even then it might crash first time it's loaded. -- http://www.munted.org.uk One very high maintenance cat living here.
r127 w/ KMS on PPC?
On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > On Wed, Apr 21, 2010 at 6:26 PM, Alex Buell > wrote: > > On Thu, 2010-04-22 at 07:55 +1000, Dave Airlie wrote: > >> > I'd like to step up for that, it'd let me learn a lot. I have > >> already > >> > extracted the r128 and its DRI from the 2.6.32 kernel tree and built > >> > them as modules and they both work just fine, with the binary > >> firmware. > >> > What's involved in making KMS work on PPC? I'm sure I need the KMS > >> > helpers and the TTM module as well right? > >> > >> For r128, it could actually re-use a lot of the radeon KMS code, in > >> fact nearly all of it. > >> > >> Alex Deucher started doing a UMS merge of radeon/r128 at one point > >> http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support > >> > >> the main things would be adding the differences in the bios parsing, > >> and modesetting paths to KMS first. > > > > I'll start digging into the Radeon, see what I can learn about KMS > > integration. For now I'll build the r128 out of the tree, simplifies > > things a bit. Is that OK? > > > > Any further reading would be tremendously helpful. > > > > It should be pretty easy to get kms going with r128 by integrating it > into the radeon drm and ddx. The hard part will be porting the r128 > 3D driver to kms. Also, kms support for r128-based macs will be a bit > trickier than x86 because the boards don't have an x86 video bios. > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > driver for properly setting up the cards without an x86 bios. Let me > know if you have any questions. Whilst hacking on the drm and r128 sources out of the tree I noticed a peculiarity of the build process. It turns out that if you build the r128 module separately after working on it, and insmod both drm and r128 modules, it spits out a lot missing drm_* symbols. However, if I build both drm and r128 modules then insmod both modules, it doesn't spit out any missing drm_* symbols. I don't quite understand why this happens, but for now I just start the build in the drm directory instead. -- http://www.munted.org.uk One very high maintenance cat living here.
r127 w/ KMS on PPC?
On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > On Wed, Apr 21, 2010 at 6:26 PM, Alex Buell > wrote: > > On Thu, 2010-04-22 at 07:55 +1000, Dave Airlie wrote: > >> > I'd like to step up for that, it'd let me learn a lot. I have > >> already > >> > extracted the r128 and its DRI from the 2.6.32 kernel tree and built > >> > them as modules and they both work just fine, with the binary > >> firmware. > >> > What's involved in making KMS work on PPC? I'm sure I need the KMS > >> > helpers and the TTM module as well right? > >> > >> For r128, it could actually re-use a lot of the radeon KMS code, in > >> fact nearly all of it. > >> > >> Alex Deucher started doing a UMS merge of radeon/r128 at one point > >> http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support > >> > >> the main things would be adding the differences in the bios parsing, > >> and modesetting paths to KMS first. > > > > I'll start digging into the Radeon, see what I can learn about KMS > > integration. For now I'll build the r128 out of the tree, simplifies > > things a bit. Is that OK? > > > > Any further reading would be tremendously helpful. > > > > It should be pretty easy to get kms going with r128 by integrating it > into the radeon drm and ddx. The hard part will be porting the r128 > 3D driver to kms. Also, kms support for r128-based macs will be a bit > trickier than x86 because the boards don't have an x86 video bios. > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > driver for properly setting up the cards without an x86 bios. Let me > know if you have any questions. Also, I was wondering why these chipset specific _drm.h files are kept in include/drm/ i.e. r128_drm.h, radeon_drm.h and mga_drm.h instead of being within the drivers/gpu/drm/*/ directories? -- http://www.munted.org.uk One very high maintenance cat living here.
r127 w/ KMS on PPC?
On Thu, Apr 22, 2010 at 01:46:46PM +0100, Alex Buell wrote: > On Wed, 2010-04-21 at 20:38 -0400, Alex Deucher wrote: > > On Wed, Apr 21, 2010 at 6:26 PM, Alex Buell > > wrote: > > > On Thu, 2010-04-22 at 07:55 +1000, Dave Airlie wrote: > > >> > I'd like to step up for that, it'd let me learn a lot. I have > > >> already > > >> > extracted the r128 and its DRI from the 2.6.32 kernel tree and built > > >> > them as modules and they both work just fine, with the binary > > >> firmware. > > >> > What's involved in making KMS work on PPC? I'm sure I need the KMS > > >> > helpers and the TTM module as well right? > > >> > > >> For r128, it could actually re-use a lot of the radeon KMS code, in > > >> fact nearly all of it. > > >> > > >> Alex Deucher started doing a UMS merge of radeon/r128 at one point > > >> http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support > > >> > > >> the main things would be adding the differences in the bios parsing, > > >> and modesetting paths to KMS first. > > > > > > I'll start digging into the Radeon, see what I can learn about KMS > > > integration. For now I'll build the r128 out of the tree, simplifies > > > things a bit. Is that OK? > > > > > > Any further reading would be tremendously helpful. > > > > > > > It should be pretty easy to get kms going with r128 by integrating it > > into the radeon drm and ddx. The hard part will be porting the r128 > > 3D driver to kms. Also, kms support for r128-based macs will be a bit > > trickier than x86 because the boards don't have an x86 video bios. > > You may have to look at the xf86-video-r128 ddx and atyr128 kernel fb > > driver for properly setting up the cards without an x86 bios. Let me > > know if you have any questions. > > Also, I was wondering why these chipset specific _drm.h files are kept > in include/drm/ i.e. r128_drm.h, radeon_drm.h and mga_drm.h instead of > being within the drivers/gpu/drm/*/ directories? Because we install them along other kernel header file (ie they are included in kernel-header package of distribution) Maybe we should move non public header out of include/drm but i don't think it's really needed. Cheers, Jerome
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #2 from Luke-Jr 2010-04-22 06:56:17 PDT --- My uneducated guess is that radeonFlush is triggering a SIGSEGV and libSDL is trying to shutdown sanely as a result, which creates a loop since the radeonFlush is already in the shutdown procedure. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] agp: use scratch page on memory remove and at GATT creation V4
On Thu, Apr 22, 2010 at 6:30 AM, Jerome Glisse wrote: > On Thu, Apr 22, 2010 at 11:27:11AM +0200, Daniel Vetter wrote: >> On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote: >> > Convert most AGP chipset to use scratch page as default entries. >> > This help avoiding GPU querying 0 address and trigger computer >> > fault. With KMS and memory manager we bind/unbind AGP memory >> > constantly and it seems that some GPU are still doing AGP >> > traffic even after GPU report being idle with the memory segment. >> > >> > Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on : >> > - SIS 1039:0001 & 1039:0003 >> > - Intel 865 8086:2571 >> > >> > Compile tested for other bridges >> > >> > V2 enable scratch page on uninorth >> > V3 fix unbound check in uninorth insert memory (Michel D?nzer) >> > V4 rebase on top of drm-next branch with the lastest intel AGP >> > ? ?changeset (stable should use version V3 of the patch) >> >> Nope, v3 still contains the bogus changes to the intel gtt driver (only >> used by intel igds). In this patch, the intel parts look good. >> >> While looking add this I've found some more stuff to nit-pick over ;) >> Instead of splattering needs_scratch_page = true all over the agp drivers, >> why not do the changes in the agp core (and the few fixups required in the >> drivers) and simply kill this variable? If using a scratch page is >> required by upper layers (drm/radeon), then keeping around this "looks >> optional, but is very much a core requirement" thing lingering around is >> quite a call for trouble, IMHO. >> >> Yours, Daniel >> -- >> Daniel Vetter >> Mail: daniel at ffwll.ch >> Mobile: +41 (0)79 365 57 48 > > V4 is ok it apply on top of drm-next, and no i don't kill > needs_scratch_page because i don't want to touch Alpha AGP > code (i think it should die, i don't think alpha got AGP > hw we care about or even support). > > Cheers, > Jerome (Working) AGP is only available on high-end systems [1]. I've been working on Alpha things for two years now, and I've talked to only a single person with one of these systems, and he worked at HP at the time. I'd certainly like to keep these supported, in the case someone decides to donate one to me. :) If you want to have any changes against Alpha AGP checked, Ivan Kokshaysky is your guy. Matt [1] http://alphalinux.org/wiki/index.php/User:Mattst88/Alphas_with_AGP
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #3 from Michel D?nzer 2010-04-22 07:04:02 PDT --- Can you get another backtrace showing what signal it is, with debugging symbols for at least r300_dri.so? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786
--- Comment #4 from Luke-Jr 2010-04-22
07:29:08 PDT ---
Program received signal SIGSEGV, Segmentation fault.
0x71d2fd79 in radeonFlush (ctx=0xbe72e0) at radeon_common.c:1107
1107if ((ctx->DrawBuffer->Name == 0) && radeon->front_buffer_dirty)
{
(gdb) bt
#0 0x71d2fd79 in radeonFlush (ctx=0xbe72e0) at radeon_common.c:1107
#1 0x71d20ae5 in radeon_firevertices (radeon=0xbe0a60) at
radeon_cmdbuf.h:118
#2 0x71d20a10 in r300DeleteTexture (ctx=0xbe72e0, texObj=0x12404d0)
at r300_tex.c:262
#3 0x71de3559 in _mesa_reference_texobj (ptr=0xbf2930, tex=0x0)
at main/texobj.c:345
#4 0x71de8963 in _mesa_free_texture_data (ctx=0xbe72e0) at
main/texstate.c:788
#5 0x71d511c5 in _mesa_free_context_data (ctx=0xbe72e0) at
main/context.c:972
#6 0x71d5137c in _mesa_destroy_context (ctx=0xbe72e0) at
main/context.c:1028
#7 0x71d2c0d7 in radeonDestroyContext (driContextPriv=0xbd6450)
at radeon_common_context.c:328
#8 0x71cfcf1d in driDestroyContext (pcp=0xbd6450) at
../common/dri_util.c:546
#9 0x7703f8c6 in driDestroyContext (context=0xb83290, psc=0xbd5fc0,
dpy=0xa8ac10) at dri_glx.c:482
#10 0x77007810 in DestroyContext (dpy=0xa8ac10, gc=0xbe08b0) at
glxcmds.c:556
#11 0x770079b0 in glXDestroyContext (dpy=0xa8ac10, gc=0xbe08b0) at
glxcmds.c:592
#12 0x76b9df22 in ?? () from /usr/lib/libSDL-1.2.so.0
#13 0x76ba1cfe in ?? () from /usr/lib/libSDL-1.2.so.0
#14 0x76ba1f17 in ?? () from /usr/lib/libSDL-1.2.so.0
#15 0x76b92902 in SDL_VideoQuit () from /usr/lib/libSDL-1.2.so.0
#16 0x76b6c16d in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#17 0x0042a1e9 in main ()
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786
--- Comment #5 from Luke-Jr 2010-04-22
07:31:36 PDT ---
1107 if ((ctx->DrawBuffer->Name == 0) &&
radeon->front_buffer_dirty) {
- 0x7f3f1063ad6e :mov-0x28(%rbp),%rax
- 0x7f3f1063ad72 :mov0xf8(%rax),%rax
SEGV>- 0x7f3f1063ad79 :mov0x28(%rax),%eax
- 0x7f3f1063ad7c :test %eax,%eax
- 0x7f3f1063ad7e :jne0x7f3f1063ae25
- 0x7f3f1063ad84 :mov-0x18(%rbp),%rax
- 0x7f3f1063ad88 :movzbl 0x552(%rax),%eax
- 0x7f3f1063ad8f :test %al,%al
- 0x7f3f1063ad91 :je 0x7f3f1063ae25
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 --- Comment #6 from Luke-Jr 2010-04-22 07:36:00 PDT --- ctx->DrawBuffer is a NULL pointer -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27796] New: atombios stuck in loop
https://bugs.freedesktop.org/show_bug.cgi?id=27796
Summary: atombios stuck in loop
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: pjsanon at hotmail.com
Created an attachment (id=35239)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35239)
bios
I am having problems with lock up in X i loose all input devices
Switching back from the console, i see the following on the screen
atombios stuck in loop
I am using fedora and the version of Xorg is 1.8.0-7.
LSPCI
01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility
X1600] (prog-if 00 [VGA controller])
Subsystem: Apple Computer Inc. MacBook Pro
Flags: bus master, fast devsel, latency 0, IRQ 28
Memory at c000 (32-bit, prefetchable) [size=256M]
I/O ports at 3000 [size=256]
Memory at d830 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at d832 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: radeon
Kernel modules: radeon
EXTRACT FROM /var/log/messages
Apr 22 10:59:51 localhost kernel: INFO: task Xorg:1792 blocked for more than
120 seconds.
Apr 22 10:59:51 localhost kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 22 10:59:51 localhost kernel: Xorg D 3856 1792
1789 0x00400088
Apr 22 10:59:51 localhost kernel: 8800b06cdbc8 0046
8800b06cdb90 8800b06cdb8c
Apr 22 10:59:51 localhost kernel: 8800b06cdb38
1402 8800b06cdfd8
Apr 22 10:59:51 localhost kernel: 8800b06cdfd8 fb80
001d5e80 8800b072a888
Apr 22 10:59:51 localhost kernel: Call Trace:
Apr 22 10:59:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: []
__mutex_lock_common+0x24e/0x392
Apr 22 10:59:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: [] ?
lock_release_holdtime+0x34/0xe3
Apr 22 10:59:51 localhost kernel: []
mutex_lock_nested+0x3e/0x43
Apr 22 10:59:51 localhost kernel: []
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: [] ? might_fault+0x5c/0xac
Apr 22 10:59:51 localhost kernel: [] ? _lock_kernel+0x7d/0x95
Apr 22 10:59:51 localhost kernel: [] drm_ioctl+0x28f/0x373
[drm]
Apr 22 10:59:51 localhost kernel: [] ?
radeon_cs_ioctl+0x0/0x1a1 [radeon]
Apr 22 10:59:51 localhost kernel: [] ?
sched_clock_local+0x1c/0x82
Apr 22 10:59:51 localhost kernel: [] ?
do_setitimer+0x1b1/0x1e2
Apr 22 10:59:51 localhost kernel: [] ?
sched_clock_cpu+0xc3/0xce
Apr 22 10:59:51 localhost kernel: [] ?
trace_hardirqs_off+0xd/0xf
Apr 22 10:59:51 localhost kernel: [] vfs_ioctl+0x32/0xa6
Apr 22 10:59:51 localhost kernel: [] do_vfs_ioctl+0x490/0x4d6
Apr 22 10:59:51 localhost kernel: [] sys_ioctl+0x56/0x79
Apr 22 10:59:51 localhost kernel: []
system_call_fastpath+0x16/0x1b
Apr 22 10:59:51 localhost kernel: 1 lock held by Xorg/1792:
Apr 22 10:59:51 localhost kernel: #0: (&rdev->cs_mutex){+.+.+.}, at:
[] radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: INFO: task Xorg:1792 blocked for more than
120 seconds.
Apr 22 11:01:51 localhost kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 22 11:01:51 localhost kernel: Xorg D 3856 1792
1789 0x00400088
Apr 22 11:01:51 localhost kernel: 8800b06cdbc8 0046
8800b06cdb90 8800b06cdb8c
Apr 22 11:01:51 localhost kernel: 8800b06cdb38
1402 8800b06cdfd8
Apr 22 11:01:51 localhost kernel: 8800b06cdfd8 fb80
001d5e80 8800b072a888
Apr 22 11:01:51 localhost kernel: Call Trace:
Apr 22 11:01:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: []
__mutex_lock_common+0x24e/0x392
Apr 22 11:01:51 localhost kernel: [] ?
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: [] ?
lock_release_holdtime+0x34/0xe3
Apr 22 11:01:51 localhost kernel: []
mutex_lock_nested+0x3e/0x43
Apr 22 11:01:51 localhost kernel: []
radeon_cs_ioctl+0x37/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: [] ? might_fault+0x5c/0xac
Apr 22 11:01:51 localhost kernel: [] ? _lock_kernel+0x7d/0x95
Apr 22 11:01:51 localhost kernel: [] drm_ioctl+0x28f/0x373
[drm]
Apr 22 11:01:51 localhost kernel: [] ?
radeon_cs_ioctl+0x0/0x1a1 [radeon]
Apr 22 11:01:51 localhost kernel: [] ?
sched_clock_local+0x1c/0x82
Apr 22 11:01:51 localhost kernel: [] ?
do_setitimer+0x1b1/0x1e2
Apr 22 11:01:51 localhost kernel: [] ?
sched_clock_cpu+0xc3/0xce
Apr 22 11:01:51 localhos
[Bug 27786] Freeze if boss-key (Shift-Esc) pressed while busy doing network stuff and game engine not running
https://bugs.freedesktop.org/show_bug.cgi?id=27786 Luke-Jr changed: What|Removed |Added See Also||http://bugzilla.libsdl.org/ ||show_bug.cgi?id=991 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon: 9800 SE has only one quadpipe
[PATCH] drm/radeon: 9800 SE has only one quadpipe
Although these cards have 2 pipelines on the silicon only
the first passed the QA and the other should be disabled.
http://www.digital-daily.com/video/ati-radeon9800se/
http://www.rojakpot.com/showarticle.aspx?artno=101&pgno=1
agd5f: add some other SE cards as well; fix up kms
Signed-off-by: Tormod Volden
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r300.c |5 ++---
drivers/gpu/drm/radeon/r420.c |6 ++
drivers/gpu/drm/radeon/radeon_cp.c |9 +++--
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index bb005bf..590f6a8 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -328,13 +328,12 @@ void r300_gpu_init(struct radeon_device *rdev)
{
uint32_t gb_tile_config, tmp;
- /* FIXME: rv380 one pipes ? */
if ((rdev->family == CHIP_R300 && rdev->pdev->device != 0x4144) ||
- (rdev->family == CHIP_R350)) {
+ (rdev->family == CHIP_R350 && rdev->pdev->device != 0x4148)) {
/* r300,r350 */
rdev->num_gb_pipes = 2;
} else {
- /* rv350,rv370,rv380,r300 AD */
+ /* rv350,rv370,rv380,r300 AD, r350 AH */
rdev->num_gb_pipes = 1;
}
rdev->num_z_pipes = 1;
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 3759d83..be092d2 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -59,6 +59,12 @@ void r420_pipes_init(struct radeon_device *rdev)
/* get max number of pipes */
gb_pipe_select = RREG32(0x402C);
num_pipes = ((gb_pipe_select >> 12) & 3) + 1;
+
+ /* SE chips have 1 pipe */
+ if ((rdev->pdev->device == 0x5e4c) ||
+ (rdev->pdev->device == 0x5e4f))
+ num_pipes = 1;
+
rdev->num_gb_pipes = num_pipes;
tmp = 0;
switch (num_pipes) {
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 419630d..2f042a3 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -435,14 +435,19 @@ static void radeon_init_pipes(struct drm_device *dev)
if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R420) {
gb_pipe_sel = RADEON_READ(R400_GB_PIPE_SELECT);
dev_priv->num_gb_pipes = ((gb_pipe_sel >> 12) & 0x3) + 1;
+ /* SE cards have 1 pipe */
+ if ((dev->pdev->device == 0x5e4c) ||
+ (dev->pdev->device == 0x5e4f))
+ dev_priv->num_gb_pipes = 1;
} else {
/* R3xx */
if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R300 &&
dev->pdev->device != 0x4144) ||
- ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R350)) {
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_R350 &&
+dev->pdev->device != 0x4148)) {
dev_priv->num_gb_pipes = 2;
} else {
- /* RV3xx/R300 AD */
+ /* RV3xx/R300 AD/R350 AH */
dev_priv->num_gb_pipes = 1;
}
}
--
1.5.6.3
--001485f27f9461f19a0484d99a55
Content-Type: text/plain; charset=US-ASCII;
name="0001-drm-radeon-9800-SE-has-only-one-quadpipe.patch"
Content-Disposition: attachment;
filename="0001-drm-radeon-9800-SE-has-only-one-quadpipe.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g8c240j70
RnJvbSAzODZkYjM5YWRiMzRlMGM1ZWExY2EzYTAzNDEwNjJiZWQxNzdlM2NkIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUb3Jtb2QgVm9sZGVuIDxkZWJpYW4udG9ybW9kQGdtYWlsLmNv
bT4KRGF0ZTogVGh1LCAyMiBBcHIgMjAxMCAxNjo1NzozMiAtMDQwMApTdWJqZWN0OiBbUEFUQ0hd
IGRybS9yYWRlb246IDk4MDAgU0UgaGFzIG9ubHkgb25lIHF1YWRwaXBlCgpBbHRob3VnaCB0aGVz
ZSBjYXJkcyBoYXZlIDIgcGlwZWxpbmVzIG9uIHRoZSBzaWxpY29uIG9ubHkKdGhlIGZpcnN0IHBh
c3NlZCB0aGUgUUEgYW5kIHRoZSBvdGhlciBzaG91bGQgYmUgZGlzYWJsZWQuCgpodHRwOi8vd3d3
LmRpZ2l0YWwtZGFpbHkuY29tL3ZpZGVvL2F0aS1yYWRlb245ODAwc2UvCmh0dHA6Ly93d3cucm9q
YWtwb3QuY29tL3Nob3dhcnRpY2xlLmFzcHg/YXJ0bm89MTAxJnBnbm89MQoKYWdkNWY6IGFkZCBz
b21lIG90aGVyIFNFIGNhcmRzIGFzIHdlbGw7IGZpeCB1cCBrbXMKClNpZ25lZC1vZmYtYnk6IFRv
cm1vZCBWb2xkZW4gPGRlYmlhbi50b3Jtb2RAZ21haWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBBbGV4
IERldWNoZXIgPGFsZXhkZXVjaGVyQGdtYWlsLmNvbT4KLS0tCiBkcml2ZXJzL2dwdS9kcm0vcmFk
ZW9uL3IzMDAuYyAgICAgIHwgICAgNSArKy0tLQogZHJpdmVycy9ncHUvZHJtL3JhZGVvbi9yNDIw
LmMgICAgICB8ICAgIDYgKysrKysrCiBkcml2ZXJzL2dwdS9kcm0vcmFkZW9uL3JhZGVvbl9jcC5j
IHwgICAgOSArKysrKysrLS0KIDMgZmlsZXMgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgNSBk
ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vcmFkZW9uL3IzMDAuYyBi
L2RyaXZlcnMvZ3B1L2RybS9yYWRlb24vcjMwMC5jCmluZGV4IGJiMDA1YmYuLjU5MGY2YTggMTAw
NjQ0Ci0tLSBhL2RyaXZlcnMvZ3B1L2RybS9yYWRlb24vcjMwMC5jCisrKyBiL2RyaXZlcnMvZ3B1
L2RybS9yYWRlb24vcjMwMC5jCkBAIC0zMjgsMTMgKzMyOCwxMiBAQCB2b2lkIHIzMDBfZ3B1X2lu
aXQoc3RydWN0
[Bug 27739] build in a separate directory includes config.h from source directory
https://bugs.freedesktop.org/show_bug.cgi?id=27739 Kristian H?gsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Kristian H?gsberg 2010-04-22 17:01:31 PDT --- What you're doing is not supported. I get configure: error: source directory already configured; run "make distclean" there first when I try to configure in a build-dir with an already configured source dir. Doing make distclean removes the config.h in the source dir. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms/evergreen: fix LUT setup
[PATCH] drm/radeon/kms/evergreen: fix LUT setup
Must have gotten broken during an earlier rebase.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 243c1c4..ce5163e 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -86,12 +86,12 @@ static void evergreen_crtc_load_lut(struct drm_crtc *crtc)
WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_GREEN +
radeon_crtc->crtc_offset, 0x);
WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_RED + radeon_crtc->crtc_offset,
0x);
- WREG32(EVERGREEN_DC_LUT_RW_MODE, radeon_crtc->crtc_id);
- WREG32(EVERGREEN_DC_LUT_WRITE_EN_MASK, 0x0007);
+ WREG32(EVERGREEN_DC_LUT_RW_MODE + radeon_crtc->crtc_offset, 0);
+ WREG32(EVERGREEN_DC_LUT_WRITE_EN_MASK + radeon_crtc->crtc_offset,
0x0007);
- WREG32(EVERGREEN_DC_LUT_RW_INDEX, 0);
+ WREG32(EVERGREEN_DC_LUT_RW_INDEX + radeon_crtc->crtc_offset, 0);
for (i = 0; i < 256; i++) {
- WREG32(EVERGREEN_DC_LUT_30_COLOR,
+ WREG32(EVERGREEN_DC_LUT_30_COLOR + radeon_crtc->crtc_offset,
(radeon_crtc->lut_r[i] << 20) |
(radeon_crtc->lut_g[i] << 10) |
(radeon_crtc->lut_b[i] << 0));
--
1.5.6.3
--0016e6567d7eebf3250484deaa8c
Content-Type: text/plain; charset=US-ASCII;
name="0001-drm-radeon-kms-evergreen-fix-LUT-setup.patch"
Content-Disposition: attachment;
filename="0001-drm-radeon-kms-evergreen-fix-LUT-setup.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g8cf23770
RnJvbSA1MDM4MzgwYjM3YWZlNmQ3OTYxMmE1NjY1ZDQ2ZDU0MDg2ODEyNDk2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGV4IERldWNoZXIgPGFsZXhkZXVjaGVyQGdtYWlsLmNvbT4K
RGF0ZTogVGh1LCAyMiBBcHIgMjAxMCAyMjo1ODo1MCAtMDQwMApTdWJqZWN0OiBbUEFUQ0hdIGRy
bS9yYWRlb24va21zL2V2ZXJncmVlbjogZml4IExVVCBzZXR1cAoKTXVzdCBoYXZlIGdvdHRlbiBi
cm9rZW4gZHVyaW5nIGFuIGVhcmxpZXIgcmViYXNlLgoKU2lnbmVkLW9mZi1ieTogQWxleCBEZXVj
aGVyIDxhbGV4ZGV1Y2hlckBnbWFpbC5jb20+Ci0tLQogZHJpdmVycy9ncHUvZHJtL3JhZGVvbi9y
YWRlb25fZGlzcGxheS5jIHwgICAgOCArKysrLS0tLQogMSBmaWxlcyBjaGFuZ2VkLCA0IGluc2Vy
dGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL3Jh
ZGVvbi9yYWRlb25fZGlzcGxheS5jIGIvZHJpdmVycy9ncHUvZHJtL3JhZGVvbi9yYWRlb25fZGlz
cGxheS5jCmluZGV4IDI0M2MxYzQuLmNlNTE2M2UgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvZ3B1L2Ry
bS9yYWRlb24vcmFkZW9uX2Rpc3BsYXkuYworKysgYi9kcml2ZXJzL2dwdS9kcm0vcmFkZW9uL3Jh
ZGVvbl9kaXNwbGF5LmMKQEAgLTg2LDEyICs4NiwxMiBAQCBzdGF0aWMgdm9pZCBldmVyZ3JlZW5f
Y3J0Y19sb2FkX2x1dChzdHJ1Y3QgZHJtX2NydGMgKmNydGMpCiAJV1JFRzMyKEVWRVJHUkVFTl9E
Q19MVVRfV0hJVEVfT0ZGU0VUX0dSRUVOICsgcmFkZW9uX2NydGMtPmNydGNfb2Zmc2V0LCAweGZm
ZmYpOwogCVdSRUczMihFVkVSR1JFRU5fRENfTFVUX1dISVRFX09GRlNFVF9SRUQgKyByYWRlb25f
Y3J0Yy0+Y3J0Y19vZmZzZXQsIDB4ZmZmZik7CiAKLQlXUkVHMzIoRVZFUkdSRUVOX0RDX0xVVF9S
V19NT0RFLCByYWRlb25fY3J0Yy0+Y3J0Y19pZCk7Ci0JV1JFRzMyKEVWRVJHUkVFTl9EQ19MVVRf
V1JJVEVfRU5fTUFTSywgMHgwMDAwMDAwNyk7CisJV1JFRzMyKEVWRVJHUkVFTl9EQ19MVVRfUldf
TU9ERSArIHJhZGVvbl9jcnRjLT5jcnRjX29mZnNldCwgMCk7CisJV1JFRzMyKEVWRVJHUkVFTl9E
Q19MVVRfV1JJVEVfRU5fTUFTSyArIHJhZGVvbl9jcnRjLT5jcnRjX29mZnNldCwgMHgwMDAwMDAw
Nyk7CiAKLQlXUkVHMzIoRVZFUkdSRUVOX0RDX0xVVF9SV19JTkRFWCwgMCk7CisJV1JFRzMyKEVW
RVJHUkVFTl9EQ19MVVRfUldfSU5ERVggKyByYWRlb25fY3J0Yy0+Y3J0Y19vZmZzZXQsIDApOwog
CWZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykgewotCQlXUkVHMzIoRVZFUkdSRUVOX0RDX0xVVF8z
MF9DT0xPUiwKKwkJV1JFRzMyKEVWRVJHUkVFTl9EQ19MVVRfMzBfQ09MT1IgKyByYWRlb25fY3J0
Yy0+Y3J0Y19vZmZzZXQsCiAJCSAgICAgICAocmFkZW9uX2NydGMtPmx1dF9yW2ldIDw8IDIwKSB8
CiAJCSAgICAgICAocmFkZW9uX2NydGMtPmx1dF9nW2ldIDw8IDEwKSB8CiAJCSAgICAgICAocmFk
ZW9uX2NydGMtPmx1dF9iW2ldIDw8IDApKTsKLS0gCjEuNS42LjMKCg==
--0016e6567d7eebf3250484deaa8c--
