2008-01-30 07:32:54 -05:00
|
|
|
/*
|
|
|
|
* sleep.c - x86-specific ACPI sleep support.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001-2003 Patrick Mochel
|
|
|
|
* Copyright (C) 2001-2003 Pavel Machek <pavel@suse.cz>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/bootmem.h>
|
|
|
|
#include <linux/dmi.h>
|
|
|
|
#include <linux/cpumask.h>
|
|
|
|
|
2008-04-10 17:28:10 -04:00
|
|
|
#include "realmode/wakeup.h"
|
|
|
|
#include "sleep.h"
|
2008-01-30 07:32:54 -05:00
|
|
|
|
2008-02-22 17:11:39 -05:00
|
|
|
unsigned long acpi_wakeup_address;
|
2008-01-30 07:32:54 -05:00
|
|
|
unsigned long acpi_realmode_flags;
|
|
|
|
|
2008-04-10 17:28:10 -04:00
|
|
|
/* address in low memory of the wakeup routine. */
|
|
|
|
static unsigned long acpi_realmode;
|
|
|
|
|
|
|
|
#ifdef CONFIG_64BIT
|
|
|
|
static char temp_stack[10240];
|
|
|
|
#endif
|
2008-01-30 07:32:54 -05:00
|
|
|
|
x86, suspend, acpi: enter Big Real Mode
The explanation for recent video BIOS suspend quirk failures is that
the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff)
instead of ordinary Real Mode (*.limit = 0xffff).
This patch changes the segment descriptors to Big Real Mode instead.
The segment descriptor registers (what Intel calls "segment cache") is
always active. The only thing that changes based on CR0.PE is how it is
*loaded* and the interpretation of the CS flags.
The segment descriptor registers contain of the following sub-registers:
selector (the "visible" part), base, limit and flags. In protected mode
or long mode, they are loaded from descriptors (or fs.base or gs.base can
be manipulated directly in long mode.) In real mode, the only thing
changed by a segment register load is the selector and the base, where the
base <- selector << 4. In particular, *the limit and the flags are not
changed*.
As far as the handling of the CS flags: a code segment cannot be writable
in protected mode, whereas it is "just another segment" in real mode, so
there is some kind of quirk that kicks in for this when CR0.PE <- 0. I'm
not sure if this is accomplished by actually changing the cs.flags register
or just changing the interpretation; it might be something that is
CPU-specific. In particular, the Transmeta CPUs had an explicit "CS is
writable if you're in real mode" override, so even if you had loaded CS
with an execute-only segment it'd be writable (but not readable!) on return
to real mode. I'm not at all sure if that is how other CPUs behave.
Signed-off-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-14 00:18:02 -04:00
|
|
|
/* XXX: this macro should move to asm-x86/segment.h and be shared with the
|
|
|
|
boot code... */
|
|
|
|
#define GDT_ENTRY(flags, base, limit) \
|
|
|
|
(((u64)(base & 0xff000000) << 32) | \
|
|
|
|
((u64)flags << 40) | \
|
|
|
|
((u64)(limit & 0x00ff0000) << 32) | \
|
|
|
|
((u64)(base & 0x00ffffff) << 16) | \
|
|
|
|
((u64)(limit & 0x0000ffff)))
|
|
|
|
|
2008-01-30 07:32:54 -05:00
|
|
|
/**
|
|
|
|
* acpi_save_state_mem - save kernel state
|
|
|
|
*
|
|
|
|
* Create an identity mapped page table and copy the wakeup routine to
|
|
|
|
* low memory.
|
2008-04-10 17:28:10 -04:00
|
|
|
*
|
|
|
|
* Note that this is too late to change acpi_wakeup_address.
|
2008-01-30 07:32:54 -05:00
|
|
|
*/
|
|
|
|
int acpi_save_state_mem(void)
|
|
|
|
{
|
2008-04-10 17:28:10 -04:00
|
|
|
struct wakeup_header *header;
|
|
|
|
|
|
|
|
if (!acpi_realmode) {
|
|
|
|
printk(KERN_ERR "Could not allocate memory during boot, "
|
|
|
|
"S3 disabled\n");
|
2008-01-30 07:32:54 -05:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2008-04-10 17:28:10 -04:00
|
|
|
memcpy((void *)acpi_realmode, &wakeup_code_start, WAKEUP_SIZE);
|
|
|
|
|
|
|
|
header = (struct wakeup_header *)(acpi_realmode + HEADER_OFFSET);
|
|
|
|
if (header->signature != 0x51ee1111) {
|
|
|
|
printk(KERN_ERR "wakeup header does not match\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
header->video_mode = saved_video_mode;
|
|
|
|
|
2008-06-24 17:03:48 -04:00
|
|
|
header->wakeup_jmp_seg = acpi_wakeup_address >> 4;
|
2008-07-14 14:44:26 -04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set up the wakeup GDT. We set these up as Big Real Mode,
|
|
|
|
* that is, with limits set to 4 GB. At least the Lenovo
|
|
|
|
* Thinkpad X61 is known to need this for the video BIOS
|
|
|
|
* initialization quirk to work; this is likely to also
|
|
|
|
* be the case for other laptops or integrated video devices.
|
|
|
|
*/
|
|
|
|
|
2008-06-24 17:03:48 -04:00
|
|
|
/* GDT[0]: GDT self-pointer */
|
|
|
|
header->wakeup_gdt[0] =
|
|
|
|
(u64)(sizeof(header->wakeup_gdt) - 1) +
|
|
|
|
((u64)(acpi_wakeup_address +
|
|
|
|
((char *)&header->wakeup_gdt - (char *)acpi_realmode))
|
|
|
|
<< 16);
|
2008-07-14 14:44:26 -04:00
|
|
|
/* GDT[1]: big real mode-like code segment */
|
x86, suspend, acpi: enter Big Real Mode
The explanation for recent video BIOS suspend quirk failures is that
the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff)
instead of ordinary Real Mode (*.limit = 0xffff).
This patch changes the segment descriptors to Big Real Mode instead.
The segment descriptor registers (what Intel calls "segment cache") is
always active. The only thing that changes based on CR0.PE is how it is
*loaded* and the interpretation of the CS flags.
The segment descriptor registers contain of the following sub-registers:
selector (the "visible" part), base, limit and flags. In protected mode
or long mode, they are loaded from descriptors (or fs.base or gs.base can
be manipulated directly in long mode.) In real mode, the only thing
changed by a segment register load is the selector and the base, where the
base <- selector << 4. In particular, *the limit and the flags are not
changed*.
As far as the handling of the CS flags: a code segment cannot be writable
in protected mode, whereas it is "just another segment" in real mode, so
there is some kind of quirk that kicks in for this when CR0.PE <- 0. I'm
not sure if this is accomplished by actually changing the cs.flags register
or just changing the interpretation; it might be something that is
CPU-specific. In particular, the Transmeta CPUs had an explicit "CS is
writable if you're in real mode" override, so even if you had loaded CS
with an execute-only segment it'd be writable (but not readable!) on return
to real mode. I'm not at all sure if that is how other CPUs behave.
Signed-off-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-14 00:18:02 -04:00
|
|
|
header->wakeup_gdt[1] =
|
|
|
|
GDT_ENTRY(0x809b, acpi_wakeup_address, 0xfffff);
|
2008-07-14 14:44:26 -04:00
|
|
|
/* GDT[2]: big real mode-like data segment */
|
x86, suspend, acpi: enter Big Real Mode
The explanation for recent video BIOS suspend quirk failures is that
the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff)
instead of ordinary Real Mode (*.limit = 0xffff).
This patch changes the segment descriptors to Big Real Mode instead.
The segment descriptor registers (what Intel calls "segment cache") is
always active. The only thing that changes based on CR0.PE is how it is
*loaded* and the interpretation of the CS flags.
The segment descriptor registers contain of the following sub-registers:
selector (the "visible" part), base, limit and flags. In protected mode
or long mode, they are loaded from descriptors (or fs.base or gs.base can
be manipulated directly in long mode.) In real mode, the only thing
changed by a segment register load is the selector and the base, where the
base <- selector << 4. In particular, *the limit and the flags are not
changed*.
As far as the handling of the CS flags: a code segment cannot be writable
in protected mode, whereas it is "just another segment" in real mode, so
there is some kind of quirk that kicks in for this when CR0.PE <- 0. I'm
not sure if this is accomplished by actually changing the cs.flags register
or just changing the interpretation; it might be something that is
CPU-specific. In particular, the Transmeta CPUs had an explicit "CS is
writable if you're in real mode" override, so even if you had loaded CS
with an execute-only segment it'd be writable (but not readable!) on return
to real mode. I'm not at all sure if that is how other CPUs behave.
Signed-off-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-14 00:18:02 -04:00
|
|
|
header->wakeup_gdt[2] =
|
|
|
|
GDT_ENTRY(0x8093, acpi_wakeup_address, 0xfffff);
|
2008-06-24 17:03:48 -04:00
|
|
|
|
2008-04-10 17:28:10 -04:00
|
|
|
#ifndef CONFIG_64BIT
|
|
|
|
store_gdt((struct desc_ptr *)&header->pmode_gdt);
|
|
|
|
|
|
|
|
header->pmode_efer_low = nx_enabled;
|
|
|
|
if (header->pmode_efer_low & 1) {
|
|
|
|
/* This is strange, why not save efer, always? */
|
|
|
|
rdmsr(MSR_EFER, header->pmode_efer_low,
|
|
|
|
header->pmode_efer_high);
|
|
|
|
}
|
|
|
|
#endif /* !CONFIG_64BIT */
|
|
|
|
|
|
|
|
header->pmode_cr0 = read_cr0();
|
|
|
|
header->pmode_cr4 = read_cr4();
|
|
|
|
header->realmode_flags = acpi_realmode_flags;
|
|
|
|
header->real_magic = 0x12345678;
|
|
|
|
|
|
|
|
#ifndef CONFIG_64BIT
|
|
|
|
header->pmode_entry = (u32)&wakeup_pmode_return;
|
|
|
|
header->pmode_cr3 = (u32)(swsusp_pg_dir - __PAGE_OFFSET);
|
|
|
|
saved_magic = 0x12345678;
|
|
|
|
#else /* CONFIG_64BIT */
|
|
|
|
header->trampoline_segment = setup_trampoline() >> 4;
|
2008-06-13 14:31:54 -04:00
|
|
|
#ifdef CONFIG_SMP
|
2008-05-27 21:22:54 -04:00
|
|
|
stack_start.sp = temp_stack + 4096;
|
2008-06-13 14:31:54 -04:00
|
|
|
#endif
|
2008-04-10 17:28:10 -04:00
|
|
|
initial_code = (unsigned long)wakeup_long64;
|
|
|
|
saved_magic = 0x123456789abcdef0;
|
|
|
|
#endif /* CONFIG_64BIT */
|
2008-01-30 07:32:54 -05:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* acpi_restore_state - undo effects of acpi_save_state_mem
|
|
|
|
*/
|
|
|
|
void acpi_restore_state_mem(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_reserve_bootmem - do _very_ early ACPI initialisation
|
|
|
|
*
|
|
|
|
* We allocate a page from the first 1MB of memory for the wakeup
|
|
|
|
* routine for when we come back from a sleep state. The
|
|
|
|
* runtime allocator allows specification of <16MB pages, but not
|
|
|
|
* <1MB pages.
|
|
|
|
*/
|
|
|
|
void __init acpi_reserve_bootmem(void)
|
|
|
|
{
|
2008-04-10 17:28:10 -04:00
|
|
|
if ((&wakeup_code_end - &wakeup_code_start) > WAKEUP_SIZE) {
|
2008-01-30 07:32:54 -05:00
|
|
|
printk(KERN_ERR
|
|
|
|
"ACPI: Wakeup code way too big, S3 disabled.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-04-10 17:28:10 -04:00
|
|
|
acpi_realmode = (unsigned long)alloc_bootmem_low(WAKEUP_SIZE);
|
|
|
|
|
|
|
|
if (!acpi_realmode) {
|
2008-01-30 07:32:54 -05:00
|
|
|
printk(KERN_ERR "ACPI: Cannot allocate lowmem, S3 disabled.\n");
|
2008-04-10 17:28:10 -04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-06-24 17:03:48 -04:00
|
|
|
acpi_wakeup_address = virt_to_phys((void *)acpi_realmode);
|
2008-01-30 07:32:54 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int __init acpi_sleep_setup(char *str)
|
|
|
|
{
|
|
|
|
while ((str != NULL) && (*str != '\0')) {
|
|
|
|
if (strncmp(str, "s3_bios", 7) == 0)
|
|
|
|
acpi_realmode_flags |= 1;
|
|
|
|
if (strncmp(str, "s3_mode", 7) == 0)
|
|
|
|
acpi_realmode_flags |= 2;
|
|
|
|
if (strncmp(str, "s3_beep", 7) == 0)
|
|
|
|
acpi_realmode_flags |= 4;
|
2008-06-12 17:24:06 -04:00
|
|
|
if (strncmp(str, "old_ordering", 12) == 0)
|
|
|
|
acpi_old_suspend_ordering();
|
2008-01-30 07:32:54 -05:00
|
|
|
str = strchr(str, ',');
|
|
|
|
if (str != NULL)
|
|
|
|
str += strspn(str, ", \t");
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
__setup("acpi_sleep=", acpi_sleep_setup);
|