From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 20 Feb 2014 08:43:53 -0500 Subject: [U-Boot] [U-Boot, v3, 2/3] dts: move device tree sources to arch/$(ARCH)/dts/ In-Reply-To: <20140220182220.A192.AA925319@jp.panasonic.com> References: <1391567307-27434-3-git-send-email-yamada.m@jp.panasonic.com> <20140219211117.GR19081@bill-the-cat> <20140220182220.A192.AA925319@jp.panasonic.com> Message-ID: <20140220134353.GD19081@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Feb 20, 2014 at 06:22:20PM +0900, Masahiro Yamada wrote: > Hello Tom, Simon > > > > Unlike Linux Kernel, U-Boot historically had *.dts files under > > > board/$(VENDOR)/dts/ and *.dtsi files under arch/$(ARCH)/dts/. > > > > > > I think arch/$(ARCH)/dts dicretory is a better location > > > to store both *.dts and *.dtsi files. > > > > > > For example, before this commit, board/xilinx/dts directory > > > had both Microblaze dts (microblaze-generic.dts) and > > > ARM dts (zynq-*.dts), which are totally unrelated. > > > > > > This commit moves *.dts to arch/$(ARCH)/dts/ directories, > > > allowing us to describe nicely mutiple DTBs generation in the next commit. > > > > > > Signed-off-by: Masahiro Yamada > > > > Applied to u-boot/master, thanks! > > > > -- > > Tom > > > This series was applied sooner than I had expected. > Simon and I were still discussing this series. > > So I am afraid Simon is really not happy about it > because he was opposed to moving *.dts files > from vendor directories to arch directories. > > Tom also mentioned as follows: > > This, I think is backwards. Xilinx has (and Freescale and others are or > > will be joining them) a lot of things shared between them as IP blocks > > get reused from non-ARM to ARM CPUs. So there's a level of DT sharing > > for these blocks between the CPUs. > > I'd like to know Tom's option about the device tree structure. > Let me confirm if my patch is doing right thing. So, for clarity, yes, I this this is the right way to go and we should focus our "we can do better" efforts on the discussion that is / will be happening with the kernel folks about how things should be handled once all these blobs move out of the kernel as that'll be something we want to leverage too. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: