From: "David P. Reed" <dpreed@reed.com>
To: Christer Weinigel <christer@weinigel.se>
Cc: Ondrej Zary <linux@rainbow-software.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Rene Herman <rene.herman@keyaccess.nl>,
Bodo Eggert <7eggert@gmx.de>, Ingo Molnar <mingo@elte.hu>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Paul Rolland <rol@as2917.net>, Pavel Machek <pavel@ucw.cz>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
rol@witbe.net
Subject: Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
Date: Tue, 08 Jan 2008 15:28:03 -0500 [thread overview]
Message-ID: <4783DCD3.8010201@reed.com> (raw)
In-Reply-To: <20080108202519.1057cb75@cw05linux>
Christer Weinigel wrote:
>> There is no need to use io writes to supposedly/theoretically "unused
>> ports" to make drivers work on any bus.
>> ISA included! You can, for example, wait for an ISA bus serial
>> adapter to put out its next character by looping reading the port
>> that has the output buffer full flag in a tight loop, with no delay
>> code at all. And if you need to time things, just call a timing loop
>> subroutine that you calibrate at boot time.
>>
>
> Now you're totally confusing things. You're talking about looking at
> bits in a register to see if a transmit register is empty.
> That's easy.
>
> The delays needed for the Intel M8259 and M8253 say that you're not
> even allowed to access the registers _at_ _all_ for some time after a
> register access. If you do a write to a register immediately followed
> by any access, including a read of the status register, you can corrupt
> the state of the chip.
>
Not true. Even on the original IBM 5150 PC, the 8259 on the motherboard
accepted back to back OUT and IN instructions, and it would NOT trash
the chip state. You can read the original IBM BIOS code if you like. I
don't remember about the 8253's timing. I doubt the chip's state would
be corrupted in any way. The data and address lines were the same data
and address lines that the microprocessor used to access memory - it
didn't "hold" the lines stable any longer than the OUT instruction.
> And the Intel chips are not the only ones with that kind of brain
> damage. But what makes the 8259 and 8253 a big problem is that every
> modern PC has a descendant of those chips in them.
Register compatible. Not the same chips or even the same masks or
timing requirements.
> The discrete Intel
> chips or clones got aggregated into Super I/O chips, and the Super I/O
> chips were put on a LPC bus (an ISA bus with another name) or
> integrated into the southbrige.
Don't try to teach your grandmother to suck eggs: I've been programming
PC compatibles since probably before you were able to do long division -
including writing code on the first prototype IBM PCs, the first
pre-manufacturing PC-ATs, and zillions of clones. (and I was also
involved in designing hardware including the so-called "Lotus Intel"
expanded memory cards and the original PC cards) The 8259 PIC is an
*interrupt controller*. It was NEVER present in a Super I/O chip, or an
LPC chip. Its functionality was absorbed into the chipsets that control
interrupt mapping, like the PIIX and the nForce.
> And the "if it ain't broken, don't fix
> it" mantra probably means that some modern chipsets are still using
> exactly the same internal design as the 25 year old chips and will
> still be subject to some of those ancient limitations.
>
Oh, come on. Give the VLSI designers some credit for brains. The CAD
tools used to design the 8259 and 8253 were so primitive you couldn't
even get a chip manufactured with designs from that era today. When
people design chips today they do it with simulators that can't even
work, and testers that run from test suites that were not available at
the time.
next prev parent reply other threads:[~2008-01-08 20:28 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9BdU5-1YW-9@gated-at.bofh.it>
[not found] ` <9BeZN-3Gf-5@gated-at.bofh.it>
[not found] ` <9BnTB-1As-31@gated-at.bofh.it>
[not found] ` <9BrX4-8go-1@gated-at.bofh.it>
[not found] ` <9BuBG-4eR-51@gated-at.bofh.it>
[not found] ` <9BvRd-6aL-71@gated-at.bofh.it>
[not found] ` <9GRQW-1DX-13@gated-at.bofh.it>
[not found] ` <9GSah-23W-1@gated-at.bofh.it>
[not found] ` <9GSDy-2GD-23@gated-at.bofh.it>
[not found] ` <9GTpK-40d-15@gated-at.bofh.it>
[not found] ` <9GUvy-5H2-11@gated-at.bofh.it>
[not found] ` <9GVKU-7SS-25@gated-at.bofh.it>
2008-01-07 19:38 ` [PATCH] x86: provide a DMI based port 0x80 I/O delay override Bodo Eggert
2008-01-07 19:46 ` H. Peter Anvin
2008-01-07 22:02 ` Bodo Eggert
2008-01-07 22:10 ` H. Peter Anvin
2008-01-07 22:27 ` Bodo Eggert
2008-01-07 22:59 ` Rene Herman
2008-01-07 23:24 ` H. Peter Anvin
2008-01-07 23:26 ` Rene Herman
2008-01-08 0:10 ` [linux-kernel] " David P. Reed
2008-01-08 0:13 ` H. Peter Anvin
2008-01-08 1:38 ` David P. Reed
2008-01-08 17:10 ` Ondrej Zary
2008-01-08 17:24 ` David P. Reed
2008-01-08 17:38 ` Ondrej Zary
2008-01-08 18:44 ` David P. Reed
2008-01-08 18:51 ` Alan Cox
2008-01-08 19:15 ` David P. Reed
2008-01-08 19:23 ` Alan Cox
2008-01-08 19:51 ` David P. Reed
2008-01-09 2:52 ` Zachary Amsden
2008-01-09 5:19 ` H. Peter Anvin
2008-01-09 21:53 ` Zachary Amsden
2008-01-09 22:22 ` David P. Reed
2008-01-11 1:36 ` Zachary Amsden
2008-01-11 3:05 ` Rene Herman
2008-01-11 14:35 ` David P. Reed
2008-01-11 14:37 ` Alan Cox
2008-01-11 15:07 ` David P. Reed
2008-01-11 17:54 ` H. Peter Anvin
2008-01-11 14:49 ` Rene Herman
2008-01-14 21:57 ` David Woodhouse
2008-01-14 22:22 ` David P. Reed
2008-01-16 14:36 ` David Newall
2008-01-16 14:55 ` Alan Cox
2008-01-16 19:15 ` David Newall
2008-01-16 20:08 ` Alan Cox
2008-01-17 6:25 ` David Newall
2008-01-17 12:02 ` Alan Cox
2008-01-17 13:36 ` David Newall
2008-01-17 13:55 ` Rene Herman
2008-01-17 21:58 ` David Newall
2008-01-17 22:13 ` Rene Herman
2008-01-18 13:37 ` David Newall
2008-01-18 14:05 ` Rene Herman
2008-01-17 15:51 ` Alan Cox
2008-01-09 5:30 ` Christer Weinigel
2008-01-09 14:42 ` David P. Reed
2008-01-09 15:27 ` Rene Herman
2008-01-09 18:17 ` Zachary Amsden
2008-01-09 18:18 ` H. Peter Anvin
2008-01-09 20:26 ` Christer Weinigel
2008-01-09 21:59 ` H. Peter Anvin
2008-01-09 18:22 ` Adrian Bunk
2008-01-09 18:27 ` H. Peter Anvin
2008-01-08 19:25 ` Christer Weinigel
2008-01-08 20:28 ` David P. Reed [this message]
2008-01-08 21:43 ` Christer Weinigel
2008-01-08 22:24 ` David P. Reed
2008-01-08 18:51 ` Bodo Eggert
2008-01-08 19:13 ` Ondrej Zary
2008-01-09 21:01 ` Matthieu castet
2008-01-08 12:51 ` Bodo Eggert
2008-01-08 13:07 ` [linux-kernel] " David P. Reed
2008-01-08 14:37 ` Alan Cox
2008-01-08 14:09 ` Rene Herman
2008-01-08 14:31 ` Alan Cox
2008-01-07 23:57 ` [linux-kernel] " David P. Reed
2008-01-08 1:58 ` Alan Cox
2008-01-07 23:25 ` Alan Cox
2008-01-08 13:17 ` Bodo Eggert
2008-01-08 14:38 ` Alan Cox
2008-01-08 3:15 ` Christer Weinigel
[not found] <fa.u5p8NBl8IjcycTVVtf0K+YtqNQc@ifi.uio.no>
[not found] ` <fa.NOJkdyuk0c8CAqzZcG+pF1TzhJM@ifi.uio.no>
[not found] ` <fa.YLAHN7jSUo9phsICUHnxilN7/lk@ifi.uio.no>
[not found] ` <fa.SvgVgdNA9oz4F+tQ9MB2VRwr8ck@ifi.uio.no>
[not found] ` <fa.By1MDYK0MY/fwkCWWrAiQCxl5KM@ifi.uio.no>
[not found] ` <fa.97XrGLIGlvAy4P/TB5vHHrfBrIw@ifi.uio.no>
2008-01-10 0:37 ` [linux-kernel] " Robert Hancock
2008-01-10 0:44 ` Rene Herman
2008-01-10 14:41 ` David P. Reed
2007-12-17 13:02 Rene Herman
2007-12-17 17:14 ` H. Peter Anvin
2007-12-17 19:43 ` David P. Reed
2007-12-17 21:25 ` Alan Cox
2008-01-01 15:59 ` David P. Reed
2008-01-01 16:15 ` Alan Cox
2008-01-01 16:43 ` Ingo Molnar
2008-01-01 17:32 ` Alan Cox
2008-01-01 18:45 ` Ingo Molnar
2008-01-01 21:07 ` Alan Cox
2008-01-02 10:04 ` Ingo Molnar
2008-01-02 13:11 ` [linux-kernel] " David P. Reed
2008-01-02 13:21 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4783DCD3.8010201@reed.com \
--to=dpreed@reed.com \
--cc=7eggert@gmx.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=christer@weinigel.se \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rainbow-software.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=rene.herman@keyaccess.nl \
--cc=rol@as2917.net \
--cc=rol@witbe.net \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.