All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hawkins <dwh@ovro.caltech.edu>
To: Mark Chambers <markc@mail.com>
Cc: "Linuxppc-Embedded \(\(E-Mail\)\)" <linuxppc-embedded@ozlabs.org>
Subject: Re: Memory mapping PCI memory region to user space
Date: Thu, 23 Mar 2006 12:26:41 -0800	[thread overview]
Message-ID: <44230481.5040500@ovro.caltech.edu> (raw)
In-Reply-To: <00c701c64eb3$c23b0c40$6401a8c0@CHUCK2>


Hi Mark,

> Ok, I should be a little more specific.

Ok :)

> Yes, I/O space is little endian, and any configuration
> registers and such are little endian.  But memory space
> is strictly 32 bit as far as PCI is concerned.
> (forgetting 64 bit PCI for the moment) The two lower
> bits of address are not used, and there is no required 
> correlation of byte enables to those missing address bits.
> 
> So, the point is, Freescale swaps bytes between its internal
> bus and PCI.  Other processors (like TI DSPs) do not.  I
> don't know that one method is necessarily right, but the fact
> that we have this discussion periodically suggests that Freescale's 
> method is not the best.

Hmm, I'd have to look on the PCI bus with the analyzer to
confirm this ... but I do recall seeing a mapping of
the 128-bit PLB to PCI bus in the 440EP manual, so
you're probably right.

The PLX PCI-9054 has an 'endianness' option like this too.
I believe its so you can use a PPC on the local bus, and
swap bytes when the are written onto the PCI bus.
Sounds like the Freescale SoC bridges have just hardcoded
that type of implementation.

> This might be an academic point, but I think it does help to
> see the distinction.  To talk to a device over PCI you must
> know how both ends map their internal buss(es) to PCI,
> and it's not directly a big/little endian issue.

Its nice to be aware of these subtle differences.

Thanks for the discussion.

Dave

  reply	other threads:[~2006-03-23 20:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-23 14:21 Memory mapping PCI memory region to user space Wyse, Chris
2006-03-23 15:44 ` Kumar Gala
2006-03-23 17:12   ` David Hawkins
2006-03-23 17:19     ` Kumar Gala
2006-03-23 17:43       ` Mark Chambers
2006-03-23 17:54         ` David Hawkins
2006-03-23 19:55           ` Mark Chambers
2006-03-23 20:26             ` David Hawkins [this message]
2006-03-23 17:46       ` David Hawkins
2006-03-27  8:02   ` Phil Nitschke
2006-03-27 16:05     ` David Hawkins
2006-03-28  4:21       ` Phil Nitschke
2006-03-28  4:55         ` David Hawkins
2006-03-28  6:44           ` Phil Nitschke
2006-03-28 16:35             ` David Hawkins
2006-03-27 16:18     ` Kumar Gala
2006-03-29  2:26       ` Phil Nitschke
2006-03-23 17:04 ` David Hawkins
  -- strict thread matches above, loose matches on Subject: below --
2006-03-23 19:52 Wyse, Chris
2006-03-23 20:01 ` Kumar Gala

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=44230481.5040500@ovro.caltech.edu \
    --to=dwh@ovro.caltech.edu \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=markc@mail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.