Skip to contentSkip to conversation

HPET reenabling after suspend-resume

PATCH In review Venkatesh Pallipadi 2 participants 2 messages Oct 23, 2004

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 HPET reenabling after suspend-resume

hpet hardware seems to need a little prodding during resume for it to start sending the timer interupts again. Attached patch does it for both i386 and x86_64.

Makefile change below: Right now suspend-resume ordering of system devices depends on their order of linking. It is ugly. But, thats the way it works currently. And we want timer device to resume before PIC.

/arch/i386/kernel/time.c renamed from /arch/i386/kernel/time.c.org +19 -11
@@ -321,7 +321,7 @@ unsigned long get_cmos_time(void)
 
 static long clock_cmos_diff;
 
-static int time_suspend(struct sys_device *dev, u32 state)
+static int timer_suspend(struct sys_device *dev, u32 state)
 {
 	/*
 	 * Estimate time zone so that set_time can update the clock
@@ -331,10 +331,18 @@ static int time_suspend(struct sys_devic
 	return 0;
 }
 
-static int time_resume(struct sys_device *dev)
+static int timer_resume(struct sys_device *dev)
 {
 	unsigned long flags;
-	unsigned long sec = get_cmos_time() + clock_cmos_diff;
+	unsigned long sec;
+
+#ifdef CONFIG_HPET_TIMER
+	if (is_hpet_enabled()) {
+		hpet_reenable();
+	}
+#endif
+
+	sec = get_cmos_time() + clock_cmos_diff;
 	write_seqlock_irqsave(&xtime_lock, flags);
 	xtime.tv_sec = sec;
 	xtime.tv_nsec = 0;
@@ -342,24 +350,24 @@ static int time_resume(struct sys_device
 	return 0;
 }
 
-static struct sysdev_class pit_sysclass = {
-	.resume = time_resume,
-	.suspend = time_suspend,
-	set_kset_name("pit"),
+static struct sysdev_class timer_sysclass = {
+	.resume = timer_resume,
+	.suspend = timer_suspend,
+	set_kset_name("timer"),
 };
 
 
 /* XXX this driverfs stuff should probably go elsewhere later -john */
-static struct sys_device device_i8253 = {
+static struct sys_device device_timer = {
 	.id	= 0,
-	.cls	= &pit_sysclass,
+	.cls	= &timer_sysclass,
 };
 
 static int time_init_device(void)
 {
-	int error = sysdev_class_register(&pit_sysclass);
+	int error = sysdev_class_register(&timer_sysclass);
 	if (!error)
-		error = sysdev_register(&device_i8253);
+		error = sysdev_register(&device_timer);
 	return error;
 }
 
/arch/i386/kernel/time_hpet.c renamed from /arch/i386/kernel/time_hpet.c.org +41 -26

91 lines not on this page · raw message

/include/asm-i386/hpet.h renamed from /include/asm-i386/hpet.h.org +1 -0
@@ -96,6 +96,7 @@ extern unsigned long hpet_address;	/* hp
 
 extern int hpet_rtc_timer_init(void);
 extern int hpet_enable(void);
+extern int hpet_reenable(void);
 extern int is_hpet_enabled(void);
 extern int is_hpet_capable(void);
 extern int hpet_readl(unsigned long a);
/arch/i386/kernel/Makefile renamed from /arch/i386/kernel/Makefile.org +1 -1
@@ -5,7 +5,7 @@
 extra-y := head.o init_task.o vmlinux.lds
 
 obj-y	:= process.o semaphore.o signal.o entry.o traps.o irq.o vm86.o \
-		ptrace.o i8259.o ioport.o ldt.o setup.o time.o sys_i386.o \
+		ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_i386.o \
 		pci-dma.o i386_ksyms.o i387.o dmi_scan.o bootflag.o \
 		doublefault.o
 
/arch/x86_64/kernel/time.c renamed from /arch/x86_64/kernel/time.c.org +52 -35

130 lines not on this page · raw message

/arch/x86_64/kernel/Makefile renamed from /arch/x86_64/kernel/Makefile.org +1 -1
@@ -5,7 +5,7 @@
 extra-y 	:= head.o head64.o init_task.o vmlinux.lds
 EXTRA_AFLAGS	:= -traditional
 obj-y	:= process.o semaphore.o signal.o entry.o traps.o irq.o \
-		ptrace.o i8259.o ioport.o ldt.o setup.o time.o sys_x86_64.o \
+		ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_x86_64.o \
 		x8664_ksyms.o i387.o syscall.o vsyscall.o \
 		setup64.o bootflag.o e820.o reboot.o warmreboot.o
 obj-y += mce.o
#1 lore raw
Quoted 4 lines · Venkatesh Pallipadi

hpet hardware seems to need a little prodding during resume for it to start sending the timer interupts again. Attached patch does it for both i386 and x86_64.

Hmm, what HPET hardware? It must have worked on some machines already, otherwise suspend/resume would have never worked on many AMD x86-64 machines.

Anyways, looks good.

-Andi