[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 7/7] xen/arm: get the number of cpus from device tree



On Thu, 15 Nov 2012, Ian Campbell wrote:
> On Thu, 2012-11-15 at 15:26 +0000, Stefano Stabellini wrote:
> > On Thu, 15 Nov 2012, Ian Campbell wrote:
> > > On Tue, 2012-11-13 at 15:42 +0000, Stefano Stabellini wrote:
> > > > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> > > > index 3d1f0f4..5b6dab9 100644
> > > > --- a/xen/common/device_tree.c
> > > > +++ b/xen/common/device_tree.c
> > > > @@ -153,6 +153,25 @@ const char *device_tree_bootargs(const void *fdt)
> > > >      return prop->data;
> > > >  }
> > > >  
> > > > +int device_tree_cpus(const void *fdt)
> > > > +{
> > > > +    int node = 0, depth = 1;
> > > > +    int cpus = 0;
> > > > +
> > > > +    node = fdt_path_offset(fdt, "/cpus/cpu");
> > > > +    if ( node < 0 )
> > > > +        return 1; /* we have at least one cpu */
> > > > +
> > > > +    while ( node >= 0 && depth >= 0 ) {
> > > > +        if ( strncmp(fdt_get_name(fdt, node, NULL), "cpu", 3) )
> > > > +            continue;
> > > > +        node = fdt_next_node(fdt, node, &depth);
> > > > +        cpus++;
> > > 
> > > Do we not need to track the largest <n> for each cpu@<n> which we see,
> > > in order to handle systems with e.g. CPUs 0, 1, 4 & 5?
> > 
> > Actually the hardware ID is expressed by the <reg> propery.
> > Maybe we should set the corresponding ID in cpu_present_map from
> > device_tree_cpus?
> 
> I'm not sure what you mean.

I mean that it is not the @<num> that expresses the cpu number from the
hardware point of view.
The cpu number is held by the <reg> property of the cpu node.
Considering that the second cpu could theoretically have ID number 5, we
should go and mark cpu 1-4 as non present in the cpu masks. We should
only set cpu number 5 as present.

> > > There are some helpers in device_tree.c to walk over trees like this,
> > > are none of them suitable?
> >  
> > Do you mean device_tree_node_matches?
> > Yes, I can use that instead of strncmp. I'll do that.
> 
> You should , but that's not what I was talkig about ;-)
> 
> I was thinking of device_tree_for_each_node but I suppose that doesn't
> quite fit? But perhaps you can integrate with early_scan_node?

Maybe, but now that I think about it we should be matching on
device_type rather than node name. We should do the same for memory too.
We need to either change device_tree_node_matches or write a new
matching function.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.