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
next prev parent 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$(echo .)caltech.edu \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=markc@mail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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