From: Phil Terry <pterry@micromemory.com>
To: galak@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org, Zhang Wei-r63237 <Wei.Zhang@freescale.com>
Subject: RE: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
Date: Wed, 23 May 2007 08:37:37 -0700 [thread overview]
Message-ID: <1179934657.11247.14.camel@pterry-fc6.micromemory.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0705230916170.535@localhost.localdomain>
On Wed, 2007-05-23 at 09:21 -0500, Kumar Gala wrote:
> On Wed, 23 May 2007, Zhang Wei-r63237 wrote:
>
> > > So I'm taking the boot/dts/mpc8641_hpcn.dts and producing a new
> > > mpc8641D_umem.dts with the following addition to the soc.
> > >
> > > srio@c0000 {
> > > device_type = "srio";
> > > compatible = "86xx,85xx";
>
> We really need to think about this, is their really any difference between
> srio and prio from a software view point?
I didn't mean to imply that, the above was just my strawman for
discussion purposes in my overview question. As per a suggestion I was
now calling it rapidio@c0000.
But maybe this is moot, the patches are on their way (yippee) Thanks
Zhang.
>
> > > reg = <c0000 20000>;
> > > law = <400000000 e00000000>;
> >
> > Please use range = <0 address_start size>
>
> The law should really be removed.
In my application I'm may be using a huge part of the 36-bit address
space to address multiple remote RIO boards in a peer DMA multicomputer
application. The default law just for maintenance messages isn't going
to cut it. Now I suppose we could say that my DMA oriented driver should
be responsible for another law for that purpose but that seemed wasteful
to me, there aren't that many laws to go around. So I wanted to hijack
and make this one configurable. But this was just my first idea so I'm
open to suggestions.
>
> >
> > > dbells = <0 ffff>;
> > > mboxs = <0 4>;
> >
> > The dbells and mboxs can be removed. The default setting in rio is okay.
>
> this could possibly be useful.
Again, the current setup seems to be the minimum required to support
rionet. The hardware can support multiple mailboxes as is not just mbox
0 used by rionet. As I understand it one message unit is dedicated to
mbox 0 and mboxes 1 to 63 are used by the second message unit. I want in
my application to use the "clean" mbox 0 for my apps messaging and
relegate rionet to mbox 1. So in the interests of generality I wanted to
make the number of mboxes supported configurable. Is this something I
should not do in dts but relegate somewhere else?
The doorbells is debatable. There is only a single unit supporting all
doorbells in extant hardware (AFAIK) so this was again for generality in
case a dual doorbell hw unit arrives.
>
> >
> > > interrupt-parent = <&mpic>;
> > > interrupts = <30 1 31 1 32 1 35 1 36 1 37 1 38 1>;
> > > };
> > >
> > Do you really use all of this interrupts? In my test, three <32 2 35 2
> > 36 2> are okay, and the sense is 2.
>
> I think we need to list all the interrupts possible from RIO, not just the
> ones the driver happens to use.
Sorry about the senses, again I just threw that in the email as a
strawman to kick off discussion (which now seems moot as Wei has the
patches (yippee)). The second set of interrupts 37 and 38 are for the
second message unit which I want to use (see above). 30 is for
port-write/error which I will be using to get interrupts from my
switches for topology changes. 31 is the out doorbell done which the
driver doesn't use cos of the synchronous nature of the out doorbell I
suppose.
>
> - k
>
>
next prev parent reply other threads:[~2007-05-23 15:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-22 19:38 Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D Phil Terry
2007-05-22 20:08 ` Segher Boessenkool
2007-05-22 20:09 ` Timur Tabi
2007-05-22 23:05 ` Arnd Bergmann
2007-05-24 6:48 ` Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D Zhang Wei-r63237
2007-05-24 9:19 ` Arnd Bergmann
2007-05-24 9:44 ` Zhang Wei-r63237
2007-05-24 11:27 ` Arnd Bergmann
2007-05-23 13:26 ` Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D Zhang Wei-r63237
2007-05-23 13:32 ` Mark A. Greer
2007-05-23 14:03 ` Zhang Wei-r63237
2007-05-23 15:42 ` Phil Terry
2007-05-23 15:53 ` Mark A. Greer
2007-05-23 15:54 ` Phil Terry
2007-05-23 14:21 ` Kumar Gala
2007-05-23 15:37 ` Phil Terry [this message]
2007-05-23 16:05 ` Segher Boessenkool
2007-05-23 16:20 ` Phil Terry
2007-05-23 16:20 ` Kumar Gala
2007-05-23 16:43 ` Phil Terry
2007-05-23 23:17 ` Segher Boessenkool
2007-05-23 23:05 ` Segher Boessenkool
2007-05-24 7:31 ` Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D Zhang Wei-r63237
2007-05-23 16:00 ` Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D Segher Boessenkool
2007-05-23 16:13 ` Phil Terry
2007-05-24 0:52 ` David Gibson
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=1179934657.11247.14.camel@pterry-fc6.micromemory.com \
--to=pterry@micromemory.com \
--cc=Wei.Zhang@freescale.com \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@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).