On 01/03/2011 01:51 PM, Scott Wood wrote:
On Thu, 23 Dec 2010 15:33:25 -0700
Grant Likely<grant.lik...@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
