From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Glass <sjg@chromium.org>
Date: Tue, 18 Feb 2014 22:06:43 -0800
Subject: [U-Boot] [PATCH v2 2/3] dts: move device tree sources to
	arch/$(ARCH)/dts/
In-Reply-To: <20140218184327.A133.AA925319@jp.panasonic.com>
References: <20140206145049.4323.AA925319@jp.panasonic.com>
	<CAPnjgZ2AvBUkR12OJvbxy732JnVGczE_K8PkTA4ZCSWSn765VA@mail.gmail.com>
	<20140218184327.A133.AA925319@jp.panasonic.com>
Message-ID: <CAPnjgZ1CPBjGtMX66L17-ksUPK6SqUgMv6CEAtLpwywf-sdKFQ@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 18 February 2014 01:43, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> Hello Simon,
>
>
>> >>
>> >> 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?
>
> Opposite.
> Board-specific code mostly resides under
> arch/arm/mach-* or arch/arm/plat-*.
> And what else is arch/arm/configs and arch/arm/boot/dts. That's it.
>
>
> We have board-specific part
>  - entries in boards.cfg
>  - include/configs/<board_config>.h
>  - board/<vendor>/<board> or board/<board>
>  - arch/<ARCH>/include/am/arch-<soc> includes sometimes
>    board-specific headers  as well as SoC specific headers.
>    (Because there is no other place to store board-specific header files)
>
> Various stuff under include/, for exmple
>   - include/xilinx.h:  vendor specific?
>   - include/sandboxblockdev.h:  arch specific?
>
> And we often missed to remove remainders of dead boards.
>
> U-Boot has more troublesome directory structure.

Well Linux got board-specific directories and systems only relatively
recently I suppose. U-Boot has the benefit of many years of legacy :-)

>
>
>> >> 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 is SoC part? What is Board part?

Well SoC is the chip from a vendor like Nvidia. Normally they would
provide a set of .dtsi files, say for example tegra20.dtsi,
tegra30.dtsi, etc. It makes sense to have a common SoC directory that
all boards can use.

Then a board that uses say a Tegra SoC on it can just include those
files and connect things up as required.

>
>> >
>> > 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.
>
> I do know that *.dtsi files are included from others, while
> *.dts files are not included from anywhere.
> And I understand your policy, *.dtsi to arch dir and *.dts to vendor dir.
> (No that I care, we have two exceptions:
> ./board/avionic-design/dts/tegra20-tamonten.dtsi
> ./board/avionic-design/dts/tegra30-tamonten.dtsi)
>
> If I have to mention a win,
> we can save makefiles by not putting almost same ones in
> vendor directories.
>
>
> Anyway, we have 3 structures proposed so far.
>
> [1] board/$(VENDOR)/dts/  (current structure)
> [2] arch/$(ARCH)/dts/  (suggested by me)
> [3] dts/  for all architectures (suggested by Scott)
>
> In my option, [2] and [3] seem to be reasonable enough.
>
> If we cannot reach an agreement,
> shall we postpone 2/3 and 3/3 and apply only 1/3?
>

I don't want to hold up progress, but I am not sure that the Linux
approach is a great idea. I prefer this:

arch/$(ARCH)/dts   - SoC .dtsi files
board/$(VENDOR)/dts   - Board-specific .dts files (which include the above)

but as you say we don't have a lot of files so it is not a huge deal.

>
>> > 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?
>
> Concerning the result, board/nvidia/common turned out to be
> SoC-specific code, not Vendor-specific (board-specific) code.
>

Agreed, but we don't put .dtsi files in there, so that is a different problem.

> But I guess the difference between SoC-specific code and board-specific
> code was not clear when nVidia develpers posted that code first.
>
> Maybe I am digressing, but it also happens to me quite often.
> It is difficult for me to decide whether each code should
> go to board/panasonic or arch/arm/cpu/armv7/uniphier.
>
> I'd say, vendor (and board) directories are harmful.

Interesting...the idea with board files I think is that it is for code
specific to a board. My hope is that there would be less of that with
device tree, but it is early days.

You are right about the common directory in board/<vendor>. But this
is probably worth a wider discussion than just device tree files.

Regards,
Simon