[SNIPPED...]
On Sat, 16 Sep 2000, [ISO-8859-1] Gérard Roudier wrote:
> > >
> > > In PCI, you donnot enable windows, but you enable/disable devices to
> > > generate and/or respond to transactions.
> >
> > Well really? From the programmers point-of-view, you have just enabled
> > some windows into address space. The word "transaction" has gotten way
> > too much visibility. The fact that some hardware mechanism has gotten
> > involved reading from and writing to a device means nothing except
> > that a write (if enabled) is posted. We don't bother thinking about
> > "transactions" when we write to SDRAM do we? To the programmer, we
> > write to it and it sticks. The fact that there was a hardware transaction
> > involving a read/modify/write of (usually) much more than our byte
> > isn't a concern.
>
> Hmmm... If you know what drivers have been written with such a limited
> "low skilled" CPU centric approach in mind, let me know. I will just avoid
> forever using the resulting crap.
>
I sure hope they all do. If any driver treats its I/O or memory
window into the device any different than it would for shared RAM
or decoded I/O ports, when access is provided by the PCI bus, then
the programmer is providing a lot of extra code/CPU cycles that
can't possibly do anything useful.
Once enabled, the PCI bus looks to the CPU (and hence the programmer
who writes stuff to be executed by the CPU) just like RAM and/or
IO ports. If there is no other activity on the PCI bus at the instant
that the CPU writes to your shared-memory window, the CPU will be
able to do this with no wait-states until the posted-write FIFO is
full. Any read, or write by another device, will force any posted-
writes to complete before they are allowed. This just makes sure that
what the CPU writes, are atomic to the CPU and to the device, without
incurring unnecessary wait-states for a device and bus that is slower
than the CPU.
Hardware does this, not software. If software is attempting to do
something that has already been done in hardware, then software is
wasting CPU cycles.
If a driver knows that its I/O port allocations have been obtained
from the PCI controller, then it need not insert any wait-states
into port reads and writes. Currently I/O wait states are obtained
by writing to port 0x80 in Linux. This puts, roughly, 300 ns between
successive port accesses. This is not necessary when using the
PCI bus. However, the overhead necessary to determine the kind of
port access to use, for every port access, wastes any CPU cycles
gained by not writing to that port.
The 'Bible' for the PCI bus seems to be "PCI System Architecture",
Tom Shanley and Don Anderson, MindShare Inc. ISBN 0-201-30974-2.
This book is over 800 pages long. Unfortunately, You have to get
roughly half-way through (page 309) until you get to anything useful
to the programmer. By that time, the programmer has learned a lot
of "buzz-words" that are best forgotten because they confuse the
whole issue. I just got through writing an entire BIOS. Once I got
thorough the "fluff", setting up all the PCI devices (including
a screen card) and all PnP devices, was a lot easier than reading
the first 19 chapters of that damn book.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:14 EST