Re: [RFC PATCH v2 3/4] arm64:thunder: Add initial dts for Cavium's Thunder SoC in 2 Node topology.

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Tuesday 25 November 2014 13:38:01 Ard Biesheuvel wrote:
> On 24 November 2014 at 18:01, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Monday 24 November 2014 11:32:46 Roy Franz wrote:
> >> >
> >> > I don't know how much history is behind this binding. Have you looked
> >> > at the sPAPR way of doing this? I don't remember exactly how that is
> >> > done, but we'd need a good reason to discard that and implement
> >> > something else for arm64.
> >> >
> >> > If we create a new binding, I don't think the 'numa-map' node you
> >> > have here is the best solution. We already have device nodes for each
> >> > memory segment and each CPU in the system. Why not work with those
> >> > nodes directly?
> >>
> >> The DT memory nodes don't exist in an EFI system, as the EFI memory
> >> map is used instead.
> >> Using EFI as the boot firmware doesn't require the use of ACPI for
> >> hardware description,
> >> so the EFI/DT case is one that we should support.
> >
> > But they /could/ exist, right? Can we just require them to be
> > present in order to use NUMA features?
> >
> 
> Actually, currently the memory nodes are stripped from the device tree
> by the EFI stub, so the kernel will never get to see them.
> This is done more or less as a fixup, under the assumption that EFI
> systems should not have DT memory nodes in the first place.
> 
> We could revisit this, of course, but it needs to be taken into
> account in this discussion.

Right. As we don't support NUMA yet, this would have to become
a requirement for implementing NUMA: If you have no memory nodes,
you could still use the DT binding for topology, but it would be
limited to CPUs and I/O devices, which of course seriously limits
the usefulness.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html