Re: iomapping a big endian area

From: Russell King (rmk+lkml_at_arm.linux.org.uk)
Date: 04/05/05

  • Next message: Jesper Juhl: "Re: [PATCH 0/4] cifs: cleanup asn1.c" 
    Date:	Tue, 5 Apr 2005 08:42:19 +0100
To: James Bottomley <James.Bottomley@SteelEye.com>

    On Sat, Apr 02, 2005 at 09:40:39PM -0600, James Bottomley wrote:
    > On Sun, 2005-04-03 at 04:10 +0100, Matthew Wilcox wrote:
    > > > SPARC64 can do it in the PTEs, but we just use raw physical
    > > > addresses in our I/O accessors, and in those load/store instructions
    > > > we can specify the endianness.
    > >
    > > Ah right. So you'd prefer an ioread8be() interface?
    >
    > Actually, ioread8be is unnecessary, but I was planning to add
    > ioread16/ioread32 and iowritexx be on be variants (equivalent to
    > _raw_readw et al.)

    Not so. There are two different styles of big endian. (Lets just face
    it, BE is fucked in the head anyway...)

    physical bus: 31...24 23...16 15...8 7...0

    BE version 1 (word invariant)
      byte access byte 0 byte 1 byte 2 byte 3
      word access 31-24 23-16 15-8 7-0

    BE version 2 (byte invariant)
      byte access byte 3 byte 2 byte 1 byte 0
      word access 7-0 15-8 23-16 31-24

    Depending on this and how your devices are wired up to such a bus, you
    may need to swap bytes in a word access, or munge the byte/half word
    address itself.

    And guess which architecture implements *both* of these... Grumble. 

    -- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Jesper Juhl: "Re: [PATCH 0/4] cifs: cleanup asn1.c"