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
