[PATCH v2 07/10] dts/ls2085a: Update DTSI to add support of various peripherals
Scott Wood
scottwood at freescale.com
Thu Oct 1 14:58:57 PDT 2015
On Thu, 2015-10-01 at 16:42 -0500, Li Yang wrote:
> On Thu, Oct 1, 2015 at 3:05 PM, Stuart Yoder <stuart.yoder at freescale.com>
> wrote:
> > Hi Rob,
> >
> > Had a question about your comments on the patch below.
> >
> > You singled out 3 nodes (gic,uart,clockgen) and said "This should be
> > under a bus node."
> >
> > What is special about those 3 nodes types? There are a bunch of other
> > memory
> > mapped SoC devices as well in the DTS.
> >
> > I skimmed the dts files under arch/arm64 and it looks like most have a
> > simple-bus
> > SoC node like this where SoC devices are under:
> >
> > soc {
> > #address-cells = <2>;
> > #size-cells = <2>;
> > compatible = "simple-bus";
> > ranges;
> >
> > Is that what you are looking for-- for all SoC devices?
>
> I think the key is to have the soc node and have all the on-chip
> devices defined underneath it.
>
> I read the following from the booting-without-of.txt document:
>
> f) the /soc<SOCname> node
>
> This node is used to represent a system-on-a-chip (SoC) and must be
> present if the processor is a SoC. The top-level soc node contains
> information that is global to all devices on the SoC. The node name
> should contain a unit address for the SoC, which is the base address
> of the memory-mapped register set for the SoC. The name of an SoC
> node should start with "soc", and the remainder of the name should
> represent the part number for the soc. For example, the MPC8540's
> soc node would be called "soc8540".
>
> A lot of device trees didn't follow the soc<SOCname> naming scheme and
> just used "soc" as the node name. I am not sure if we want to enforce
> the naming in the future or update the document to make it more relax.
Update the document. Having the SoC name in the node name was a pain, which
is why we don't do it anymore. Ideally, this text should be moved into a
binding for Freescale PPC/LS SoCs. It really doesn't have the broad
applicability that this historical document suggests, and even on our SoCs it
doesn't represent the entire SoC. It represents CCSR/IMMR.
-Scott
More information about the linux-arm-kernel
mailing list