[RFC] MPIC Bindings and Bindings for AMP Systems

Scott Wood scottwood at freescale.com
Thu Jan 6 10:07:25 EST 2011

On Wed, 5 Jan 2011 14:49:40 -0800
"Blanchard, Hollis" <Hollis_Blanchard at mentor.com> wrote:

> On 01/05/2011 02:09 PM, Scott Wood wrote:
> > On Wed, 5 Jan 2011 15:58:55 -0600
> > Meador Inge<meador_inge at mentor.com>  wrote:
> >
> >> We need some sort of mapping between a message register and a message
> >> register number so that the message registers can be referenced through
> >> some sort of API (e.g. 'mpic_msgr_read(0)').  One way to do that would
> >> be by putting an order on the registers.  Maybe there is a better way,
> >> though ...
> > A message register is uniquely identified by a reference to the device
> > tree node, plus a 0-3 index into that node's message registers.
> Really what we're talking about is software configuration, not hardware 
> description.

Part of that software configuration involves identifying the hardware
being referenced.

> We've gone back and forth on representing this information 
> in the device tree, and most recently decided against it. Outside the 
> kernel, a device node reference isn't really practical.

Global enumeration isn't much fun either.  For something like this
where it's very unlikely that additional MPIC message units will be
added to the system dynamically, it's managable, but it's not a good
habit to get into.  Look at the pain that's been caused by such
assumptions in the i2c subsystem, in kernel interrupt management, etc.

A reference to a node is just a pointer to a software message driver
object, which can be obtained from looking up an alias.  It's a little
less simple than just using a number, but it's not impractical. It also
provides a natural place to put a layer of indirection in the code that
isolates the upper-layer protocol from the details of what sort of
message transport it is using.

Now, if you don't care about this, and want to just use numbers in your
application, go ahead.  But I don't think that such an assumption
should go into the device tree binding.  Have the software number the
message register banks in increasing physical address order, or based
on numbered aliases similar to how U-Boot enumerates ethernet nodes, or
something similar.


More information about the Linuxppc-dev mailing list