Re: [Qemu-arm] [PATCH 1/2] hw/misc: Add a model for the ASPEED System Control Unit

[Peter Maydell]

On 21 June 2016 at 04:49, Andrew Jeffery <address@hidden> wrote:
> On Mon, 2016-06-20 at 14:57 +0100, Peter Maydell wrote:
>> I think there are a couple of plausible ways you might model this:
>>
>> (a) just have a single property for "revision" which corresponds
>> to the revision of this bit of silicon IP within the SoC; the
>> model of the device itself then knows what the reset state is
>> for this revision of the device.
>> (b) ditto, but also have some configurable flags where relevant
>> (ie approximately where it's the same IP rev within the SoC
>> but it's been configured by tying down different config lines;
>> for instance hw/dma/pl330.c has a collection of properties
>> which match the configurable knobs for the hardware.)
>
> Okay. I think (b) is the most appropriate. The board-controllable bits
> are primarily in the hardware strapping register. The register is
> composed of fields of mostly unrelated bits, so we could go two ways
> here:
>
> (1) expose the register through a single 32bit property
> (2) break out a property for each bitfield
>
> Do you have a preference? grepping the tree suggests there isn't a
> precedent for "large" numbers of properties* so maybe (2) is overkill,
> but (1) feels like it might fit into the overly-general-interface
> problem that we're trying to eliminate.
>
> * Seems the microblaze CPU defines the most with 9 properties?

(You forgot '-n' on your sort rune.)
hw/dma/pl330.c has 15.

> Approach (2) will leave us with 21 properties for the SCU.

What would the 21 properties be in this case?

But yes, a single 32 bit property would probably be better.

thanks
-- PMM