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

[Kumar Gala <kumar.gala@freescale.com>]

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

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

Well 8548 is semi-public :)

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

I assume you mean 36-bit, what would one do with 66-bit addresses :)

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

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

- kumar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/