janitorial: remove i8253_lock conversion
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
@@ -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
@@ -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
@@ -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;
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 tox86_64likewise.Jan
PS: voyager hunk was uncompilable anyway.
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_64likewise.
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.
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 tox86_64likewise.
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.