Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Dave Airlie wrote: >> > Anyway, this patch is really good, and enables S3 to work on more >> > machines. Thats good. It is not intrusive and I'll probably (try to) >> > push it. >> >> which acpi_sleep=... parameter enables it? I have machines resuming >> perfectly fine without it that i don't want to break ;-) > > I'll clean it up to add that stuff soon, but I've hit a problem with it on > my main desktop, it won't come out of suspend using my patch, however this is why it needs a boot-parameter :-) -- Stefan Seyfried \ "I didn't want to write for pay. I QA / R Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
> > Anyway, this patch is really good, and enables S3 to work on more > > machines. Thats good. It is not intrusive and I'll probably (try to) > > push it. > > which acpi_sleep=... parameter enables it? I have machines resuming > perfectly fine without it that i don't want to break ;-) I'll clean it up to add that stuff soon, but I've hit a problem with it on my main desktop, it won't come out of suspend using my patch, however vbepost in userspace works... this is very strange, as they do the same thing which is execute the VBIOS at c000:3, one does it in the kernel in REAL mode and the other does it in vm86 mode from userspace.. I think it may be calling into the real BIOS and hanging up in there.. maybe something to do with segment register setup or stacks.. (I've tried on-board i865, radeon and MGA cards)... Dave -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Pavel Machek wrote: > Anyway, this patch is really good, and enables S3 to work on more > machines. Thats good. It is not intrusive and I'll probably (try to) > push it. which acpi_sleep=... parameter enables it? I have machines resuming perfectly fine without it that i don't want to break ;-) -- Stefan Seyfried \ "I didn't want to write for pay. I QA / R Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Pavel Machek wrote: Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. which acpi_sleep=... parameter enables it? I have machines resuming perfectly fine without it that i don't want to break ;-) -- Stefan Seyfried \ I didn't want to write for pay. I QA / RD Team Mobile Devices \ wanted to be paid for what I write. SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. which acpi_sleep=... parameter enables it? I have machines resuming perfectly fine without it that i don't want to break ;-) I'll clean it up to add that stuff soon, but I've hit a problem with it on my main desktop, it won't come out of suspend using my patch, however vbepost in userspace works... this is very strange, as they do the same thing which is execute the VBIOS at c000:3, one does it in the kernel in REAL mode and the other does it in vm86 mode from userspace.. I think it may be calling into the real BIOS and hanging up in there.. maybe something to do with segment register setup or stacks.. (I've tried on-board i865, radeon and MGA cards)... Dave -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Dave Airlie wrote: Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. which acpi_sleep=... parameter enables it? I have machines resuming perfectly fine without it that i don't want to break ;-) I'll clean it up to add that stuff soon, but I've hit a problem with it on my main desktop, it won't come out of suspend using my patch, however this is why it needs a boot-parameter :-) -- Stefan Seyfried \ I didn't want to write for pay. I QA / RD Team Mobile Devices \ wanted to be paid for what I write. SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
On Sat, 23 Jul 2005 08:53:00 +0200, Stefan Smietanowski <[EMAIL PROTECTED]> wrote: >Pavel Machek wrote: >> Well, we have debugged with beeps, but... It would be cool if someone >> got usb debug mode working but... and there are hardware debuggers. > >If kdb is your thing then SGI has gotten kdb work over USB using >OHCI chipsets. They haven't done UHCI (Yet?). SGI systems only use OHCI, so we have not done UHCI support in KDB. If anybody wants to do the work for UHCI and send me a working patch, that patch will be included in KDB. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
On Sat, 23 Jul 2005 08:53:00 +0200, Stefan Smietanowski [EMAIL PROTECTED] wrote: Pavel Machek wrote: Well, we have debugged with beeps, but... It would be cool if someone got usb debug mode working but... and there are hardware debuggers. If kdb is your thing then SGI has gotten kdb work over USB using OHCI chipsets. They haven't done UHCI (Yet?). SGI systems only use OHCI, so we have not done UHCI support in KDB. If anybody wants to do the work for UHCI and send me a working patch, that patch will be included in KDB. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
> > For Intel at least the recommendation is to use the BIOS "save > mode"/"restore mode" interface. I'm going to see about implementing that on my PC when I get back to home, it doesn't seem like too bad an idea either... We are also going to provide some hooks out to userspace as well.. but I'd be interested in trying as many in-kernel solutions before going down that road... Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
On Sad, 2005-07-23 at 00:17 +0100, Matthew Garrett wrote: > Dave Airlie <[EMAIL PROTECTED]> wrote: > > > At OLS at lot of people were giving out about cards not resuming, > > so using a patch from Michael Marineau and help from lots of people > > sitting around in a circle at OLS I've gotten a patch that restores video > > on my laptop by going into real mode and re-posting the BIOS during > > resume, > > On laptops, the code at c000:0003 may jump to BIOS code that isn't > present after system boot. In userspace, this isn't too much of a > problem - the userspace code tends to just fall over rather than hanging > the machine. What happens if the kernel hits illegal or inappropriate > code on resume? For Intel at least the recommendation is to use the BIOS "save mode"/"restore mode" interface. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pavel Machek wrote: > Hi! > > >>>Unfortunately, if you only get printk() working after you ran >>>userspace app... well it makes debugging things like SATA >>>"interesting". So I quite like this patch. >> >>Most interesting laptop vendors have at least one model in each range >>with a serial port, which makes this sort of thing a bit easier. > > > Well, we have debugged with beeps, but... It would be cool if someone > got usb debug mode working but... and there are hardware debuggers. > > Anyway, this patch is really good, and enables S3 to work on more > machines. Thats good. It is not intrusive and I'll probably (try to) > push it. If kdb is your thing then SGI has gotten kdb work over USB using OHCI chipsets. They haven't done UHCI (Yet?). // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFC4elMBrn2kJu9P78RAlqqAJ4iKFeCf4Iomic7UzyWNLLztIqXkgCggc4L xyzG4KWvlUT15roBjWhtMhE= =j79y -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pavel Machek wrote: Hi! Unfortunately, if you only get printk() working after you ran userspace app... well it makes debugging things like SATA interesting. So I quite like this patch. Most interesting laptop vendors have at least one model in each range with a serial port, which makes this sort of thing a bit easier. Well, we have debugged with beeps, but... It would be cool if someone got usb debug mode working but... and there are hardware debuggers. Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. If kdb is your thing then SGI has gotten kdb work over USB using OHCI chipsets. They haven't done UHCI (Yet?). // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFC4elMBrn2kJu9P78RAlqqAJ4iKFeCf4Iomic7UzyWNLLztIqXkgCggc4L xyzG4KWvlUT15roBjWhtMhE= =j79y -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
On Sad, 2005-07-23 at 00:17 +0100, Matthew Garrett wrote: Dave Airlie [EMAIL PROTECTED] wrote: At OLS at lot of people were giving out about cards not resuming, so using a patch from Michael Marineau and help from lots of people sitting around in a circle at OLS I've gotten a patch that restores video on my laptop by going into real mode and re-posting the BIOS during resume, On laptops, the code at c000:0003 may jump to BIOS code that isn't present after system boot. In userspace, this isn't too much of a problem - the userspace code tends to just fall over rather than hanging the machine. What happens if the kernel hits illegal or inappropriate code on resume? For Intel at least the recommendation is to use the BIOS save mode/restore mode interface. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
For Intel at least the recommendation is to use the BIOS save mode/restore mode interface. I'm going to see about implementing that on my PC when I get back to home, it doesn't seem like too bad an idea either... We are also going to provide some hooks out to userspace as well.. but I'd be interested in trying as many in-kernel solutions before going down that road... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Hi! > > Unfortunately, if you only get printk() working after you ran > > userspace app... well it makes debugging things like SATA > > "interesting". So I quite like this patch. > > Most interesting laptop vendors have at least one model in each range > with a serial port, which makes this sort of thing a bit easier. Well, we have debugged with beeps, but... It would be cool if someone got usb debug mode working but... and there are hardware debuggers. Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Pavel Machek <[EMAIL PROTECTED]> wrote: > Unfortunately, if you only get printk() working after you ran > userspace app... well it makes debugging things like SATA > "interesting". So I quite like this patch. Most interesting laptop vendors have at least one model in each range with a serial port, which makes this sort of thing a bit easier. > If your BIOS does something wrong, well... your machine crashes. I think it's hard to define it as "something wrong" - there's no reason for BIOS authors to support the OS calling BIOS setup code after the machine has booted. Thinkpads seem to manage this fine, Sonys tend to be less good at it. Using the VBE mode setting code tends to be more reliable, and is pretty much guaranteed to be there even after boot. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Hi! > > At OLS at lot of people were giving out about cards not resuming, > > so using a patch from Michael Marineau and help from lots of people > > sitting around in a circle at OLS I've gotten a patch that restores video > > on my laptop by going into real mode and re-posting the BIOS during > > resume, > > On laptops, the code at c000:0003 may jump to BIOS code that isn't > present after system boot. In userspace, this isn't too much of a > problem - the userspace code tends to just fall over rather than hanging > the machine. What happens if the kernel hits illegal or inappropriate > code on resume? > > I'm still fairly convinced that the best approach here is to carry it > out in userspace, though this may require some support for asking > framebuffers not to try to print anything until userspace is running. > The only "real" solution is for the framebuffer drivers to know how to > program the chip from scratch. Unfortunately, if you only get printk() working after you ran userspace app... well it makes debugging things like SATA "interesting". So I quite like this patch. If your BIOS does something wrong, well... your machine crashes. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Dave Airlie <[EMAIL PROTECTED]> wrote: > At OLS at lot of people were giving out about cards not resuming, > so using a patch from Michael Marineau and help from lots of people > sitting around in a circle at OLS I've gotten a patch that restores video > on my laptop by going into real mode and re-posting the BIOS during > resume, On laptops, the code at c000:0003 may jump to BIOS code that isn't present after system boot. In userspace, this isn't too much of a problem - the userspace code tends to just fall over rather than hanging the machine. What happens if the kernel hits illegal or inappropriate code on resume? I'm still fairly convinced that the best approach here is to carry it out in userspace, though this may require some support for asking framebuffers not to try to print anything until userspace is running. The only "real" solution is for the framebuffer drivers to know how to program the chip from scratch. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Hi all,
At OLS at lot of people were giving out about cards not resuming,
so using a patch from Michael Marineau and help from lots of people
sitting around in a circle at OLS I've gotten a patch that restores video
on my laptop by going into real mode and re-posting the BIOS during
resume,
The current code can try to repost the BIOS in wakeup.S but this won't
work as ths PCI bus isn't alive enough, this patch waits until the pci
resume code is being called and it if finds a card with no driver loaded
it calls the reset code. This won't work if you are using radeonfb or any
fb, I've also written this code with Benh for radeonfb but the card
doesn't come up perfectly and we can crash later on...
Issues with this patch:
1. It uses CONFIG_X86 in C file, this should really be done with an arch
hook but I want to make sure that it solves the issues that people are
seeing and on what setups it breaks... I'd like this in -mm just to get
testing of it .. but I believe more discussion would be needed before
mainline could get it.
2. It traps back to realmode in kernel space.. (before reboot and apm bios
did this but to be honest a lot of people may not like this)
3. It traps back to realmode in kernel space (just in case you missed it)
4. See 2 and 3
5. Andi said he has code to do that trap on x86-64 systems, I might
integrate it in future versions...
My laptop still doesn't resume due to SATA no resuming properly on it..
but that is my next issue
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
diff --git a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
--- a/arch/i386/kernel/acpi/sleep.c
+++ b/arch/i386/kernel/acpi/sleep.c
@@ -5,15 +5,18 @@
* Copyright (C) 2001-2003 Pavel Machek <[EMAIL PROTECTED]>
*/
+#include
#include
#include
#include
+#include
#include
#include
/* address in low memory of the wakeup routine. */
unsigned long acpi_wakeup_address = 0;
unsigned long acpi_video_flags;
+unsigned long acpi_video_devnum;
extern char wakeup_start, wakeup_end;
extern void zap_low_mappings(void);
@@ -56,6 +59,33 @@ void acpi_restore_state_mem (void)
zap_low_mappings();
}
+/*
+ * acpi_vgapost
+ */
+
+extern void do_vgapost_lowlevel (unsigned long);
+
+void acpi_vgapost (struct pci_dev *pci_dev)
+{
+ unsigned long flags, saved_video_flags = acpi_video_flags;
+
+ acpi_video_devnum = (pci_dev->bus->number<<8) | (pci_dev->devfn);
+ acpi_video_flags = 1;
+ /* Map low memory and copy information */
+ init_low_mapping(swapper_pg_dir, USER_PTRS_PER_PGD);
+ memcpy((void *) acpi_wakeup_address, _start, _end -
_start);
+ acpi_copy_wakeup_routine(acpi_wakeup_address);
+ /* Tunnel thru real mode */
+ local_irq_save(flags);
+ do_vgapost_lowlevel(acpi_wakeup_address);
+ local_irq_restore(flags);
+ /* Restore mapping etc */
+ zap_low_mappings();
+ acpi_video_flags = saved_video_flags;
+}
+
+EXPORT_SYMBOL (acpi_vgapost);
+
/**
* acpi_reserve_bootmem - do _very_ early ACPI initialisation
*
diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -43,6 +43,7 @@ wakeup_code:
testl $1, video_flags - wakeup_code
jz 1f
+ movlvideo_devnum - wakeup_code, %eax
lcall $0xc000,$3
movw%cs, %ax
movw%ax, %ds# Bios might
have played with that
@@ -98,6 +99,7 @@ real_save_cr4:.long 0
real_magic:.long 0
video_mode:.long 0
video_flags: .long 0
+video_devnum: .long 0
real_efer_save_restore:.long 0
real_save_efer_edx:.long 0
real_save_efer_eax:.long 0
@@ -171,6 +173,32 @@ check_vesa:
_setbad: jmp setbad
+#
+# Real mode switch - verbatim from reboot.c
+#
+go_real:
+ movl%cr0, %eax
+ andl$0x0011, %eax
+ orl $0x6000, %eax
+ movl%eax, %cr0
+ movl%eax, %cr3
+ movl%cr0, %ebx
+ andl$0x6000, %ebx
+ jz 1f
+ wbinvd
+1: andb$0x10, %al
+ movl%eax, %cr0
+go_real_jmp: .byte 0xea
+go_real_jmp_off: .word 0x
+go_real_jmp_seg: .word 0x
+#
+# Real mode descriptor table
+#
+ .align 8
+go_real_desc: .quad 0x
+go_real_cseg: .quad 0x9a00
+go_real_dseg: .quad 0x9200
+
.code32
ALIGN
@@ -261,6 +289,8 @@ ENTRY(acpi_copy_wakeup_routine)
movl%edx, video_mode - wakeup_start (%eax)
movlacpi_video_flags, %edx
movl%edx, video_flags - wakeup_start (%eax)
+ movlacpi_video_devnum, %edx
+ movl%edx, video_devnum - wakeup_start (%eax)
movl$0x12345678, real_magic - wakeup_start (%eax)
movl$0x12345678, saved_magic
ret
@@ -310,6 +340,59 @@
[PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Hi all,
At OLS at lot of people were giving out about cards not resuming,
so using a patch from Michael Marineau and help from lots of people
sitting around in a circle at OLS I've gotten a patch that restores video
on my laptop by going into real mode and re-posting the BIOS during
resume,
The current code can try to repost the BIOS in wakeup.S but this won't
work as ths PCI bus isn't alive enough, this patch waits until the pci
resume code is being called and it if finds a card with no driver loaded
it calls the reset code. This won't work if you are using radeonfb or any
fb, I've also written this code with Benh for radeonfb but the card
doesn't come up perfectly and we can crash later on...
Issues with this patch:
1. It uses CONFIG_X86 in C file, this should really be done with an arch
hook but I want to make sure that it solves the issues that people are
seeing and on what setups it breaks... I'd like this in -mm just to get
testing of it .. but I believe more discussion would be needed before
mainline could get it.
2. It traps back to realmode in kernel space.. (before reboot and apm bios
did this but to be honest a lot of people may not like this)
3. It traps back to realmode in kernel space (just in case you missed it)
4. See 2 and 3
5. Andi said he has code to do that trap on x86-64 systems, I might
integrate it in future versions...
My laptop still doesn't resume due to SATA no resuming properly on it..
but that is my next issue
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
diff --git a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
--- a/arch/i386/kernel/acpi/sleep.c
+++ b/arch/i386/kernel/acpi/sleep.c
@@ -5,15 +5,18 @@
* Copyright (C) 2001-2003 Pavel Machek [EMAIL PROTECTED]
*/
+#include linux/module.h
#include linux/acpi.h
#include linux/bootmem.h
#include linux/dmi.h
+#include linux/pci.h
#include asm/smp.h
#include asm/tlbflush.h
/* address in low memory of the wakeup routine. */
unsigned long acpi_wakeup_address = 0;
unsigned long acpi_video_flags;
+unsigned long acpi_video_devnum;
extern char wakeup_start, wakeup_end;
extern void zap_low_mappings(void);
@@ -56,6 +59,33 @@ void acpi_restore_state_mem (void)
zap_low_mappings();
}
+/*
+ * acpi_vgapost
+ */
+
+extern void do_vgapost_lowlevel (unsigned long);
+
+void acpi_vgapost (struct pci_dev *pci_dev)
+{
+ unsigned long flags, saved_video_flags = acpi_video_flags;
+
+ acpi_video_devnum = (pci_dev-bus-number8) | (pci_dev-devfn);
+ acpi_video_flags = 1;
+ /* Map low memory and copy information */
+ init_low_mapping(swapper_pg_dir, USER_PTRS_PER_PGD);
+ memcpy((void *) acpi_wakeup_address, wakeup_start, wakeup_end -
wakeup_start);
+ acpi_copy_wakeup_routine(acpi_wakeup_address);
+ /* Tunnel thru real mode */
+ local_irq_save(flags);
+ do_vgapost_lowlevel(acpi_wakeup_address);
+ local_irq_restore(flags);
+ /* Restore mapping etc */
+ zap_low_mappings();
+ acpi_video_flags = saved_video_flags;
+}
+
+EXPORT_SYMBOL (acpi_vgapost);
+
/**
* acpi_reserve_bootmem - do _very_ early ACPI initialisation
*
diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -43,6 +43,7 @@ wakeup_code:
testl $1, video_flags - wakeup_code
jz 1f
+ movlvideo_devnum - wakeup_code, %eax
lcall $0xc000,$3
movw%cs, %ax
movw%ax, %ds# Bios might
have played with that
@@ -98,6 +99,7 @@ real_save_cr4:.long 0
real_magic:.long 0
video_mode:.long 0
video_flags: .long 0
+video_devnum: .long 0
real_efer_save_restore:.long 0
real_save_efer_edx:.long 0
real_save_efer_eax:.long 0
@@ -171,6 +173,32 @@ check_vesa:
_setbad: jmp setbad
+#
+# Real mode switch - verbatim from reboot.c
+#
+go_real:
+ movl%cr0, %eax
+ andl$0x0011, %eax
+ orl $0x6000, %eax
+ movl%eax, %cr0
+ movl%eax, %cr3
+ movl%cr0, %ebx
+ andl$0x6000, %ebx
+ jz 1f
+ wbinvd
+1: andb$0x10, %al
+ movl%eax, %cr0
+go_real_jmp: .byte 0xea
+go_real_jmp_off: .word 0x
+go_real_jmp_seg: .word 0x
+#
+# Real mode descriptor table
+#
+ .align 8
+go_real_desc: .quad 0x
+go_real_cseg: .quad 0x9a00
+go_real_dseg: .quad 0x9200
+
.code32
ALIGN
@@ -261,6 +289,8 @@ ENTRY(acpi_copy_wakeup_routine)
movl%edx, video_mode - wakeup_start (%eax)
movlacpi_video_flags, %edx
movl%edx, video_flags - wakeup_start (%eax)
+ movlacpi_video_devnum, %edx
+ movl%edx, video_devnum - wakeup_start (%eax)
movl$0x12345678, real_magic -
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Dave Airlie [EMAIL PROTECTED] wrote: At OLS at lot of people were giving out about cards not resuming, so using a patch from Michael Marineau and help from lots of people sitting around in a circle at OLS I've gotten a patch that restores video on my laptop by going into real mode and re-posting the BIOS during resume, On laptops, the code at c000:0003 may jump to BIOS code that isn't present after system boot. In userspace, this isn't too much of a problem - the userspace code tends to just fall over rather than hanging the machine. What happens if the kernel hits illegal or inappropriate code on resume? I'm still fairly convinced that the best approach here is to carry it out in userspace, though this may require some support for asking framebuffers not to try to print anything until userspace is running. The only real solution is for the framebuffer drivers to know how to program the chip from scratch. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Hi! At OLS at lot of people were giving out about cards not resuming, so using a patch from Michael Marineau and help from lots of people sitting around in a circle at OLS I've gotten a patch that restores video on my laptop by going into real mode and re-posting the BIOS during resume, On laptops, the code at c000:0003 may jump to BIOS code that isn't present after system boot. In userspace, this isn't too much of a problem - the userspace code tends to just fall over rather than hanging the machine. What happens if the kernel hits illegal or inappropriate code on resume? I'm still fairly convinced that the best approach here is to carry it out in userspace, though this may require some support for asking framebuffers not to try to print anything until userspace is running. The only real solution is for the framebuffer drivers to know how to program the chip from scratch. Unfortunately, if you only get printk() working after you ran userspace app... well it makes debugging things like SATA interesting. So I quite like this patch. If your BIOS does something wrong, well... your machine crashes. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Pavel Machek [EMAIL PROTECTED] wrote: Unfortunately, if you only get printk() working after you ran userspace app... well it makes debugging things like SATA interesting. So I quite like this patch. Most interesting laptop vendors have at least one model in each range with a serial port, which makes this sort of thing a bit easier. If your BIOS does something wrong, well... your machine crashes. I think it's hard to define it as something wrong - there's no reason for BIOS authors to support the OS calling BIOS setup code after the machine has booted. Thinkpads seem to manage this fine, Sonys tend to be less good at it. Using the VBE mode setting code tends to be more reliable, and is pretty much guaranteed to be there even after boot. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Hi! Unfortunately, if you only get printk() working after you ran userspace app... well it makes debugging things like SATA interesting. So I quite like this patch. Most interesting laptop vendors have at least one model in each range with a serial port, which makes this sort of thing a bit easier. Well, we have debugged with beeps, but... It would be cool if someone got usb debug mode working but... and there are hardware debuggers. Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
