Re: Linux and real device drivers

Momchil 'Velco' Velikov (velco@fadata.bg)
Wed, 22 Sep 1999 11:28:56 +0300

Jes Sorensen wrote:
>
> >>>>> "Bret" == Bret Indrelee <breti@bit3.com> writes:
>
> Bret> Jes Sorensen [mailto:Jes.Sorensen@cern.ch] wrote:
> >> Again, the last version of UDI I looked at was 0.80. Anyway, UDI
> >> means going through indirect functions to simply read/write a
> >> device register since you have no idea how a device is mapped in a
> >> certain type of machine or operating system .... this alone should
> >> be enough to prove my point.
>
> Bret> It does prove a point, but maybe not the one you intended.
>
> Oh yes it does.
>
> Bret> PCI bus normally runs at 33 MHz. It takes at least two clock
> Bret> cycles to do a write and can take much longer to do a read. This
> Bret> gives us roughly 60 ns minimum for a write transaction during
> Bret> which time the CPU can do nothing. On a read, many PCI devices
> Bret> will send a RETRY signal just to give themselves more time. This
> Bret> can be more in the range of 100s of ns to single digit ms for a
> Bret> device read.
>
> pre-fetching, write-back caching, nobody said all PCI writes have to
> be synchronous. No I don't really care about I/O port access.

Are you kidding? Do you really want to use that on device's registers ?

>
> Bret> Modern processors are in excess of 200 MHz. That would come out
> Bret> to about 5 ns/cycle. The processor can execute 12 instructions
> Bret> in the time it takes to do the minimum PCI cycle. That should be
> Bret> more than enough time to do a minimal subroutine call. The
> Bret> faster your processor, the worse it gets.
>
> Faster your processor, the deeper your pipeline, branch == pipeline
> flush. next?

Ok, branch has a penalty but it's certainly != pipeline flush.
Note that this is unconditional branch, and if the branch target address
is computed sufficiently ahead of the branch instruction there will be
no penalty.

> And here you might want to look at some of the released
> documentation on the IA64 to see what we might expect from the future,
> branches are expensive.

Have Intel released docs about some implementation of the architecture ?
OTOH, judging from past experience, I wan't be surprised
if Intel ain't got it Right *again*. (OK, OK, just kidding,
people (and companies) sometimes grow up and learn things :-)

Regards,
-velco

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