Re: [RFC] MPIC Bindings and Bindings for AMP Systems

[Meador Inge <meador_inge@mentor.com>]

On 01/03/2011 01:51 PM, Scott Wood wrote:
> On Thu, 23 Dec 2010 15:33:25 -0700
> Grant Likely<grant.likely@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