Re: New resources - pls, explain :-(

Peter Desnoyers (pjd@fred001.dynip.com)
Fri, 13 Aug 1999 14:36:10 -0400 (EDT)


Linus Torvalds wrote:
>
> In short, I still don't see why not just have a "bigendian_writel()" is so
> hard to accept for people.

If I follow correctly, then:

readl/writel swaps on bigendian, not on littleendian
bigendian_readl/writel swaps on littlendian, not no bigendian ?

The only cases I have insight into are PCI drivers, where the swapping
points on bigendian machines can be:

- none, all device registers are little-endian
- on the motherboard, flip all memread32/memwrite32 but no DMA access
(the hardware folks at work believe this exists somewhere, but I haven't
seen it)
- on the motherboard, selectable on a page-by-page basis (ultrasparc?)
- on the card - one or more areas can be configured to flip byte order
to big-endian

I'm assuming that there are no PCI devices where device registers are
always big-endian. (is that true for all weird Mac cards?) Handling of
cases is:

1. The driver knows the hardware is little-endian, and always uses
readl/writel.

2. Kernel/arch knows the hardware, and defines readl/writel, etc. properly.
(i.e. no software swap in readl) The driver works like (1).

3,4. The driver sets the swapping inside an #ifdef BIGENDIAN when first
setting up the hardware, and then uses native_readl/native_writel.

(Note that if the card does the swapping, it doesn't have to be a separate
memory region - it might just be a config bit that flips one or more
of the existing regions.)

However, there's probably a case for bigendian_readl/writel as well,
so that S-Bus drivers (S-Bus is native bigendian, I assume? I'm overly
ignorant of it) can co-exist with PCI drivers without any conditional
logic inside of the readl/writel functions. Like the other cases, the
driver knows the endianness of the hardware, and just uses the right
function without any #if BIGENDIAN messiness.

Does this make sense?

-- 
............................................................................
 Peter Desnoyers 
 162 Pleasant St.         (617) 661-1979          pjd@fred.cambridge.ma.us
 Cambridge, Mass. 02139   (978) 461-0402 (work)   pjd@giga-net.com 

- 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/