[PATCH v2 07/10] dts/ls2085a: Update DTSI to add support of various peripherals
Li Yang
leoli at freescale.com
Thu Oct 1 15:41:56 PDT 2015
On Thu, Oct 1, 2015 at 4:58 PM, Scott Wood <scottwood at freescale.com> wrote:
> 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.
Having the soc node to represent the CCSR space is a Freescale
specific thing. But using the soc node to be the parent for all the
on-chip devices seems to be a good practice for all device trees. I
do think we should maintain a standard for the top level nodes of a
device tree.
Regards,
Leo
More information about the linux-arm-kernel
mailing list