[RFC] MPIC Bindings and Bindings for AMP Systems

[Blanchard, Hollis]

On 01/05/2011 03:07 PM, Scott Wood wrote:
> 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.
Using physical addresses doesn't solve the enumeration problem either, 
but I think it's beside the point: userspace must refer to the device. 
There is a rich history of userspace *not* walking /proc/device-tree in 
order to refer to a physical device. Are you suggesting this case is 
special?

Hollis Blanchard
Mentor Graphics, Embedded Systems Division