Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D

[Phil Terry <pterry@micromemory.com>]

On Wed, 2007-05-23 at 11:20 -0500, Kumar Gala wrote:
> On Wed, 23 May 2007, Phil Terry wrote:
> 
> > On Wed, 2007-05-23 at 18:05 +0200, Segher Boessenkool wrote:
> > > >> 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.
> > >
> > > If the firmware sets up the "law", it should put a property
> > > in the node describing the setting.  If Linux sets up the
> > > laws, there shouldn't be a property (since it is a policy
> > > decision).
> > Ooops, I just posted a question to you before I saw this pop up sorry?
> >
> > But when you say "firmware" do you mean u-boot or your kernel loading
> > code or do you mean some aspect of the hardware, eg, its EEPROM program
> > which can vary from hardware to hardware instantiation?
> >
> > If you mean u-boot I'm confused (so whats new?). AFAIK u-boot can't
> > probe and set this up and even if it did, linux in the arch's I'm
> > familiar with sets everything up anew regardless of what the boot loader
> > did. AFAIK in the freescale processors the dtb is being passed in from
> > u-boot as a supplied with the kernel build "blob" not because it built
> > it dynamically. Or again have I got hold of the wrong end of the stick?
> 
> That's mostly true, but you are looking at it from one implementations
> point of view, not from how its architected.  In the future we may (and I
> will) have u-boot capable of doing more dynamic building of the device
> tree or someother firmware.  All the kernel knows is its handed a device
> tree.

OK, but if the device tree is not allowed to dictate policy, to use
Segher's term, just hardware characteristics, how does that help us get
the embedded soc kernels away from being designed and built to specific
demo/eval board setups and make them more configurable? 

I got the impression that to some extent thats how you/we/?? were trying
to use the dts stuff. If my board is exactly like freescales xyz demo
board except I move my rio map to here, my pci map to here, change a few
sizes etc., why do I have to go and patchup the arch setup code, modify
ppc_md routines, etc. Isn't the plan that I just edit the dts, compile
with dtc and have u-boot pass in the dtb to the stock kernel and its
boots on my board? 

If dts can't do this because its not allowed policy statements then what
will do this?

What device in the dts represents the soc mpx/mpc where I can define
what the laws should be? Segher is right, its not a property of the
rapidio device, it doesn't have a BAR (though it does have ATMUs?). But
if I have a device representing the mpx/mpc (the soc itself?) then I can
specify ranges for child devices to operate in (the laws) and then in
the child device I can specify ranges for the ATMUs?

I'm probably trampling over a ton of old stuff here, sorry, excuse my
ramblings....

Please I'm not trying to start up any previous turf wars here, just
trying to understand the truce terms and the plan ahead so I can get
with the program. Appreciate the help for a newbie.

Cheers
Phil

> 
> - k
> 
>  > > Cheers
> > Phil
> >
> > >
> > > >>> The dbells and mboxs can be removed. The default setting in rio is
> > > >>> okay.
> > > >>
> > > >> this could possibly be useful.
> > >
> > > Same issue.  Even if the firmware uses a default setting,
> > > it should still put it in the device tree _iff_ it is the
> > > firmware's decision (and not the kernel's).
> > >
> > >
> > > Segher
> > >
> > >
> > >
> >
> >
> 
>