qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 14/19] openpic: convert to qdev


From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 14/19] openpic: convert to qdev
Date: Wed, 12 Dec 2012 11:37:12 +0100

On 12.12.2012, at 02:38, Scott Wood wrote:

> On 12/11/2012 06:56:56 PM, Alexander Graf wrote:
>> On 11.12.2012, at 18:47, Scott Wood wrote:
>> > 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 an mpic 
>> >> to the model list and make that one be really generic. But the MPIC in -M 
>> >> mpc8544ds should behave exactly like an mpc8544 mpic. Whenever we fail to 
>> >> do so, we better fix the emulation to be accurate ;)
>> >
>> > What behaviors would "mpc8544" specify that "fsl mpic v2.0" would not?
>> I don't know. If you say that mpc8544 == "fsl mpic v2.0" I'm more than happy 
>> to rename what we have. Simply calling it "MPIC" was definitely wrong, so I 
>> want with the one where I'm actually sure that what I'm implementing is 
>> correct, because I have the spec in front of me.
>> My general approach to this problem would be that we for example get a p4080 
>> board once. Once we get that, we want a p4080 MPIC. Then you'd sit down and 
>> model the p4080 MPIC. You realize that it's identical to the mpc8544 MPIC. 
>> So you either choose to instantiate an 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 revision 
> of p4080 in which case it could be v4.0 or v4.1.  Note that this example 
> shows that the chip name can be even less specific than the block version 
> number.

Ok, I'll rename it to "FSL_MPIC_20" then :).

> 
>> If you can assure me today that they will be identical, I'm more than happy 
>> to change the name today already :).
> 
> "fsl mpic v2.0" describes the MPIC that was integrated into the mpc8544, as 
> well as several other chips.  In general you can look at versioned SoC blocks 
> as if they were a separate chip, except for integration parameters, which 
> should be qdev parameters.  The only integration parameters I can think of 
> for MPIC are the number of CPUs -- we already deviate from mpc8544 there to 
> allow SMP -- and number of interrupt sources, for which we can safely just 
> implement the maximum, or make it a qdev parameter if we really care about 
> matching what hardware reports in FRR[NIRQ] (this number is actually rather 
> useless to software the way Freescale implemented it).

Sounds great :).


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]