lkml.org 
[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: New resources - pls, explain :-(
From
Date
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

Linus> But the whole discussion started as a _byte_ order
Linus> discussion. And I still do not agree with _any_ of those
Linus> arguments. I will not call it "writel_na()", because I still do
Linus> not agree at all with the concept of making the IO thing
Linus> byte-order-dependent.

I am sorry, that was probably my mistake. The discussion did indeed
start as a byte order discussion. On the fbdev and ppc lists we ran
into the synchronization problem as we discovered that the view people
had on how how they believed writel() was working right now was quite
different. I should probably have made this more clear when I brought
it into the discussion here.

Linus> What you and others have convinced me about is to have a "raw"
Linus> interface. That is actually very different from what the
Linus> original discussion was about. It is not really about "native"
Linus> byte order at all: in fact the native IO byte order might be
Linus> different from the native CPU byteorder, so we might need to
Linus> use "io_to_le32()" instead of "cpu_to_le32()".

One should probably name this pci_to_le32() to avoid confusion with
other busses.

Linus> So think of "__writel()" as something completely different than
Linus> a byte-order issue: think of it as a "raw access". The byte
Linus> order it then just a small subset of the bigger picture.

Linus> Just as an extreme example: __writel() might not just re-order
Linus> and buffer, maybe the native IO interface needs explicit
Linus> flushing to make it out to the bus _at_all_, and might be
Linus> delayed indefinitely if there isn't an eventual accompanying
Linus> flush operation. You might want to allow caching of IO accesses
Linus> - and with a write-back cache it might not be flushed out to
Linus> the bus at all if the cache is big enough. Until somebody does
Linus> a "flush this region out to the bus NOW" operation.

I agree with you on the raw issue here and I must admit when you first
mentioned the io_mb() suggestion I first thought that mb() was more
than enough for us. However after thinking a bit more about it I
realized that mb() is overkill for some cases, ie. on some
architectures the PTE's have a bit that tells the CPU not to allow
reordering on those pages and then it is a waste to do a wmb() after
the __writel() (I have the impression this is the case for the Sparc64
for instance - someone with my knowledge on this feel free to correct
me if I am wrong).

Actually we probably should name these for pci_io[wr]b() or similar as
the acutal io barrier might be different between busses - or am I
overdesigning things here?

I see your point about __writel(io_to_le32(data), addr) now. However
having a pci_writel_cpuorder() (or something similarly named) it will
be possible to optimize this better than if one has to optimize
__writel() and io_to_le32() individually. Some architectures allows
for special stores that converts the data in one go etc.

Jes

-
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    [W:0.153 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site