From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4D24E99F.90908@mentor.com> Date: Wed, 05 Jan 2011 15:58:55 -0600 From: Meador Inge MIME-Version: 1.0 To: Scott Wood Subject: Re: [RFC] MPIC Bindings and Bindings for AMP Systems References: <4D12F171.7010103@mentor.com> <20101223185623.GA20384@angua.secretlab.ca> <4D13C402.2090209@mentor.com> <20101223223325.GK20384@angua.secretlab.ca> <20110103135120.32aeb60d@udp111988uds.am.freescale.net> In-Reply-To: <20110103135120.32aeb60d@udp111988uds.am.freescale.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: "Blanchard, Hollis" , devicetree-discuss@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 01/03/2011 01:51 PM, Scott Wood wrote: > On Thu, 23 Dec 2010 15:33:25 -0700 > Grant Likely 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