Another reply (my other mail should have given some answers on this already..)
> ---------- Forwarded message ----------
> Date: Sat, 14 Nov 1998 09:31:03 +0100 (MET)
> From: Gerard Roudier <groudier@club-internet.fr>
> To: "Jon M. Taylor" <taylorj@ecs.csus.edu>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: Accessing MMIO PCI space - crossplatform (fwd)
>
>
> On Fri, 13 Nov 1998, Jon M. Taylor wrote:
>
> The proposal from GGI folk looks fine but it is a SAASTDWDIOAI (TM).
> StillAnotherAbstractionsSetIntendedToDealWithBrainDamagedInOutArchitectureImplementations.
>
> The PCI recommendation is to have a flat model with unified memory/BUS
> physical addressing from all parts (I mean CPUs and BUSes). It seems
> that when it is easy to make things simple and hard to make them complex,
> architecture designers did prefer the latter.
>
> Just a question:
> If I choose a system that has a simple IO system design, how much will be
> the bloat and the overhead due to this proposal?
If you compare to a driver that hardcodes io-port addresses, e.g. like
outb(0x23, 0x3B0 + DATA_REG);
the overhead would be an data fetch plus one add instruction, as
io_out8(0x23, my_region.base_virt + DATA_REG);
would have to assume my_region->base_virt non-constant. Again, this is to
drive the io-ports which are slow anyway. (Except on 12Mhz 386 SX, I agree...)
However, for memory mapped I/O access there isn't much overhead, as you would
have to fetch the base address anyway, plus one add for the offset.
> Regards,
> Gerard.
>
> PS: my prefered way to make things portable is to use '#if' (preprocessed)
> contructs and not 'if' (run time) contructs. Any bloat or overhead due to
> portability issues is poor design in my opinion. I would prefer to use non
> portable code rather than to have code that checks at run time if my
> system is something different from what it actually is. BTW, I understand
> portability issues since my official work is to develop such kind of
> applications.
There ain't no run-time if's neccessary. The i386 implementation uses inlines
and with optimization this gives minimal overhead as pointed out above.
However, I used this scheme for several drivers (keyboard, Permedia2)
and it works perfectly for my purposes.
Again, this is an proposal, you may improve it, or point out the flaws
(what I would ask you to do :-), you are not forced to use it. I found it
very easy to learn, as you don't have to learn dozens of macros or function
names, just a few rules:
- to in/out functions, only virtual addresses have to be passed.
- to devices, only bus address must be passed.
- to do mapping, only physical addresses must be passed.
- You have to register the regions you want to access before
accessing them.
- when registering, you have to fill in device-specific capabilties
only. (No big thinking, 'May I pass this address to in/out(), can
I pass it to virt_to_phys, do I have to convert it first...')
So, to me, this scheme proved easy to use, robust and easy to learn.
Especially it is reasonably error-proof due to automatic strong
type-checking done by GCC. This pointed out bugs at _compile_time_
to me that otherwise would have gone unnoticed and caused me some
time spent bughunting.
Steffen
----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------
------------- The GGI Project: http://www.ggi-project.org --------------
-
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/