Messages in this thread |  | | | From | Peter Desnoyers <> | | Subject | Re: New resources - pls, explain :-( | | Date | Mon, 16 Aug 1999 12:54:13 -0400 (EDT) |
| |
Benjamin Herrenschmidt wrote: > > Basically, as Paul Mackerras noticed, there are cases when you move bunch > of byte datas 32 bits at a time (or 16 bits at a time) between the HW > device and system memory where you just need no swapping, whatever endian > is current on your platform. And of course, in those cases, you also want > maximum performances.
If you wanted max performance, you wouldn't issue reads over PCI :-)
Honestly, it's quite possible that any overhead from byteswaps would be swamped by the bus latency, which is going to be hundreds of CPU clocks on today's machines. (although as anecdotal evidence to the contrary, we just squashed a bug in our linux driver that never surfaced in our NT driver, because the NT bus macros evidently gave the chip just enough extra time to recover after a reset. We don't want to lose that performance edge, even if it cost me a day with a PCI analyzer.)
Actually, by the time I finished my last posting, calling for little-endian and native-endian read/writes, I had managed to convince myself that the right answer is really really fixed little-endian and big-endian primitives, because the driver always knows the endian-ness of the hardware. If that endian-ness is variable - a rather esoteric case - then the driver knows about that, too, and can do the work to deal with it.
This has the nice feature that I can write a driver for a normal device on a little-endian machine without any #if-endian nonsense, and then recompile and run it on a big-endian machine. Except that I can already do that today - the only change this makes is to bring native bigendian hardware (oddball PCI cards, NuBus, SBus) into the readl/writel fold, a task which might be of more importance if people were making more new cards for them...
(which brings up my confusion over Linus' definition of "PCI-like". In prior lives I worked on 68K systems, and now I'm working on a PCI card that has only memory regions, not I/O ones, so I guess I tend to think of all I/O as memory-mapped, with in/out defining a weird separate address space. I have a hard time figuring out a definition of PCI-like that allows my card and PCI on an UltraSparc but excludes NuBus and SBus.)
-- ............................................................................ Peter Desnoyers Giganet Inc. 162 Pleasant St. (617) 661-1979 pjd@fred.cambridge.ma.us Cambridge, Mass. 02139 (978) 461-0402 (work) pjd@giga-net.com - 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/
|  |