On Mon 2007-12-17 15:42:51, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > > > ./char/epca.c
> > > > > ./char/sonypi.c
> > > > > ./scsi/megaraid.c
> > > > > ./ide/pci/serverworks.c
> > > > > ./ide/pci/cmd640.c
> > > > > ./input/mouse/pc110pad.c
> > >
> > > You are miss
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > > ./char/epca.c
> > > > ./char/sonypi.c
> > > > ./scsi/megaraid.c
> > > > ./ide/pci/serverworks.c
> > > > ./ide/pci/cmd640.c
> > > > ./input/mouse/pc110pad.c
> >
> > You are missing some watchdogs at least ?
>
> I snipped them, I only wanted to c
On Mon 2007-12-17 00:03:01, Alan Cox wrote:
> On Sun, 16 Dec 2007 22:26:33 +0100
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
> > >
> > > * Alan Cox <[EMAIL PROTECTED]> wrote:
> > >
> > > > There is another reason we can't just do a dumb changeov
> /*
> * We try to avoid enabling the hardware if it's not
> * there, but we don't know how to test. But we do know
> * that the PC110 is not a PCI system. So if we find any
> * PCI devices in the machine, we don't have a PC110.
> */
The pc110 pad device is ISA. Its an ISA bus 486 box
Alan
-
On Sun, 16 Dec 2007 22:26:33 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
> >
> > * Alan Cox <[EMAIL PROTECTED]> wrote:
> >
> > > There is another reason we can't just do a dumb changeover - two
> > > actually
> > >
> > > #1: Some drivers are u
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
>
> * Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > There is another reason we can't just do a dumb changeover - two
> > actually
> >
> > #1: Some drivers are using inb_p/outb_p in PCI cases which are going
> > #to cause PCI posting changes. Most are
On Thu, 13 Dec 2007 20:50:33 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80)
> is "absolutely correct" for devices provided on PCI-X running on 3 GHz
> or greater machines?
Yes - the LPC bus clock doesn't change for the
* Alan Cox <[EMAIL PROTECTED]> wrote:
> There is another reason we can't just do a dumb changeover - two
> actually
>
> #1: Some drivers are using inb_p/outb_p in PCI cases which are going
> #to cause PCI posting changes. Most are probably just wrong in the
> #first place but they need hand c
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Why is TSC significant? udelay() based on bogomips seems to be good
> > enough...?
>
> Maybe I'm not sure how accurate it really is on non TSC system. On the
> other hand it is unclear that the port 80 IO is always the same time
> so it's probably o
Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80)
is "absolutely correct" for devices provided on PCI-X running on 3 GHz
or greater machines?
Well, you are entitled to your opinion. Seems likely that reading the
timing specs of such a chipset might be correct, and delay
On Thu, 13 Dec 2007 08:13:29 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Perhaps what was meant is that ISA-tuned timings make little sense on
> devices that are part of the chipset or on the PCI or PCI-X buses?
No.
ISA as LPC bus is alive and well inside and outside chipsets. Welcome to
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
On the other hand, since we don't know in many cases whether the "_p"
was supposed to mean "the time it takes to execute an "out al,80h" on
whatever bus stru
> Yes, it's now clear that all of this is so. Regrettably, it's used in
> dozens of drivers, most having nothing to do with an ISA/LPC bus.
>
> If it really is specific to the ISA architecture, then it should only be
> used in architecture specific code.
ISA/LPC is not architecture specific. I
Alan Cox wrote:
without need. Not surprising since it has such a vague specific
meaning. One could say, Linux on i386 is liberally sprinkled with
"vague specific" ? sorry don't follow you.
The _p variants are a universal fixture, defined as ending with a pause,
but without specify
There is another reason we can't just do a dumb changeover - two actually
#1: Some drivers are using inb_p/outb_p in PCI cases which are going to
cause PCI posting changes. Most are probably just wrong in the first
place but they need hand checking
#2: We've got SMP cases that only 'work' because
On Tue, 11 Dec 2007, David P. Reed wrote:
> 1) I found in a book, the Undocumented PC, that I have lying around that
> the "pause" recommended for some old adapter chips on the ISA bus was 1
> usec. The book carefully points out on various models of PCs how many
> short jumps are required to imp
1) I found in a book, the Undocumented PC, that I have lying around that
the "pause" recommended for some old adapter chips on the ISA bus was 1
usec. The book carefully points out on various models of PCs how many
short jumps are required to implement 1 usec, and suggests that for
faster mach
Dick - I didn't work for Don in Boca. I did know him, having met with
him several times when he was still alive. I worked from 1979-1985 as a
consultant and eventually VP R&D, at Software Arts in Cambridge, MA, and
there was a machine we developed the first IBM Visicalc for, in a locked
room
On 11-12-07 21:27, linux-os (Dick Johnson) wrote:
I didn't know you worked in Boca Raton for Don Estrage on
the IBM 5150. I must have missed you --somehow.
Frankly, if there ever was a good reason for _not_ merging i386 and x86-64
it would've been having an escape from these kinds of discussi
On Tue, 11 Dec 2007, David P. Reed wrote:
>
>
> Alan Cox wrote:
>>
>> The vga driver is somewhat misnamed. In console mode we handle everything
>> back to MDA/HGA and some HGA adapters do need delays.
>>
>>
> No they don't. I really, really, really know this for a fact. I wrote
> ASM drivers f
>> And if you choose to be such an insulting
Fine. I won't bother submitting patches to fix this because I don't seem
to care any more. The only person who is suffering seems to have an
attitude problem and the only people I work for with attitude problems
are customers of my employer.
Alan
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to
be safe" perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to
be safe" perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to
be safe" perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to
be safe" perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
Hi!
> a spec sheet, or even better a machine. I may have an original PC-XT
> still lying around in the attic, don't know if I can fire it up, but it had
> such graphics cards. I also have several early high-speed clones that were
> "overclocked".
PC-XT does not count ... it needs to be 386
Alan Cox wrote:
The vga driver is somewhat misnamed. In console mode we handle everything
back to MDA/HGA and some HGA adapters do need delays.
No they don't. I really, really, really know this for a fact. I wrote
ASM drivers for every early video adapter and ran them all through Lotus
On Tue 2007-12-11 18:04:32, Rene Herman wrote:
> On 11-12-07 18:00, David P. Reed wrote:
>
>> Which port do you want me to test?
>
> Oh, thought your previous reply was already responding to this. The "other
> diagnostic port", 0xed. The point is not so much that it's going to be a
> good alterna
Hi!
>> Anyways it looks like the discussion here is going in a
>> a loop. I had hoped David would post his test results with
>> another port so that we know for sure that the bus aborts (and not port
>> 80) is the problem on his box. But it looks like
>> he doesn't want to do this. Still removing
> below, from a list of those I needed to patch to eliminate refs to _b
> calls) or arch specific code (also listed below), who might know why the
> _p macros are actually needed (for any platform)?
Because the controllers were historically slower than the CPU and thus
clocked at half bus speed.
On 11-12-07 18:04, Rene Herman wrote:
On 11-12-07 18:00, David P. Reed wrote:
Which port do you want me to test?
Oh, thought your previous reply was already responding to this. The
"other diagnostic port", 0xed. The point is not so much that it's going
to be a good alternate solution but t
David P. Reed wrote:
I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS -
other ports have been used in the history of the IBM PC family by some
vendors, and some machines have used it for DMA port mapping!!
Correction: ALL machines use it for DMA port mapping. The port is
On 11-12-07 18:00, David P. Reed wrote:
Which port do you want me to test?
Oh, thought your previous reply was already responding to this. The "other
diagnostic port", 0xed. The point is not so much that it's going to be a
good alternate solution but to exclude it being a possible solution.
Rene Herman wrote:
On 11-12-07 02:25, H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a s
On 11-12-07 17:58, David P. Reed wrote:
I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS
There's lots of things concerning the PC that is documented nowhere and is
still true. Did you test 0xed?
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
Which port do you want me to test? Also, I can run the timing test on
my machine if you share the source code so I can build it.
Rene Herman wrote:
On 11-12-07 17:30, Andi Kleen wrote:
Anyways it looks like the discussion here is going in a
a loop. I had hoped David would post his test resul
As the person who started this thread, I'm still puzzled by two things:
1) is there anyone out there who wrote one of these drivers (most listed
below, from a list of those I needed to patch to eliminate refs to _b
calls) or arch specific code (also listed below), who might know why the
_p mac
On 11-12-07 17:30, Andi Kleen wrote:
Anyways it looks like the discussion here is going in a
a loop. I had hoped David would post his test results with
another port so that we know for sure that the bus aborts
(and not port 80) is the problem on his box. But it looks like
he doesn't want to do
On 11-12-07 17:32, John Stoffel wrote:
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA
slot, which until recently was actually used with an 8 port serial
card:
jfsnew:~/src> sudo ./port80
out: 729
in : 348
jfsnew:~/src> sudo ./port80
out: 729
in : 354
jfsnew:~/src> sudo ./po
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA
slot, which until recently was actually used with an 8 port serial
card:
jfsnew:~/src> sudo ./port80
out: 729
in : 348
jfsnew:~/src> sudo ./port80
out: 729
in : 354
jfsnew:~/src> sudo ./port80
out: 729
in : 350
jfsnew:~/src> sudo
> Most, probably most-all, of the delays to port operations
> on modern ix86 machines are not needed at all. Certainly
We know this. The problem is that there is no good known way to
figure out which machines need it. Also it is typically
slow hardware anyways -- the most time critical is probab
On 11-12-07 16:37, Paul Rolland wrote:
Great, thanks for the quick replies.
That last one below especially is quite a bit more than 1. As said before,
most hardware isn't in fact going to need anything but I suppose udelay(2)
might be the "safer" replacement for the outb then...
On Tue, 11
On Tue, 11 Dec 2007, David Newall wrote:
> Rene Herman wrote:
>> This particular discussion isn't about anything in general but solely
>> about the delay an outb_p gives you on x86 since what is under
>> discussion is not using an output to port 0x80 on that platform to
>> generate it.
>
> That c
Hello,
On Tue, 11 Dec 2007 16:28:56 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 11-12-07 15:15, Rene Herman wrote:
>
> > On 11-12-07 14:32, Paul Rolland wrote:
> >
> This might be a bit more constant, I suppose. This serialises with cpuid.
> Don't see a difference locally, but perhaps yo
On 11-12-07 15:15, Rene Herman wrote:
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both
out and in on my own PC -- a little over. If anyone cares, see
attached little test pr
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
> In any case, my machine does not have an ISA bus. Why should it? It's
> a laptop!
Really? Are you sure? How does the CPU talk to the BIOS? How about
the parallel port if you have one? (I will assume you have no serial
ports sin
> That could be true if outb_p were used only in architecture dependent
> code, but it's not. It's used in drivers that are supposed to run on
> all sorts of platforms. Why does a megaraid controller need delays on
> i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most
> pla
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
program. The "little over" I don't worry a
On 11-12-07 14:50, David Newall wrote:
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be true
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be true if outb_p were used only in architecture d
On Tue, Dec 11, 2007 at 02:47:25PM +0100, Pavel Machek wrote:
> On Tue 2007-12-11 14:32:49, Andi Kleen wrote:
> > > The LPC bus behaviour is absolutely and precisely defined. The timing of
> > > the inb is defined in bus clocks which is perfect as the devices needing
> > > delay are running at a fr
On Tue 2007-12-11 14:32:49, Andi Kleen wrote:
> > The LPC bus behaviour is absolutely and precisely defined. The timing of
> > the inb is defined in bus clocks which is perfect as the devices needing
> > delay are running at a fraction of busclock usually busclock/2.
> >
> > Older processors did n
Hello,
On Tue, 11 Dec 2007 14:16:01 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 11-12-07 13:08, David Newall wrote:
>
> > Rene Herman wrote:
> (*) some local testing shows it to be almost exactly that for both out and
> in on my own PC -- a little over. If anyone cares, see attached litt
> The LPC bus behaviour is absolutely and precisely defined. The timing of
> the inb is defined in bus clocks which is perfect as the devices needing
> delay are running at a fraction of busclock usually busclock/2.
>
> Older processors did not have a high precision timer so you couldn't
> calibra
> I really *hate* the idea that access to non-present hardware is used to
> generate a delay. That sucks so badly. It's worthy of a school-aged
> hacker, not of a world-leading operating system. It's so not
> best-practice that it's worst-practice.
Actually its very good practice.
The LPC b
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be the delay on the i386 (sic) architecture
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port 0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
which certainly for anything modern means a fixed, unchanging value
(someth
Hi,
On Tue, 11 Dec 2007 12:12:59 +1030
David Newall <[EMAIL PROTECTED]> wrote:
> H. Peter Anvin wrote:
> > David Newall wrote:
> >
> > I think a single ISA bus transaction is 1 µs, so two of them back to
> > back should be 2 µs, not 8 µs...
>
> Exactly. You think it's 2us, but the documentatio
On 11-12-07 02:25, H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transa
Alan Cox wrote:
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
Yes it does. The branding spec said "No ISA bus" so it was renamed "LPC"
and hidden internally, but its alive and well.
Well that, plus it was serialized and uses PCI electricals and timing,
he
Andi Kleen wrote:
My machine in question, for example, needs no waiting within CMOS_READs
at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years) who required IO dela
David Newall wrote:
Exactly. You think it's 2us, but the documentation doesn't say. The _p
functions are generic inasmuch as they provide an unspecified delay.
Drivers which work across platforms, and which use _p, therefore have
different delays on different platforms. Should the length
David Newall wrote:
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus trans
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so tw
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so two of them back to
back
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
Rene Herman wrote:
By the way, David, it would be interesting if you could test 0xed. If
your problem is some piece of hardware getting upset at LPC bus aborts
it's not going to matter and we'd know an outb delay is just not an
option on your system at least. You said you could quickly reprod
On Monday 10 December 2007 12:30:53 Krzysztof Halasa wrote:
> Rene Herman <[EMAIL PROTECTED]> writes:
> > Alan, did you double-check that 8 us? I tried to but I seem to not
> > have trustworthy documentation.
>
> I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
> that means at le
On 10-12-07 12:30, Krzysztof Halasa wrote:
Rene Herman <[EMAIL PROTECTED]> writes:
Alan, did you double-check that 8 us? I tried to but I seem to not
have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1 Maccesses/second = u
> Really?
>
> udelay() seems to use
> ... cpu_data(raw_smp_processor_id()).loops_per_jiffy ..
Ok that should be a good safety
>
> ..so it seems that bug trap is already there... because
> raw_smp_processor_id() will probably just oops...
And I double checked my docs - they say 8 cycles - 1uS
Rene Herman <[EMAIL PROTECTED]> writes:
> Alan, did you double-check that 8 us? I tried to but I seem to not
> have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1 Maccesses/second = up to 1 microsecond/access.
Perhaps IO ports
On 09-12-07 22:25, Pavel Machek wrote:
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
Yes, i guess switching to udelay at least on newer systems would
be a good idea. I'm not quite sure about systems without TSC though.
Something like this? (Warning, will not probably even compile on
x86-64
On Sun 2007-12-09 22:29:28, Alan Cox wrote:
> On Sun, 9 Dec 2007 22:25:13 +0100
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
> > > > I mean, we expect 8usec delay -- historical ISA timing -- but when
> > > > _PCI_ card with leds is inserted, it is l
On Sun, 9 Dec 2007 22:25:13 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
> > > I mean, we expect 8usec delay -- historical ISA timing -- but when
> > > _PCI_ card with leds is inserted, it is likely to be faster than old
> > > ISA, right?
> >
> > Y
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
> > I mean, we expect 8usec delay -- historical ISA timing -- but when
> > _PCI_ card with leds is inserted, it is likely to be faster than old
> > ISA, right?
>
> Yes, i guess switching to udelay at least on newer systems would
> be a good idea. I'm
On Sat 2007-12-08 14:25:02, David P. Reed wrote:
>
>
> Alan Cox wrote:
> >
> >0x80 should be fine for anything PC compatible anyway,
> >its specifically
> >reserved as a debug port and supported for *exactly*
> >that purpose by
> >many chipsets.
> >
> >
> Disagree. The definitions of PC compa
> I mean, we expect 8usec delay -- historical ISA timing -- but when
> _PCI_ card with leds is inserted, it is likely to be faster than old
> ISA, right?
Yes, i guess switching to udelay at least on newer systems would
be a good idea. I'm not quite sure about systems without TSC though.
-Andi
--
On Sunday 09 December 2007 13:54:58 you wrote:
> Hi!
>
> > > modern CPU compared to the bus. But the delay really needs to be
> > > something that is about IO port speed. Ok in theory you could try to
> > > measure a outb using RDTSC and then use udelay, but first you would
> > > need
> >
> > You d
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
> Actually, I've seen few pci cards with leds on port 0x80, and I
> wonder: is our outb_p really correct?
>
> I mean, we expect 8usec delay -- historical ISA timing -- but when
> _PCI_ card with leds is inserted, it is likely to be faster than old
>
Hi!
> > modern CPU compared to the bus. But the delay really needs to be something
> > that is about IO port speed. Ok in theory you could try to measure
> > a outb using RDTSC and then use udelay, but first you would need
>
> You don't need to. Port 0x80 historically is about 8uS so just udelay(
On 08-12-07 20:25, David P. Reed wrote:
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
A bus is not something with expansion slots. Your machine has an ISA bus, or
LPC rather, if only to hang its BIOS of. That earlier report about BIOS
chips shitting themse
> The point here is that Linux is NOT using a defined-to-be "unused"
> port. It IS using the "diagnostic" port, and talking to a diagnostic
> device that *is* used, and may be present.
Just like millions of other pieces of software from the same era.
> 2) Start a background task with the main
I am going to do a test on another "unused" port.
However, I realized as I was thinking about this. 0x80 is the
"diagnostic device" port. It is not an "unused" port.
Normally, Linux would support a device like the diagnostic device by
providing a character device, called /dev/post-diagnosis
> In any case, my machine does not have an ISA bus. Why should it? It's
> a laptop!
Yes it does. The branding spec said "No ISA bus" so it was renamed "LPC"
and hidden internally, but its alive and well.
> has already serviced the bus and delivered data! Why put many
> microseconds into the
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
>
>
> Alan Cox wrote:
> >
> >0x80 should be fine for anything PC compatible anyway, its specifically
> >reserved as a debug port and supported for *exactly* that purpose by
> >many chipsets.
> >
> >
> Disagree. The definitions of PC
Alan Cox wrote:
0x80 should be fine for anything PC compatible anyway, its specifically
reserved as a debug port and supported for *exactly* that purpose by
many chipsets.
Disagree. The definitions of PC compatible are quite problematic. I
have the advantage over some of you young guys,
On Wed, Dec 05, 2007 at 11:10:39AM +, Pavel Machek wrote:
> On Fri 2007-12-07 09:50:26, David P. Reed wrote:
> > My machine in question, for example, needs no waiting
> > within CMOS_READs at all. And I doubt any other
> > chip/device needs waiting that isn't already provided by
> > the bu
> > 8uS is an ISA bus transaction.
>
> You very likely know better but just in case you're confused -- I thought it
> was 8 cycles...
I'll double check. Its a long time since I stuck a scope on an ISA bus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Fri 2007-12-07 09:50:26, David P. Reed wrote:
> My machine in question, for example, needs no waiting
> within CMOS_READs at all. And I doubt any other
> chip/device needs waiting that isn't already provided by
> the bus. the i/o to port 80 is very, very odd in this
> context. Actually, m
On 07-12-07 19:42, Alan Cox wrote:
On Fri, 07 Dec 2007 19:45:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
On 07-12-07 18:19, Alan Cox wrote:
On Fri, 7 Dec 2007 17:31:16 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
a
On Fri, 07 Dec 2007 19:45:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 07-12-07 18:19, Alan Cox wrote:
>
> > On Fri, 7 Dec 2007 17:31:16 +0100
> > Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> >>> You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
> >>> and make sure
On 07-12-07 18:19, Alan Cox wrote:
On Fri, 7 Dec 2007 17:31:16 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and make sure the initial default delay is conservative enough before the
How would you make it conservative enou
On Fri, 7 Dec 2007 17:31:16 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
> > and make sure the initial default delay is conservative enough before the
>
> How would you make it conservative enough handling let's say a 6Gh
> You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
> and make sure the initial default delay is conservative enough before the
How would you make it conservative enough handling let's say a 6Ghz CPU
that can execute multiple jumps per cycle?
-Andi
--
To unsubscribe from th
On 07-12-07 16:43, Rene Herman wrote:
On 07-12-07 15:54, Andi Kleen wrote:
My machine in question, for example, needs no waiting within
CMOS_READs at all. And I doubt any other chip/device needs waiting
that isn't
I don't know about CMOS, but there were definitely some not too ancient
sy
> modern CPU compared to the bus. But the delay really needs to be something
> that is about IO port speed. Ok in theory you could try to measure
> a outb using RDTSC and then use udelay, but first you would need
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and make sur
On 07-12-07 15:54, Andi Kleen wrote:
My machine in question, for example, needs no waiting within CMOS_READs
at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years)
> My machine in question, for example, needs no waiting within CMOS_READs
> at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years) who required IO delays in the
floppy
Andi Kleen wrote:
Changing the delay instruction sequence from the outb to short jumps
might be the safe thing.
I don't think that makes sense to do on anything modern. The trouble
is that the jumps will effectively execute near "infinitely fast" on any
modern CPU compared to the bus. But the de
1 - 100 of 109 matches
Mail list logo
