Messages in this thread | | | Date | Sun, 15 Aug 1999 11:42:42 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New resources - pls, explain :-( |
| |
On 15 Aug 1999, Jes Sorensen wrote: > > Sorry I do not get your point here, you are saying that if one wants > to use __writel() then he/she will have to handle byte swapping on big > endian architectures manually? That means if I say write a Gigabit > Ethernet driver and I want to optimize it maximally then I am going to > use __writel() on the x86 and Alphas because those are the machines I > have access to. Now someone wants to use the driver to Linux/PPC and > suddenly all hell breaks lose because __writel() doesn't byteswap so > this person will have to modify the driver in order to make it run at > all.
Indeed. It's not the first time that would happen.
> Yes this will work, but it is going to make it impossible to use > __writel() for traditional PCI access as I described above unless I > define my own versions of writel in the driver to do > > #define __l_writel(x,y) __writel(cpu_to_le32(x),y)
Well, you could do that.
A well-written driver would not. A well-written driver will usually have something like
#define read_device(dev,offset) \ readl((dev)->mapping+(offset)) #define write_device(dev,offset,data) \ __writel(cpu_to_le32(data), (dev)->mapping+(offset)
but admittedly rather few of them are right now.
> If you read some of my previous postings then you'd remember that I > was arguing for a native byte order in the first place, you were the > one who brought the explicit big endian version into the discussion.
I was wrong.
But the whole discussion started as a _byte_ order discussion. And I still do not agree with _any_ of those arguments. I will not call it "writel_na()", because I still do not agree at all with the concept of making the IO thing byte-order-dependent.
What you and others have convinced me about is to have a "raw" interface. That is actually very different from what the original discussion was about. It is not really about "native" byte order at all: in fact the native IO byte order might be different from the native CPU byteorder, so we might need to use "io_to_le32()" instead of "cpu_to_le32()".
So think of "__writel()" as something completely different than a byte-order issue: think of it as a "raw access". The byte order it then just a small subset of the bigger picture.
Just as an extreme example: __writel() might not just re-order and buffer, maybe the native IO interface needs explicit flushing to make it out to the bus _at_all_, and might be delayed indefinitely if there isn't an eventual accompanying flush operation. You might want to allow caching of IO accesses - and with a write-back cache it might not be flushed out to the bus at all if the cache is big enough. Until somebody does a "flush this region out to the bus NOW" operation.
Linus
- 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/
| |