From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TibHc-0008Bx-Fz for qemu-devel@nongnu.org; Tue, 11 Dec 2012 20:38:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TibHZ-0002Qj-Pv for qemu-devel@nongnu.org; Tue, 11 Dec 2012 20:38:48 -0500 Date: Tue, 11 Dec 2012 19:38:20 -0600 From: Scott Wood In-Reply-To: <2871B5F4-8084-46EC-A612-725421829498@suse.de> (from agraf@suse.de on Tue Dec 11 18:56:56 2012) Message-ID: <1355276300.16025.5@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 14/19] openpic: convert to qdev List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-ppc@nongnu.org List" , qemu-devel qemu-devel On 12/11/2012 06:56:56 PM, Alexander Graf wrote: >=20 > On 11.12.2012, at 18:47, Scott Wood wrote: >=20 > > On 12/11/2012 02:25:31 AM, Alexander Graf wrote: > >> If we want a pv style generic mpic (for -M e500), let's add such =20 > an mpic to the model list and make that one be really generic. But =20 > the MPIC in -M mpc8544ds should behave exactly like an mpc8544 mpic. =20 > Whenever we fail to do so, we better fix the emulation to be accurate =20 > ;) > > > > What behaviors would "mpc8544" specify that "fsl mpic v2.0" would =20 > not? >=20 > I don't know. If you say that mpc8544 =3D=3D "fsl mpic v2.0" I'm more =20 > than happy to rename what we have. Simply calling it "MPIC" was =20 > definitely wrong, so I want with the one where I'm actually sure that =20 > what I'm implementing is correct, because I have the spec in front of =20 > me. >=20 > My general approach to this problem would be that we for example get =20 > a p4080 board once. Once we get that, we want a p4080 MPIC. Then =20 > you'd sit down and model the p4080 MPIC. You realize that it's =20 > identical to the mpc8544 MPIC. So you either choose to instantiate an =20 > MPC8544 MPIC or you rename the model name to "fsl mpic v2.0". p4080 would be "fsl mpic v4.2" -- unless you want to model an older =20 revision of p4080 in which case it could be v4.0 or v4.1. Note that =20 this example shows that the chip name can be even less specific than =20 the block version number. > If you can assure me today that they will be identical, I'm more than =20 > happy to change the name today already :). "fsl mpic v2.0" describes the MPIC that was integrated into the =20 mpc8544, as well as several other chips. In general you can look at =20 versioned SoC blocks as if they were a separate chip, except for =20 integration parameters, which should be qdev parameters. The only =20 integration parameters I can think of for MPIC are the number of CPUs =20 -- we already deviate from mpc8544 there to allow SMP -- and number of =20 interrupt sources, for which we can safely just implement the maximum, =20 or make it a qdev parameter if we really care about matching what =20 hardware reports in FRR[NIRQ] (this number is actually rather useless =20 to software the way Freescale implemented it). -Scott=