From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH v2 07/10] dts/ls2085a: Update DTSI to add support of various peripherals Date: Thu, 1 Oct 2015 16:58:57 -0500 Message-ID: <1443736737.5336.158.camel@freescale.com> References: <1441350322-4671-1-git-send-email-bhupesh.sharma@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Li Yang Cc: Mark Rutland , devicetree@vger.kernel.org, Shaohui Xie , Arnd Bergmann , Huan Wang , Sharma Bhupesh , Catalin Marinas , Olof Johansson , Singh Jaiprakash , Stuart Yoder , Will Deacon , "Lian M.H." , Liu Gang , Rob Herring , Marc Zyngier , Badola Nikhil-B46172 , Bhupesh SHARMA , "linux-clk@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "Lu Y.B." List-Id: devicetree@vger.kernel.org On Thu, 2015-10-01 at 16:42 -0500, Li Yang wrote: > On Thu, Oct 1, 2015 at 3:05 PM, Stuart Yoder > 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 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 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