All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 8 Jun 2005 09:01:03 -0700	[thread overview]
Message-ID: <20050608090103.A32468@cox.net> (raw)
In-Reply-To: <609b05dd2d9806d7d1cd68696b1f49e2@freescale.com>; from kumar.gala@freescale.com on Wed, Jun 08, 2005 at 10:34:03AM -0500

On Wed, Jun 08, 2005 at 10:34:03AM -0500, Kumar Gala wrote:
> 
> 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 :)

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>

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

  reply	other threads:[~2005-06-08 16:01 UTC|newest]

Thread overview: 19+ 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 ` Matt Porter
2005-06-06 22:40 ` [PATCH][2/5] RapidIO support: core includes Matt Porter
2005-06-06 22:40   ` Matt Porter
2005-06-06 22:40   ` [PATCH][3/5] RapidIO support: core enum Matt Porter
2005-06-06 22:40     ` Matt Porter
2005-06-06 22:40     ` [PATCH][4/5] RapidIO support: ppc32 Matt Porter
2005-06-06 22:40       ` Matt Porter
2005-06-06 22:40       ` [PATCH][5/5] RapidIO support: net driver Matt Porter
2005-06-06 22:40         ` Matt Porter
2005-06-08  4:43       ` [PATCH][4/5] RapidIO support: ppc32 Kumar Gala
2005-06-08  4:43         ` Kumar Gala
2005-06-08  5:52         ` Matt Porter
2005-06-08 15:34           ` Kumar Gala
2005-06-08 15:34             ` Kumar Gala
2005-06-08 16:01             ` Matt Porter [this message]
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=20050608090103.A32468@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 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.