linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Mike Frysinger <vapier@gentoo.org>
Subject: Re: [RESEND PATCH 2/4] asm-generic: io: don't perform swab during {in,out} string functions
Date: Tue, 23 Oct 2012 12:25:56 +1100	[thread overview]
Message-ID: <1350955556.2728.18.camel@pasglop> (raw)
In-Reply-To: <CAMuHMdWH3GXJ_dW-FCAX=LAkBuQmQtwRUtNpcqg_afm-UFK_2g@mail.gmail.com>

On Thu, 2012-10-18 at 07:48 +0200, Geert Uytterhoeven wrote:

> So assume you have the bytestream "Hello, world!\n" in memory on the
> PCI device.I.e.
> 
> 00000000  48 65 6c 6c 6f 2c 20 77  6f 72 6c 64 21 0a        |Hello, world!.|
> 
> You want to copy it to system RAM using readsl(), which does:
> 
>                u32 *buf = buffer;
>                do {
>                        u32 x = __raw_readl(addr + PCI_IOBASE);
>                        *buf++ = x;
>                 } while (--count);
> 
> On little endian, the first __raw_readl() should return "0x6c6c6548", so
> it is stored correctly by "*buf = x ".

Right.

> On big endian, the first __raw_readl() should return "0x48656c6c" instead,
> else it's stored incorrectly by "*buf = x ".
> But the PCI bus is little endian, so I expect __raw_readl() would return
> "0x6c6c6548", and thus needs swapping?

No. The PCI bus will return 0x48656c6c.

This is due to how the PCI bus is wired to the CPU bus, which is called
"byte address invariant". When doing a read of your byte 0, the CPU will
effectively read 0 with byte enables picking 48. Since the CPU wants
the first byte in the MSB, the bus must be wired up to the CPU such that
the MSB is the first byte in address order.

This is how a BE CPU is normally wired to a LE bus. The fact that a
register needs to be swapped comes from the fact that the device will
put the MSB in the higher address byte, which then corresponds to the
LSB on the BE CPU -> needs swapping.

But for a byte stream, as you can see, no swapping is required.

To some extent, it looks as if the wiring is byte swapped, in order to
provide the byte address invariance (and thus causes registers to look
byteswapped) but it's really not, it's just a convention.

> On m68k (classic with MMU), the situation is a bit more complicated, as some ISA
> (or PCMCIA) busses are physically wired swapped. But inw() and insw() always do
> either both swapping, or both no swapping. The state of support for ISA drivers
> is a bit vague, though.

Then something is horribly wrong in those m68k setups :-) Either in the
way the busses are wired or in your implementation of either inw or
insw.

> Now, on m68k without MMU, inw() doesn't do swapping, but insw() does.
> This agrees more or less with you and Will, except that the bus seems to be
> physically swapped?

Yeah that's possible. In the early days people incorrectly thought it
would be smart to do that, thus avoiding a byteswap for register
accesses .... and causing all data (DMA or FIFO) to be all backward.

That's for example why the disks in the Tivo are byteswapped 16-bit by
16-bit on the platter (ie, all the data is).

I wouldn't be surprised if some 68k suffered from similar HW designer
stupidity.

But the "proper" generic rule is byte address invariance, and that
implies swap on register access and no swap on byte streams.

Cheers,
Ben.


> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2012-10-23  1:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-17 15:45 [RESEND PATCH 0/4] Fix endianness of generic I/O accessors Will Deacon
2012-10-17 15:45 ` Will Deacon
2012-10-17 15:45 ` [RESEND PATCH 1/4] asm-generic: io: remove {read,write} string functions Will Deacon
2012-10-17 15:45   ` Will Deacon
2012-10-26 13:29   ` Arnd Bergmann
2012-10-26 13:38     ` Will Deacon
2012-10-26 13:38       ` Will Deacon
2012-10-17 15:45 ` [RESEND PATCH 2/4] asm-generic: io: don't perform swab during {in,out} " Will Deacon
2012-10-17 15:45   ` Will Deacon
2012-10-17 19:16   ` Geert Uytterhoeven
2012-10-18  0:04     ` Benjamin Herrenschmidt
2012-10-18  5:48       ` Geert Uytterhoeven
2012-10-19 12:53         ` Will Deacon
2012-10-23  1:25         ` Benjamin Herrenschmidt [this message]
2012-10-23  1:25           ` Benjamin Herrenschmidt
2012-10-28  9:28           ` Geert Uytterhoeven
2012-10-28 20:38             ` Benjamin Herrenschmidt
2012-10-18  0:01   ` Benjamin Herrenschmidt
2012-10-17 15:45 ` [RESEND PATCH 3/4] mmc: mmci: use io{read,write}*_rep accessors instead of " Will Deacon
2012-10-17 15:45   ` Will Deacon
2012-10-17 15:45 ` [RESEND PATCH 4/4] net: smc91x: " Will Deacon
2012-10-17 15:45   ` Will Deacon
2012-10-19  8:25   ` James Hogan
2012-10-19  8:25     ` James Hogan
2012-10-19  9:27     ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1350955556.2728.18.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vapier@gentoo.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).