Messages in this thread | | | Subject | Re: New resources - pls, explain :-( | From | Jes Sorensen <> | Date | 16 Aug 1999 22:00:44 +0200 |
| |
>>>>> "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/
| |