From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiUAr-0006fa-Qy for qemu-devel@nongnu.org; Tue, 11 Dec 2012 13:03:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiUAg-0005fZ-RG for qemu-devel@nongnu.org; Tue, 11 Dec 2012 13:03:21 -0500 Date: Tue, 11 Dec 2012 11:47:42 -0600 From: Scott Wood In-Reply-To: (from agraf@suse.de on Tue Dec 11 02:25:31 2012) Message-ID: <1355248062.13481.7@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 02:25:31 AM, Alexander Graf wrote: >=20 >=20 > On 11.12.2012, at 00:47, Scott Wood wrote: >=20 > > On 12/08/2012 07:44:37 AM, Alexander Graf wrote: > >> This patch converts the OpenPIC device to qdev. Along the way it > >> renames the "openpic" target to "raven" and the "mpic" target to > >> "mpc8544", to better reflect the actual models they implement. > >> This way we have a generic OpenPIC device now that can handle > >> different flavors of the OpenPIC specification. > > > > I'd rather not see the expansion of "mpc8544" hardcoding, =20 > especially since it's not really modelling an MPIC as found in an =20 > mpc8544, but rather half-implementing a generic Freescale MPIC. >=20 > That's what we've been doing wrong all the time now. We shouldn't =20 > implement a half-generic fsl mpic, because we will never get to a =20 > point where we're accurate enough or flexible enough for both =20 > definitions. What do you mean by "both"? AFAICT we'll always have a half-generic =20 MPIC because we'll probably never get it looking 100% like any =20 particular chip. > If we want a pv style generic mpic (for -M e500), let's add such an =20 > mpic to the model list and make that one be really generic. But the =20 > 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 not? -Scott=