lkml.org 
[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans