[RFC] MPIC Bindings and Bindings for AMP Systems

Scott Wood scottwood at freescale.com
Tue Jan 4 06:51:20 EST 2011

On Thu, 23 Dec 2010 15:33:25 -0700
Grant Likely <grant.likely at secretlab.ca> wrote:

> On Thu, Dec 23, 2010 at 03:49:54PM -0600, Meador Inge wrote:
> > How do you
> > see this working in terms of processing the data?  It seems like we
> > are going to have to be aware of N values instead of 1, which seems
> > worse.
> This argument has been rehashed many times, but it basically comes
> down to compatible values should ideally be anchored to a real
> implemented device, not to a family of devices, or to an unversioned
> specification.

Freescale MPICs do have version numbers (version registers, even).  We
should put that version (possibly along with a compatible version) in
the compatible, though, for blocks such as this which don't include the
main MPIC registers and thus the version registers.

> In practise, the implementation doesn't actually look any different
> except that the 'reference' version specifies a specific
> implementation instead of a generic name.  To use a concrete example,
> if there are two parts using this MPIC, like the freescale p2040 and
> p4080, and say for argument that the p2040 was implemented first, then
> the compatible values would look like:
> for the p2040:   compatible = "fsl,p2040-msgr";
> for the p4080:   compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";

While I don't think it affected the message unit, p4080 rev 1 has a
different version of the MPIC from p4080 rev 2 (4.0 versus 4.1, IIRC).

I don't think "mpic-" should be dropped, whether a specific chip is
added or not.  "msgr" just seems too generic, and "mpic-" tells the
reader where in the chip manual they can find information about it.

> > >?  This needs some more explanation.  cell-index often gets abused as
> > >a way to enumerate devices.  Typically, the address of the device
> > >itself is sufficient to identify the device.
> > 
> > The message registers typically come in blocks of four memory mapped
> > registers and may not be in contiguous memory (example [3]).  The
> > intent of 'cell-index' is to put an ordering on the blocks (so, yes,
> > enumeration).  We could order them by address as well I suppose.
> > One less property to worry about :)

But why do we care about ordering them?  What's important is just that
you use the same one on both the sending partition and the receiving


More information about the Linuxppc-dev mailing list