[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
partition.
-Scott
More information about the devicetree-discuss
mailing list