[RFC] MPIC Bindings and Bindings for AMP Systems
Meador Inge
meador_inge at mentor.com
Thu Jan 6 08:58:55 EST 2011
On 01/03/2011 01:51 PM, Scott Wood wrote:
> 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.
I like that better than claiming compatibility with other chips. I will
incorporate that idea. Thanks.
>> 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.
Agreed.
>>>> ? 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.
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 ...
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
More information about the devicetree-discuss
mailing list