On Tue, 2016-06-21 at 07:56 +0100, Peter Maydell wrote: > 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.
Ugh. > > > > > 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. Alright, I'll go ahead with that. Thanks for the feedback. Andrew
signature.asc
Description: This is a digitally signed message part
