Re: [PATCH v2 07/10] dts/ls2085a: Update DTSI to add support of various peripherals

[Scott Wood <scottwood@freescale.com>]

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@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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel