[Top][All Lists]
[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
- Re: [Qemu-ppc] [PATCH 02/19] mpic: Unify numbering scheme, (continued)
[Qemu-ppc] [PATCH 11/19] openpic: convert simple reg operations to builtin bitops, Alexander Graf, 2012/12/08
[Qemu-ppc] [PATCH 14/19] openpic: convert to qdev, Alexander Graf, 2012/12/08