On Tue, 2016-06-21 at 07:56 +0100, Peter Maydell wrote:
> On 21 June 2016 at 04:49, Andrew Jeffery <andrew@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