lkml.org 
[lkml]   [1999]   [Aug]   [15]   [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> 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.106 / U:0.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site