On 20-02-08 21:13, David P. Reed wrote:
Actually, disparaging things as "one idiotic system" doesn't seem like a
long-term thoughtful process - it's not even accurate.
Whatever we think about systems using port 0x80, fact of the matter is that
they do and outside of legacy stuff that isn't ap
Actually, disparaging things as "one idiotic system" doesn't seem like a
long-term thoughtful process - it's not even accurate. There are more
such systems that are running code today than the total number of 486
systems ever manufactured. The production rate is $1M/month.
a) ENE chips are "
On 20-02-08 18:05, H. Peter Anvin wrote:
Rene Herman wrote:
_Something_ like this would seem to be the only remaining option. It
seems fairly unuseful to #ifdef around that switch statement for
kernels without support for the earlier families, but if you insist...
"Only remaining option"
Rene Herman wrote:
_Something_ like this would seem to be the only remaining option. It
seems fairly unuseful to #ifdef around that switch statement for kernels
without support for the earlier families, but if you insist...
"Only remaining option" other than the one we've had all along. E
On 18-02-08 23:44, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT
delay in the first place meaning it just doesn't matter. There were
the VIA issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe
* David P. Reed <[EMAIL PROTECTED]> wrote:
> x86: use explicit timing delay for pit accesses in kernel and pcspkr
> driver
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Rene Herman wrote:
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the
VIA issues with the PIC but unless I
Rene Herman wrote:
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the PIT
are ill-defined if there hasn't been a PIT clock between two adjacent
accesses, so I fully expect that there are chipsets out there which
will do very bad things
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with t
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay in
the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy
On 18-02-08 22:44, H. Peter Anvin wrote:
Rene Herman wrote:
I mean that before the linux kernel used a port 0x80 write as an I/O
delay it used a short jump (two in a row actually...) as such and this
was at the time that it actually ran on the old legacy stuff that is
of most concern here.
Rene Herman wrote:
I mean that before the linux kernel used a port 0x80 write as an I/O
delay it used a short jump (two in a row actually...) as such and this
was at the time that it actually ran on the old legacy stuff that is of
most concern here.
No, if I'm not mistaken, those two jumps
On 18-02-08 22:04, Rene Herman wrote:
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note such -- it's a
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note such -- it's a vital part
of the problem.
Sorry,
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay (which
the Pentium obsoleted) I suppose it'll probably be okay even without
fixing that specifically but do note such -- it's a vital part of the
problem.
Sorry, that paragraph didn't parse for me.
On 18-02-08 19:58, David P. Reed wrote:
--- linux-2.6.orig/include/asm-x86/i8253.h
+++ linux-2.6/include/asm-x86/i8253.h
@@ -12,7 +12,25 @@ extern struct clock_event_device *global
extern void setup_pit_timer(void);
-#define inb_pit inb_p
-#define outb_pit outb_p
+/* accesses to PIT
On Mon, 18 Feb 2008 13:58:41 -0500 (EST)
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
Both look good to me now
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
pit accesses in i8253.c and pcspkr driver use outb_p for timing.
Fix them to use explicit timing delay for access to PIT,
rather than inb_p/outb_p calls, which use insufficiently explicit
delays (defaulting to port 80 writ
19 matches
Mail list logo
