Messages in this thread | | | Subject | Re: New resources - pls, explain :-( | From | Jes Sorensen <> | Date | 13 Aug 1999 09:40:07 +0200 |
| |
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
Linus> On 12 Aug 1999, Jes Sorensen wrote: >> Having a readl_na() would make sense on big endian machines with >> PCI busses since since some PCI cards (some gfx and network cards) >> will do the translation for you in hardware making it look like the >> card is native byte order. For 16 and 24 bit graphics for instance >> it is absolutely not fun doing the byte swapping in software.
Linus> But the point is _still_ that the driver needs to know. The Linus> driver needs to know which area to select, and in some cases Linus> the driver needs to put the card in the right endianness mode.
Certainly it does, but then again it also needs to know whether to pick readl() or readl_na() and a ton of other things.
Linus> In short, I have not heard a SINGLE argument for this being a Linus> generic feature. I _have_ heard tons of valid argument for Linus> fixing on a known byte-order, and I agree with them. And it's Linus> very obvious that little- endian is THE byteorder, nobody Linus> really even argues about that.
I don't disagree that little endian should be the default method for PCI access. What I was suggesting was an alternative function one can optionally use if you know that you can do it in the other order.
Linus> In short, I still don't see why not just have a Linus> "bigendian_writel()" is so hard to accept for people. The the Linus> drivers that know about the issue might do something like this:
This will solve the problem just fine, my arguing was basically that the native or no-swap versions will avoid a bunch of ifdef's in drivers, thats all. We can easily do things by defining bigendian_writel() if you prefer it that way I just felt the other solution was more elegant.
>> I do not disagree with your vme_readl() proposal. Well it would be >> nice if one could have a readl() that works for everybody but if >> one wants to support 256 PCI busses in a box it might be a little >> problematic.
Linus> Well, if it were just a case of the same type of bus, it Linus> probably wouldn't be too bad. They'd be mapped at different Linus> offsets, but that can be handled by ioremap() and friends. The Linus> trouble really starts when you have different kinds of buses Linus> that have different rules for how they can be accessed because Linus> of different coherency issues or similar (or different ways to Linus> handle non-existent addresses - you may end up having to use Linus> different address spaces for different buses).
Linus> That's why it is so much easier if the programmer explicitly Linus> states some extra information - on some hardware the things may Linus> end up being collapsed to the same case, but on other hardware Linus> there may be special rules for one of them.
The thing I was more interested in is when you have multiple types of adapters of some type with the same chips on them but attached to different busses. For busses that are somewhat similar it would be a nice solution around this but I agree it would be a hack.
Linus> For example, I've considered maybe having two kinds of Linus> "writel()" - one that does a synchronous write and does an Linus> implied write barrier, and one that says "I don't care if this Linus> write gets re-ordered with respect to other writes". On x86, Linus> the two are one and the same thing, because the MTRR's (or the Linus> page table bits) handle the difference in hardware. On other Linus> architectures they can end up being quite different, and have Linus> quite different performance characteristics. And it would be Linus> bad if "writel()" had to try to figure out the information by Linus> hand, when a programmer could just tell it what kind of access Linus> he was thinking of..
Oh yes thats another issue, right now nobody agrees whether the current writel is meant to be synchronous or not.
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/
| |