On 21 June 2016 at 04:49, Andrew Jeffery <and...@aj.id.au> 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
