Re: [RFC] MPIC Bindings and Bindings for AMP Systems

On Wed, 5 Jan 2011 14:49:40 -0800
"Blanchard, Hollis" [off-list ref] wrote:

On 01/05/2011 02:09 PM, Scott Wood wrote:

quoted

On Wed, 5 Jan 2011 15:58:55 -0600
Meador Inge[off-list ref]  wrote:

quoted

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.

-Scott