From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Glass <sjg@chromium.org>
Date: Sat, 15 Feb 2014 16:46:07 -0700
Subject: [U-Boot] [PATCH v2 2/3] dts: move device tree sources to
	arch/$(ARCH)/dts/
In-Reply-To: <20140206145049.4323.AA925319@jp.panasonic.com>
References: <1391506721-32462-3-git-send-email-yamada.m@jp.panasonic.com>
	<CAPnjgZ3WAXresEJ_es=wMKsaiTWU4c3PFot8GzL1sKu182jT_Q@mail.gmail.com>
	<20140206145049.4323.AA925319@jp.panasonic.com>
Message-ID: <CAPnjgZ2AvBUkR12OJvbxy732JnVGczE_K8PkTA4ZCSWSn765VA@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Masahiro,

On 5 February 2014 22:50, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> Hello Simon,
>
>
>> Hi Masahiro,
>>
>> On 4 February 2014 02:38, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
>> > 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.
>>
>> What is the motivation for this? I worry that we might end up with a
>> lot of files in one directory.
>
> We have only 35 .dtsi and .dts for ARM.
> I think it will be OK at least until we have 500.
>
> Linux v3.13 has 500 .dtsi and .dts files in arch/arm/boot/dts/
> and they are still adding device trees to that directory.
>
> I have no idea if they will keep going, or someone will scream and turn
> around.
>
> Anyway, when Linux guys someday invents a nice idea to work arond
> increasing device trees, we can import it to U-Boot.
> It should be easy for us because we already have a similar build system.

Hmm, but would it be such a big problem to keep the general ARM and
SOC stuff in arch/arm/dts and the board-specific stuff in board/ ?

One of the problems with Linux is that their board-specific code is
spread all over the place, and I'm not sure we want to emulate it?

>
>> One benefit of the current approach is
>> that .dts files are split up by vendor. Even if we put the SoC .dtsi
>> files in arch/arm, perhaps there is a benefit in leaving the board
>> .dts files in board/<vendor>?
>
> I don't like the idea to split up by vendor.
>
> Now Xilinx has device trees both for ARM and Microblaze,
> resulting in totally unrelated device trees in one directory.

Shouldn't the SoC part go in arch/arm and arch/microblaze? Then just
the board-specific stuff can go in board/

>
> What if Freescale decided to adopt device tree?
> They support various boards on ARM, PowerPC, M68K.
>
> Renesus is the same. They have ARM and SuperH boards.

I'm not convinced yet. I think maybe you have forgotten about the
.dtsi files for SoCs. They are common, but no one is going to include
a board .dts file (nor can they), so putting them in a common area
does not seem like a win to me.

>
>
> On the other hand, different vendors can produce similar boards.
> For example avionic design, which develops Tegra boards,
> are using nVidia's sources.
>
> When I saw  board/nvidia/common/common.mk
> and board/avionic-design/*/Makefile, etc., I think we're screwed up
> with <vendor> directory.

Well the probably as I see it is that board/nvidia has some SoC code
that other boards want to use. The solution to that might be to move
the code to arch/arm/cpu/armv7/tegra... instead?

>
> Best Regards
> Masahiro Yamada
>

Regards,
Simon