From: Matt Porter <mporter@kernel.crashing.org>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH][4/5] RapidIO support: ppc32
Date: Tue, 7 Jun 2005 22:52:10 -0700 [thread overview]
Message-ID: <20050607225210.A28898@cox.net> (raw)
In-Reply-To: <3648449bcd3a154bcf9b92930f74f3d9@freescale.com>; from kumar.gala@freescale.com on Tue, Jun 07, 2005 at 11:43:26PM -0500
On Tue, Jun 07, 2005 at 11:43:26PM -0500, Kumar Gala wrote:
> Two questions:
> 1. how well does will all of this handle > 32-bit phys addr?
It does and it doesn't handle > 32-bit phys addr. It depends on which
configuration you are talking about. If you are talking about I/O
>32-bit, it's no problem. If you are talking about handling DMA >32-bit,
then we need to handle a 64-bit DMA addr in the ppc32 implementations and
also extend the arch messaging interface to let callers know when an
implementation can handle high DMA (system memory >4GB). This is all
pretty easy to handle once we need to support such a processor. So
far, nothing is available publicly. :)
For RIO MMIO purposes (which is functionality I'm working on now),
it has the similar issues that PCI memory space has on processors with
I/O above 4GB. However, on RIO our resources hold a bus address since
a physical address doesn't make sense since address spaces our per-device.
If we ever support a 66-bit address space device on 32-bit processor, we
might need a u64 resource.
> 2. can we make any of this a platform driver?
Hrm, so you would rather see RIO host bridges look like a driver
on another "bus"? I have seen them as a component just like PCI
host bridges. That is, they are instantiated by arch-code and
then initialized by a subsys initcall. This does mean that we
will be enumerating much later (during driver initcalls), but
it might be a better model if we ever see a rumored PCIE->RIO
bridge. Supporting that as a RIO master port would require driver
time init of the RIO fabric. There's some ordering issues that we'd
have to see about working out. None of this is needed right now,
though.
> I would prefer if we could have the memory offsets and irq's not be
> straight from the #define's
I think this and #2 are separate issues. We can pass the mpc85xx
rio init code some parameters to abstract things to different
parts. This is similar to how we init different SoC's PCI host
bridges with some common code on PPC32 (marvell, 85xx, etc).
I was just looking at doing this to support RIO on the 8548. At
the time I wrote this 85xx support there wasn't any info on the
8548 available, but it's an easy thing to extend.
-Matt
next prev parent reply other threads:[~2005-06-08 5:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-06 22:40 [PATCH][1/5] RapidIO support: core base Matt Porter
2005-06-06 22:40 ` [PATCH][2/5] RapidIO support: core includes Matt Porter
2005-06-06 22:40 ` [PATCH][3/5] RapidIO support: core enum Matt Porter
2005-06-06 22:40 ` [PATCH][4/5] RapidIO support: ppc32 Matt Porter
2005-06-06 22:40 ` [PATCH][5/5] RapidIO support: net driver Matt Porter
2005-06-08 4:43 ` [PATCH][4/5] RapidIO support: ppc32 Kumar Gala
2005-06-08 5:52 ` Matt Porter [this message]
2005-06-08 15:34 ` Kumar Gala
2005-06-08 16:01 ` Matt Porter
2005-06-07 5:19 ` [PATCH][3/5] RapidIO support: core enum Zwane Mwaikambo
2005-06-07 21:14 ` Matt Porter
-- strict thread matches above, loose matches on Subject: below --
2005-06-02 21:03 [PATCH][1/5] RapidIO support: core Matt Porter
2005-06-02 21:12 ` [PATCH][2/5] RapidIO support: core includes Matt Porter
2005-06-02 21:19 ` [PATCH][3/5] RapidIO support: enumeration Matt Porter
2005-06-02 21:25 ` [PATCH][4/5] RapidIO support: ppc32 Matt Porter
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=20050607225210.A28898@cox.net \
--to=mporter@kernel.crashing.org \
--cc=kumar.gala@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-embedded@ozlabs.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;
as well as URLs for NNTP newsgroup(s).