From: "Alexey Zaytsev" <alexey.zaytsev@gmail.com>
To: "Kyle McMartin" <kyle@mcmartin.ca>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: ioread32 endianess.
Date: Tue, 27 Feb 2007 17:36:22 +0300 [thread overview]
Message-ID: <f19298770702270636j2c03f537je578768b33d95237@mail.gmail.com> (raw)
In-Reply-To: <20070227135535.GD3545@athena.road.mcmartin.ca>
On 2/27/07, Kyle McMartin <kyle@mcmartin.ca> wrote:
> On Tue, Feb 27, 2007 at 08:20:21AM -0500, Kyle McMartin wrote:
> > PCI is always little endian, unless it's not. In which case you're probably
PCI is always LE, but the host may be different. If you read some data
from a PCI device
on a LE host, the data would be OK, but on a BE host, you may need to
swap it. Right?
More fun comes when you are doing DMA...
> > dealing with a graphics card which likely has some kind of palindromic
> > register which you can read and write to set the endianness of the host
> > interface. Whoo. Run on sentence.
> >
>
> Perhaps we should have a Documentation/ entry for this...
>
> io(read|write){8,16,32} are the "pci iomap" functions (see
> asm-generic/iomap.h) they always byteswap so the value is little endian.
They do even if the target bus is not little endian, right?
>
> io(read|write){8,16,32}be are sister functions added to deal with big
> endian busses. They always byteswap so the value is in big endian.
>
> Both these previous functions can handle using a cookie based on an IO port
> range, or an MMIO region.
>
> (read|write){b,w,l} are the old style MMIO-mapped accessors. They also always
> byteswap so the value is in little endian. There is no big endian equivalent
> for the generic case.
>
> __raw_(read|write){b,w,l} are also old style accessors. They always operate
> in host endianness.
>
> The above are (AFAIK) the only functions guaranteed to exist for MMIO.
>
> Of course, most platforms either provide (in|out){b,w,l} or don't support
> Port IO as well, but MMIO is the really complicated case.
>
> In any event, <asm-generic/iomap.h> should shed a bit more light on using
> these.
>
> Cheers,
> Kyle M.
>
prev parent reply other threads:[~2007-02-27 14:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-26 15:36 ioread32 endianess Alexey Zaytsev
2007-02-26 16:04 ` Kyle McMartin
2007-02-27 12:31 ` Alexey Zaytsev
2007-02-27 13:20 ` Kyle McMartin
2007-02-27 13:55 ` Kyle McMartin
2007-02-27 14:27 ` Haavard Skinnemoen
2007-02-27 14:36 ` Alexey Zaytsev [this message]
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=f19298770702270636j2c03f537je578768b33d95237@mail.gmail.com \
--to=alexey.zaytsev@gmail.com \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
/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