Re: [PATCH][4/5] RapidIO support: ppc32

On Wed, Jun 08, 2005 at 10:34:03AM -0500, Kumar Gala wrote:

On Jun 8, 2005, at 12:52 AM, Matt Porter wrote:

quoted

On Tue, Jun 07, 2005 at 11:43:26PM -0500, Kumar Gala wrote:

quoted

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

quoted

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. :)

Well 8548 is semi-public :)

Heh, well my definition is when Fscale has the reference manual
downloadable from the main website...as of last night that wasn't
the case for 8548. :)

<snip>

quoted

quoted

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.

Agreed, they are separate issues, I'm cool on waiting to see what 
happens with RIO <-> PCIE bridges in the future.  For now if you can 
look at abstracting the offset, irq info that would be good (especially 
since 8548 does msg'g a bit differently).

No problem. The first "ppc85xx_rio.c" was only intended to work on
the 8540/8560 stuff where I had hardware. From my look at 8548, it
shouldn't take much work.

-Matt