Skip to contentSkip to conversation

janitorial: remove i8253_lock conversion

PATCH In review Jan Kiszka 2 participants 4 messages Oct 29, 2007 – Oct 30, 2007

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

PATCH 1/1 janitorial: remove i8253_lock conversion

Unless I'm utterly wrong, there are practically only two use cases regarding the PIT: Either Linux has complete hold of it for clocksource and/or clockevent usage, or the RT domain takes it over, also completely. In both cases the RT domain does not need to use the i8253_lock (see Xenomai). So let's remove the hunks that harden this lock for no good (upcoming 2.6.24 would otherwise require even _extended_ patching). Patch addresses i386, but this cleanup should be applicable to x86_64 likewise.

Jan

---
 arch/i386/kernel/i8253.c               |    2 +-
 arch/i386/mach-voyager/voyager_basic.c |    8 ++++----
 include/asm-i386/i8253.h               |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)
arch/i386/kernel/i8253.c +1 -1
Index: linux-2.6.23.1-xeno/arch/i386/kernel/i8253.c
===================================================================
@@ -16,7 +16,7 @@
 #include <asm/io.h>
 #include <asm/timer.h>
 
-IPIPE_DEFINE_SPINLOCK(i8253_lock);
+DEFINE_SPINLOCK(i8253_lock);
 EXPORT_SYMBOL(i8253_lock);
 
 /*
arch/i386/mach-voyager/voyager_basic.c +4 -4
Index: linux-2.6.23.1-xeno/arch/i386/mach-voyager/voyager_basic.c
===================================================================
@@ -185,20 +185,20 @@ voyager_timer_interrupt(void)
 		 * pointy.  */
 		__u16 val;
 
-		spin_lock_irqsave(&i8253_lock);
+		spin_lock(&i8253_lock);
 		
 		outb_p(0x00, 0x43);
 		val = inb_p(0x40);
 		val |= inb(0x40) << 8;
-		spin_unlock_irqrestore(&i8253_lock);
+		spin_unlock(&i8253_lock);
 
 		if(val > LATCH) {
 			printk("\nVOYAGER: countdown timer value too high (%d), resetting\n\n", val);
-			spin_lock_irqsave(&i8253_lock);
+			spin_lock(&i8253_lock);
 			outb(0x34,0x43);
 			outb_p(LATCH & 0xff , 0x40);	/* LSB */
 			outb(LATCH >> 8 , 0x40);	/* MSB */
-			spin_unlock_irqrestore(&i8253_lock);
+			spin_unlock(&i8253_lock);
 		}
 	}
 #ifdef CONFIG_SMP
include/asm-i386/i8253.h +1 -1
Index: linux-2.6.23.1-xeno/include/asm-i386/i8253.h
===================================================================
@@ -8,7 +8,7 @@
 #define PIT_CH0			0x40
 #define PIT_CH2			0x42
 
-extern ipipe_spinlock_t i8253_lock;
+extern spinlock_t i8253_lock;
 
 extern struct clock_event_device *global_clock_event;
author
#1 lore raw
Quoted 10 lines · Jan Kiszka

Unless I'm utterly wrong, there are practically only two use cases regarding the PIT: Either Linux has complete hold of it for clocksource and/or clockevent usage, or the RT domain takes it over, also completely. In both cases the RT domain does not need to use the i8253_lock (see Xenomai). So let's remove the hunks that harden this lock for no good (upcoming 2.6.24 would otherwise require even _extended_ patching). Patch addresses i386, but this cleanup should be applicable to x86_64 likewise.

Jan

PS: voyager hunk was uncompilable anyway.

#2 lore raw
Quoted 10 lines · Jan Kiszka
Quoted 9 lines · Jan Kiszka

Unless I'm utterly wrong, there are practically only two use cases regarding the PIT: Either Linux has complete hold of it for clocksource and/or clockevent usage, or the RT domain takes it over, also completely. In both cases the RT domain does not need to use the i8253_lock (see Xenomai). So let's remove the hunks that harden this lock for no good (upcoming 2.6.24 would otherwise require even _extended_ patching). Patch addresses i386, but this cleanup should be applicable to x86_64 likewise.

Quoted 4 lines
Quoted 1 line

Jan

PS: voyager hunk was uncompilable anyway.

It's not the hunk, it's even the entire Voyager platform which we never supported actually. This hunk was plainly useless indeed.

Quoted 8 lines

------------------------------------------------------------------------

_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main

Signature · 1 line
Philippe.
#3 lore raw
In reply to Jan Kiszka
Quoted 5 lines · Jan Kiszka

Unless I'm utterly wrong, there are practically only two use cases regarding the PIT: Either Linux has complete hold of it for clocksource and/or clockevent usage, or the RT domain takes it over, also completely. In both cases the RT domain does not need to use the i8253_lock (see Xenomai).

Ack.

So let's remove the hunks that harden this

Quoted 4 lines

lock for no good (upcoming 2.6.24 would otherwise require even _extended_ patching). Patch addresses i386, but this cleanup should be applicable to x86_64 likewise.

Our x86_64 port relies on having APIC+TSC, so we don't even care about the PIT anyway.

Will merge, thanks.

Quoted 2 lines

Jan

Signature · 1 line
Philippe.