[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071230144700.78f4605c@the-village.bc.nu>
Date: Sun, 30 Dec 2007 14:47:00 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Rene Herman <rene.herman@...access.nl>, dpreed@...d.com,
Islam Amer <pharon@...il.com>, hpa@...or.com,
Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...hat.com>,
Andi Kleen <andi@...stfloor.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
> slowdown entirely (obviously that is not for 2.6.24 either, though!), and
> drivers that then are shown to really need it could use their *own* ports.
*No* - that is the one thing they cannot do. The _p cycles on ISA for 2MHz
parts on a standard ISA bus needs the delay to come off another device.
For modern systems we should just use tsc delays, but we have to fix all
the drivers first as right now 0x80 causes posting and we have some PCI
users (I think probably all bogus), and we need to fix the tons of
locking errors that are mostly covered by the inb 0x80 being an
indivisible operation so not getting split by interrupts/SMP.
I've been going through the drivers that use it - the biggest mess
appears to be in the watchdog drivers all of which copied an original
lack of locking from the mid 1990s caused by umm.. me. I guess my past is
catching up with me ;)
Some of the ISA network users (like the scc driver) are going to be quite
foul to fix but most of it looks quite sane.
The X server also appears to touch 0x80 in some cases but we can hope
only on ancient hardware.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists