Hi Andreas, On Wed, Nov 27, 2013 at 8:27 PM, Andreas Färber <afaer...@suse.de> wrote: > Am 27.11.2013 11:15, schrieb Peter Maydell: >> On 27 November 2013 09:42, Andreas Färber <afaer...@suse.de> wrote: >>> If we turn it into a dynamic property, we could register it conditional >>> to ARM_FEATURE_CBAR. >> >> Unfortunately feature flags only get set at realize (in the >> per-cpu init function), so we don't know at the point where >> we're registering properties whether to have this one or not. > > 1/6 sets it in instance_init actually. So instance_post_init might do. >
Do you have a candidate example of this pattern that I can work off? >> The other option would be to define an a9 cpu class init fn to >> put the property in. > > Is it A9-only or would A15, A7, A12, etc. also need it? > >>> The overall idea of the series makes sense to me. I would caution to >>> think about the naming scheme though - we might want to have a "cbar" >>> property to access the current value whereas we'll likely end up having >>> several reset values to configure over time. >> >> Mmm, maybe. The approach I think we've taken in some other >> places (eg the cache controller) is to have the property names >> match the silicon's config or control signal names (which in >> this case would be PERIPHBASE), but they are not always >> consistent from CPU to CPU, so that might be more confusing >> than helpful. I don't think I have a strong opinion here, so I'd >> be happy with any vaguely consistent-looking plan. > > Whatever name you choose, I was rather thinking of whether you may want > to call it, e.g., "foo-reset" or "reset-foo" to distinguish from plain > "foo". (Igor's x86 properties series uses "feat-foo" on Anthony's > suggestion to group and parse feature properties.) > Is the "periphbase" ever runtime configurable? If not I'm not sure we need the "reset". Regards, Peter > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >
