From: Andrew B. <bar...@os...> - 2004-07-30 02:14:21
|
I just bought a Radeon 7000 video card on-line. What is the status of and plans for power management support for this card? I read Documentation/power/video.txt, and it says that I can't have framebuffer console. That could be a problem as I use bootsplash. It also says I need a patched X server. My Google search turned up a page concerning S3/Radeon that says the patch is no longer necessary (I can't find the URL at the moment, sorry). Any thoughts, tips, tricks, etc. would be greatly appreciated. Regards, Andrew Barr |
From: Micha F. <mi...@po...> - 2004-07-30 14:10:29
|
On Thu, Jul 29, 2004 at 10:14:00PM +0000, Andrew Barr wrote: > I just bought a Radeon 7000 video card on-line. What is the status of > and plans for power management support for this card? I read > Documentation/power/video.txt, and it says that I can't have framebuffer > console. That could be a problem as I use bootsplash. It also says I > need a patched X server. My Google search turned up a page concerning > S3/Radeon that says the patch is no longer necessary (I can't find the > URL at the moment, sorry). Any thoughts, tips, tricks, etc. would be > greatly appreciated. > I am not sure about the current state of things. AFAIK the problem was with dri suspend support for radeon, and at the time at least, the card was reset on VT switch to enable suspend. IIRC the patch was incorporated into main the main tree quite some time ago. I have no experience with S3 suspend (my laptop doesn't seem to support it) but it does suspend with swsusp2 if I switch VT. > Regards, > Andrew Barr > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Acpi-devel mailing list > Acp...@li... > https://lists.sourceforge.net/lists/listinfo/acpi-devel > > +++++++++++++++++++++++++++++++++++++++++++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > |
From: wwp <sub...@fr...> - 2004-07-30 14:28:52
|
Hello Micha, On Fri, 30 Jul 2004 17:10:28 +0300 Micha Feigin <mi...@po...> wrote: [snip] > I am not sure about the current state of things. AFAIK the problem was > with dri suspend support for radeon, and at the time at least, the card > was reset on VT switch to enable suspend. IIRC the patch was > incorporated into main the main tree quite some time ago. > > I have no experience with S3 suspend (my laptop doesn't seem to support > it) but it does suspend with swsusp2 if I switch VT. I m just curious: do you switch to VT or do you close X and return to console (or even do `init 2`)? Regards, -- wwp |
From: Micha F. <mi...@po...> - 2004-07-30 19:00:13
|
On Fri, Jul 30, 2004 at 04:27:56PM +0200, wwp wrote: > Hello Micha, > > > On Fri, 30 Jul 2004 17:10:28 +0300 Micha Feigin <mi...@po...> wrote: > > [snip] > > I am not sure about the current state of things. AFAIK the problem was > > with dri suspend support for radeon, and at the time at least, the card > > was reset on VT switch to enable suspend. IIRC the patch was > > incorporated into main the main tree quite some time ago. > > > > I have no experience with S3 suspend (my laptop doesn't seem to support > > it) but it does suspend with swsusp2 if I switch VT. > > I m just curious: do you switch to VT or do you close X and return to console > (or even do `init 2`)? > I have a script that basically does VT=`fgconsole` chvt 9 echo 4 > /proc/acpi/sleep (or whatever sleep command you use) chvt $VT This changes to a console terminal before suspend, suspends, and on resume switches back to X. This will also reset the card properly. Its actually a mach64 and not a radeon, but I ported the relevant portions of the radeon dri driver PM to the mach64. Note though that mach64 needs no kernel PM support, its all done on the X side (didn't find out yet how to do it on the kernel side, although I hope to do that when I have them time, that would save the VT switch). > > Regards, > > -- > wwp > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Acpi-devel mailing list > Acp...@li... > https://lists.sourceforge.net/lists/listinfo/acpi-devel > > +++++++++++++++++++++++++++++++++++++++++++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > |
From: Andrew B. <bar...@os...> - 2004-08-03 23:10:13
|
My card came in the mail today...it works fine except for...(you guessed it) S3 suspend with a framebuffer. The card never re-initializes (even with acpi_sleep=s3_bios) and the monitor never powers back up. I can do swsusp2, which is okay for now, but I guess my question at this point is this: does anyone know what is keeping this card from working right with a framebuffer over S3? More to the point, it is something that could be fixed? Given how far the ACPI code has come in 2.6, I would certainly hope something is possible. Andrew P.S. In case you're wondering, yes, I'm a bit of a perfectionist. ;) |
From: Erik T. <er...@de...> - 2004-08-03 23:30:07
|
Am Di, den 03.08.2004 schrieb Andrew Barr um 21:10: > My card came in the mail today...it works fine except for...(you guessed > it) S3 suspend with a framebuffer. The card never re-initializes (even > with acpi_sleep=s3_bios) and the monitor never powers back up. I can do > swsusp2, which is okay for now, but I guess my question at this point is > this: does anyone know what is keeping this card from working right with > a framebuffer over S3? More to the point, it is something that could be > fixed? Given how far the ACPI code has come in 2.6, I would certainly > hope something is possible. > > Andrew > > P.S. In case you're wondering, yes, I'm a bit of a perfectionist. ;) Well, I got a radeon 9600 too, and it never comes back too. I did not try swsuspend or any special parameters. If you find a solution, please tell me. I heard that somebody has a t41p running with acpi, but I could't get my system working with acpi here. |
From: Nathan B. <nb...@op...> - 2004-08-04 01:18:22
|
Andrew Barr wrote: >My card came in the mail today...it works fine except for...(you guessed >it) S3 suspend with a framebuffer. The card never re-initializes (even >with acpi_sleep=s3_bios) and the monitor never powers back up. I can do >swsusp2, which is okay for now, but I guess my question at this point is >this: does anyone know what is keeping this card from working right with >a framebuffer over S3? More to the point, it is something that could be >fixed? Given how far the ACPI code has come in 2.6, I would certainly >hope something is possible. > > The problem is in the graphics driver. Unfortunately graphics drivers are a bit of a mess on linux: there are multiple drivers that all may think they "own" the device. There are non-DRI X drivers that don't incorporate any kernel functionality, DRI-based drivers that do include kernel components, the text console driver (which knows nothing about specific hardware), the framebuffer drivers... one or all of those drivers needs to be taught how to resume the card, and if more than one driver is running at once, they need to coordinate resume functionality amongst themselves. Good luck getting the drivers talking amongt one another if one of them is not open source... Also there are issues with AGPGART not knowing how to resume certain AGP bus chipsets. >P.S. In case you're wondering, yes, I'm a bit of a perfectionist. ;) > > Sounds like we have a volunteer to clean up the whole mess :-) |
From: Erik T. <er...@de...> - 2004-08-04 01:40:16
|
Am Mi, den 04.08.2004 schrieb Nathan Bryant um 3:18: > The problem is in the graphics driver. Unfortunately graphics drivers > are a bit of a mess on linux: there are multiple drivers that all may > think they "own" the device. There are non-DRI X drivers that don't > incorporate any kernel functionality, DRI-based drivers that do include > kernel components, the text console driver (which knows nothing about > specific hardware), the framebuffer drivers... one or all of those > drivers needs to be taught how to resume the card, and if more than one > driver is running at once, they need to coordinate resume functionality > amongst themselves. > > Good luck getting the drivers talking amongt one another if one of them > is not open source... > > Also there are issues with AGPGART not knowing how to resume certain AGP > bus chipsets. Well, if somebody would have a configuration, like add this framebuffer-support, drop this dri-driver, then it works, it would be enough for me. |
From: Len B. <len...@in...> - 2004-08-04 03:41:12
|
Some folks have had good luck getting Radeon to resume after applying this patch. I saw it fix a Dell 600m/Radeon. http://lists.debian.org/debian-x/2004/03/msg03482.html cheers, -Len |
From: <ole...@ce...> - 2004-08-04 06:47:05
|
Len> Some folks have had good luck getting Radeon to resume Len> after applying this patch. I saw it fix a Dell 600m/Radeon. Len> http://lists.debian.org/debian-x/2004/03/msg03482.html The same folks were even happier with a more recent patch that moves the S3 resume POST where really belongs: into kernel space: <http://article.gmane.org/gmane.linux.acpi.devel/8879> Ole |
From: wwp <sub...@fr...> - 2004-08-04 07:18:08
|
Hello ole...@ce..., On 04 Aug 2004 08:43:58 +0200 ole...@ce... wrote: > Len> Some folks have had good luck getting Radeon to resume > Len> after applying this patch. I saw it fix a Dell 600m/Radeon. > > Len> http://lists.debian.org/debian-x/2004/03/msg03482.html > > The same folks were even happier with a more recent patch that moves > the S3 resume POST where really belongs: into kernel space: > > <http://article.gmane.org/gmane.linux.acpi.devel/8879> Is there a possible equivalent to 2.4 kernels (if only it is relevant)? Regards, -- wwp |
From: Ow M. H. <Ow....@wd...> - 2004-08-04 07:28:50
|
On Tue, 2004-08-03 at 23:43, ole...@ce... wrote: > Len> Some folks have had good luck getting Radeon to resume > Len> after applying this patch. I saw it fix a Dell 600m/Radeon. > > Len> http://lists.debian.org/debian-x/2004/03/msg03482.html > > The same folks were even happier with a more recent patch that moves > the S3 resume POST where really belongs: into kernel space: > > <http://article.gmane.org/gmane.linux.acpi.devel/8879> I've got to try this out. I have a D600 running on FC2. S4 works great.. S3.. not so. When I have time... Sigh.. interesting info though.. Thanks -- Ow Mun Heng Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel 2.6.7-2.jul1-interactive Neuromancer 00:16:43 up 11:31, 5 users, load average: 0.69, 0.66, 0.61 |
From: Len B. <len...@in...> - 2004-08-04 14:54:15
|
On Wed, 2004-08-04 at 02:43, ole...@ce... wrote: > Len> Some folks have had good luck getting Radeon to resume > Len> after applying this patch. I saw it fix a Dell 600m/Radeon. > > Len> http://lists.debian.org/debian-x/2004/03/msg03482.html > > The same folks were even happier with a more recent patch that moves > the S3 resume POST where really belongs: into kernel space: > > <http://article.gmane.org/gmane.linux.acpi.devel/8879> Thanks Ole, for pointing that out. I too would prefer a kernel-based solution that applies to all video adapters. I would like a solution that applies to x86_64 in addition to i386. I saw the note about this patch fixing the dell 600m with the Radeon 9000. I haven't yet seen reports of it fixing other system's video on S3 resume, including the Radeon 7000 that is the subject of this thread. Can you summarize the feedback you've got so far? Can you re-post the cleaned up patch? Maybe good to go to lkml with it for broader review and feedback. thanks, -Len |
From: <co...@lo...> - 2004-08-04 17:45:01
|
This S3 resume POST patch has to go into the official ACPI/kernel source, just has to. POST'ing the video adapter on resume is absolutely fundamental. That some older non-Radeon cards can do without and we've gone this long without it is just amazing coincidence. This should go in right away, anything is better than nothing. -Huw > On Wed, 2004-08-04 at 02:43, ole...@ce... wrote: >> Len> Some folks have had good luck getting Radeon to resume >> Len> after applying this patch. I saw it fix a Dell 600m/Radeon. >> >> Len> http://lists.debian.org/debian-x/2004/03/msg03482.html >> >> The same folks were even happier with a more recent patch that moves >> the S3 resume POST where really belongs: into kernel space: >> >> <http://article.gmane.org/gmane.linux.acpi.devel/8879> > > Thanks Ole, for pointing that out. > I too would prefer a kernel-based solution that > applies to all video adapters. I would > like a solution that applies to x86_64 > in addition to i386. > > I saw the note about this patch fixing the dell 600m > with the Radeon 9000. I haven't yet seen reports of it > fixing other system's video on S3 resume, including > the Radeon 7000 that is the subject of this thread. > Can you summarize the feedback you've got so far? > > Can you re-post the cleaned up patch? > Maybe good to go to lkml with it for broader review > and feedback. > > thanks, > -Len > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source > Technology Group. Come see the changes on the new OSTG site. > www.ostg.com > _______________________________________________ > Acpi-devel mailing list > Acp...@li... > https://lists.sourceforge.net/lists/listinfo/acpi-devel |
From: Nathan B. <nb...@op...> - 2004-08-04 17:48:46
|
co...@lo... wrote: > This S3 resume POST patch has to go into the official ACPI/kernel > source, just has to. POST'ing the video adapter on resume is > absolutely fundamental. That some older non-Radeon cards can > do without and we've gone this long without it is just amazing > coincidence. This should go in right away, anything is better > than nothing. -Huw Huh? acpi_sleep=s3_bios is in the mainline. |
From: <co...@lo...> - 2004-08-04 18:23:21
|
> co...@lo... wrote: >> This S3 resume POST patch has to go into the official ACPI/kernel >> source, just has to. POST'ing the video adapter on resume is >> absolutely fundamental. That some older non-Radeon cards can >> do without and we've gone this long without it is just amazing >> coincidence. This should go in right away, anything is better >> than nothing. -Huw > > Huh? acpi_sleep=s3_bios is in the mainline. It doesn't work, and it never has except in serendipitous circumstances. It happens at the wrong time, with interrupts in completely the wrong state. If it ever worked for anyone, it's a miracle that should not be regarded as a reason to perpetuate it. Let's get rid of it and replace it with the right solution - this more recent patch. -Huw |
From: Eric V. <eri...@fr...> - 2004-08-04 18:36:01
|
co...@lo... wrote: >>co...@lo... wrote: >> >>>This S3 resume POST patch has to go into the official ACPI/kernel >>>source, just has to. POST'ing the video adapter on resume is >>>absolutely fundamental. That some older non-Radeon cards can >>>do without and we've gone this long without it is just amazing >>>coincidence. This should go in right away, anything is better >>>than nothing. -Huw >> >>Huh? acpi_sleep=s3_bios is in the mainline. > > > It doesn't work, and it never has except in serendipitous > circumstances. It happens at the wrong time, with interrupts > in completely the wrong state. If it ever worked for anyone, > it's a miracle that should not be regarded as a reason to > perpetuate it. Let's get rid of it and replace it with the > right solution - this more recent patch. -Huw At least is works for me (radeon 7500, Ausus L3800C). Note that I would be glad not to rely on the BIOS but I think your wording is a little bit strong... -- eric |
From: <ole...@ce...> - 2004-08-06 06:16:40
|
Len> I would like a solution that applies to x86_64 in addition to Len> i386. What would it take? I know absolutely nothing about that architecture. From arch/x86_64/kernel/acpi/wakeup.S it seems to support some form of real mode, so could it do the return to real mode just like i386? Len> Can you summarize the feedback you've got so far? Failures and success: ===================== One failure report (Stefan), that's the Radeon 7000 failure you're referring to. It's an AGP system, I'm anxious to know if adding the bus number helps. Two success reports, both with Dell d660/Radeon 9000. My own machine is a Fujitsu P2120/Radeon Mobility M6 LY. Len> Can you re-post the cleaned up patch? It's on my todo list:-) Len> Maybe good to go to lkml with it for broader review and feedback. "lkml" - is that the linux kernel mailing list? I'm not a seasoned kernel patch provider. Ole |
From: Andi K. <ak...@su...> - 2004-08-06 13:58:38
|
On Fri, Aug 06, 2004 at 08:13:25AM +0200, ole...@ce... wrote: > Len> I would like a solution that applies to x86_64 in addition to > Len> i386. > > What would it take? > > I know absolutely nothing about that architecture. From > arch/x86_64/kernel/acpi/wakeup.S it seems to support some form of real > mode, so could it do the return to real mode just like i386? x86-64 S3 wakeups works exactly the same as i386, it just switches to long mode instead of 32bit mode. x86-64 has real mode too (it is a fully compatible PC with an additional 64bit long mode) The code is slightly different for historical reasons, but if you have real mode POST code you can probably just insert it into the real mode part of the x86-64 S3 wakeup. -Andi |
From: Pavel M. <pa...@uc...> - 2004-08-11 19:46:31
|
Hi! > Len> I would like a solution that applies to x86_64 in addition to > Len> i386. > > What would it take? Len, you can't expect ole to write x86-64 support without testing. Patch should be designed so that it does no damage on non-i386, but you should not expect more. It would be nice if i386 version could be merged. I'll probably do x86-64 in future; stable i386 version would certainly help me. > I know absolutely nothing about that architecture. From > arch/x86_64/kernel/acpi/wakeup.S it seems to support some form of real > mode, so could it do the return to real mode just like i386? Yes. > "lkml" - is that the linux kernel mailing list? Yes. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms |
From: Andrew B. <bar...@os...> - 2004-07-30 17:31:32
|
On Fri, 2004-07-30 at 14:10, Micha Feigin wrote: [...] > I am not sure about the current state of things. AFAIK the problem was > with dri suspend support for radeon, and at the time at least, the card > was reset on VT switch to enable suspend. IIRC the patch was > incorporated into main the main tree quite some time ago. > > I have no experience with S3 suspend (my laptop doesn't seem to support > it) but it does suspend with swsusp2 if I switch VT. Thanks to everyone for their responses. I won't be able to try anything out for a week or so because the card is in the mail still, but this gives me a good idea of what to expect when I do get it. Thanks again. Andrew |
From: Ow M. H. <Ow....@wd...> - 2004-08-06 20:14:22
|
On Fri, 2004-07-30 at 07:10, Micha Feigin wrote: > On Thu, Jul 29, 2004 at 10:14:00PM +0000, Andrew Barr wrote: > > I just bought a Radeon 7000 video card on-line. What is the status of > > and plans for power management support for this card? I read > > I am not sure about the current state of things. AFAIK the problem was > with dri suspend support for radeon, and at the time at least, the card > was reset on VT switch to enable suspend. IIRC the patch was > incorporated into main the main tree quite some time ago. I think this problem must be 2fold. 1. The Bios implementation 2. the X server Why? Cause by experience on my D600 system running RH9 and now FC2, it's been better and better. On RH9, 2.4 kernel, I had to switch to virtual terminal before I get back my display. No 3D/dri support Rh9 2.6 kernel, no need to switch to VT. Still no 3D. Fc2 2.6 kernel. No need for VT and There's DRI/3d (Tux racer works Great/fast) But I keep complaining because I can't run America's Army and Unreal Tournament etc. > > I have no experience with S3 suspend (my laptop doesn't seem to support > it) but it does suspend with swsusp2 if I switch VT. S3 is a different beast. I believe it's the code implementation. I heard that FreeBSD users seems to be able to get it working. Linux Users are getting there too. (Debian) and what I've heard but not understood is the Need for POSTing the VGA card. S4 works for Me. S3 Nope. > > Regards, > > Andrew Barr > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > > one more big change to announce. We are now OSTG- Open Source Technology > > Group. Come see the changes on the new OSTG site. www.ostg.com > > _______________________________________________ > > Acpi-devel mailing list > > Acp...@li... > > https://lists.sourceforge.net/lists/listinfo/acpi-devel > > > > +++++++++++++++++++++++++++++++++++++++++++ > > This Mail Was Scanned By Mail-seCure System > > at the Tel-Aviv University CC. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Acpi-devel mailing list > Acp...@li... > https://lists.sourceforge.net/lists/listinfo/acpi-devel -- Ow Mun Heng Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel 2.6.7-2.jul1-interactive Neuromancer 13:05:47 up 4:24, 6 users, load average: 2.36, 1.96, 2.44 |
From: Stefan <ste...@gm...> - 2004-08-04 19:03:23
|
Am Mittwoch, 4. August 2004 19:44 schrieb co...@lo...: > This S3 resume POST patch has to go into the official ACPI/kernel > source, just has to. POST'ing the video adapter on resume is > absolutely fundamental. That some older non-Radeon cards can > do without and we've gone this long without it is just amazing > coincidence. This should go in right away, anything is better > than nothing. -Huw I think this patch only works for radeon cards, and not in all circumstances. It doesn't work for me(ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000] (rev 01)). Strangely, user mode based VGA rom post works. I am allready trying to debug this with Ole, but it seems that he's on holyday. Any ideas? There is some resume code in drivers/video/aty/radeon_pm.c written by ATI, but it's only compiled on PowerMac and is only tested for <=R200 and S2. I tried to activate it(remove arch and model checking), but it only made my display flash a few times. Perhaps we should ask ATI for help. Stefan |
From: <ole...@ce...> - 2004-08-05 07:38:49
|
Stefan> I think this patch only works for radeon cards, I'd rather say it is perhaps only reported to be needed for Radeon cards, VGA POST'ing as such is of course not chipset specific. I'd maintain that ACPI makes no promise that the graphics chipset is reinitialized on S3 resume. So if an adapter "just works", it is either because the device hasn't been completely powered down (Dn, n<3?) or because the system BIOS graciously takes care of the POSTing Stefan> and not in all circumstances. Which is disappointing:-( Stefan> I am allready trying to debug this with Ole, but it seems that Stefan> he's on holyday. No, I'm just attending my daytime job;-) Sorry if I dropped out on one of your mails. Stefan> Any ideas? Yes, two: 1. Try supplying the bus number with the devfn argument: acpi_vgapost (pdev->bus->number << 8 | pdev->devfn); 2. Check that the VGA BIOS is really there before calling it. IIRC, the signature at 0xc000:0 should be 0xaa55 Stefan> There is some resume code in drivers/video/aty/radeon_pm.c Stefan> written by ATI, but it's only compiled on PowerMac and is only Stefan> tested for <=R200 and S2. ^^-- Do you mean D2? I've played with earlier versions of this code in radeonfb. In my understanding D2 is low power still retaining some state, so the PowerMac code is not a complete cold boot. Stefan> Perhaps we should ask ATI for help. I guess it could be tried; someone pessimistically predicted the answer as "use the BIOS". Ole |
From: <tm...@dr...> - 2004-08-05 12:27:21
|
On Thu, Aug 05, 2004 at 09:33:54AM +0200, ole...@ce... wrote: >=20 > I guess it could be tried; someone pessimistically predicted the > answer as "use the BIOS". >=20 > Ole Ben Herrenschmidt the linux PPC maintainer looked at it at one point. It appears that for some of the ATI Vide cards in laptops (Fujitsu P2120 is one), the Video Bios is co-lclated with main system bios... which makes it hard to post gracefuly. Tomasz --=20 Tomasz M. Ciolek=09 ***************************************************************************= **** tmc at dreamcraft dot com dot au=20 ***************************************************************************= **** GPG Key ID: 0x41C4C2F0 GPG Key Fingerprint: 3883 B308 8256 2246 D3ED A1FF 3A1D 0EAD 41C4 C2F0 Key available on www.pgp.net=09 ***************************************************************************= **** |