On Wed, 5 Jan 2011 15:58:55 -0600
Meador Inge [off-list ref] 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.
-Scott
On 01/05/2011 02:09 PM, Scott Wood wrote:
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
quoted
some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that =
would
quoted
be by putting an order on the registers. Maybe there is a better =
way,
quoted
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=20
description. We've gone back and forth on representing this information=20
in the device tree, and most recently decided against it. Outside the=20
kernel, a device node reference isn't really practical.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
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
On 01/05/2011 03:07 PM, Scott Wood wrote:
On Wed, 5 Jan 2011 14:49:40 -0800
"Blanchard, Hollis"[off-list ref] wrote:
quoted
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
quoted
quoted
quoted
register number so that the message registers can be referenced =
through
quoted
quoted
quoted
some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that =
would
quoted
quoted
quoted
be by putting an order on the registers. Maybe there is a better =
way,
quoted
quoted
quoted
though ...
A message register is uniquely identified by a reference to the =
device
quoted
quoted
tree node, plus a 0-3 index into that node's message registers.
Really what we're talking about is software configuration, not =
hardware
quoted
description.
Part of that software configuration involves identifying the hardware
being referenced.
quoted
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,=20
but I think it's beside the point: userspace must refer to the device.=20
There is a rich history of userspace *not* walking /proc/device-tree in=20
order to refer to a physical device. Are you suggesting this case is=20
special?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division