Subject: Re: Can we kill f inb_p, outb_p and other random I/O on port 0x80,
	in 2.6?
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <m1isnlk6pq.fsf@ebiederm.dsl.xmission.com>
References: <m1isnlk6pq.fsf@ebiederm.dsl.xmission.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1064229778.8584.2.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
Date: Mon, 22 Sep 2003 12:22:59 +0100
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1280
Lines: 31

On Llu, 2003-09-22 at 01:27, Eric W. Biederman wrote:
> So can we gradually kill inb_p, outb_p in 2.6?  An the other
> miscellaneous users of I/O port 0x80 for I/O delays?
> 
> Or possibly rewriting outb_p to look something like:
> outb(); udelay(200);  or whatever the appropriate delay is?

The delay should be 8 ISA clocks. While you can easily fix inb_p and
outb_p you also need to fix up the udelay() code since if you stick 
a BUG() check in udelay you'll find it gets used before the clock is
initialized even now, let alone with inb_p relying on it. But that
itself is quite fixable too.

(one part of the problem of course is you need inb_p/outb_p to drive
the timer chip on some x86 boards in order to calibrate the udelay
timer)


> When debugging this I modified arch/i386/io.h to read:
> #define  __SLOW_DOWN_IO__ ""
> Which totally removed the delay and the system ran fine.

Not all systems do - we had breakages from both the keyboard controller
and the timer chips even on some modern boards when this got messed up.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/