From mboxrd@z Thu Jan  1 00:00:00 1970
From: Masahiro Yamada <yamada.m@jp.panasonic.com>
Date: Thu, 12 Jun 2014 15:32:14 +0900
Subject: [U-Boot] Refactoring of U-Boot directory structure
In-Reply-To: <20140612044145.B1CF3380601@gemini.denx.de>
References: <20140612131050.963A.AA925319@jp.panasonic.com>
	<20140612044145.B1CF3380601@gemini.denx.de>
Message-ID: <20140612153214.9642.AA925319@jp.panasonic.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 Wolfgang,

On Thu, 12 Jun 2014 06:41:45 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Masahiro,
> 
> In message <20140612131050.963A.AA925319@jp.panasonic.com> you wrote:
> > 
> > [1] Do not split the similar  SoC family to various directories
> > 
> > at91 SoC directory exists under arm920t, arm926ejs, armv7 directory.
> 
> To me this actually makes sense, as they are using different CPU cores
> (ARMv4t vs. ARMv5te vs. ARMv7).
> 
> > ./arch/arm/cpu/arm920t/at91
> > ./arch/arm/cpu/arm926ejs/at91
> > ./arch/arm/cpu/armv7/at91
> > 
> > It looks reasonable to collect at91 sources into a single place,
> > arch/arm/mach-at91
> 
> Did you look at the code?   Files like lowlevel_init.S, reset.c or
> timer.c look pretty much specific to the respective architecture.
> What would be the benefit of mixing all this different stuff in a
> single directory?

No.
I am discussing from the generic view.

In the current structure, there is no place which at91-common
part should go to.

Splitting code into various directories loses the motivation of
consolidating the common part even if it exists.

(Again, just in case, this is generalities.
I am not familiar with the at91-specific implementation.)



> > That's why Tegra directories are sprinkled under arch/arm/:
> > 
> > arch/arm/cpu/arm720t/tegra-common/
> > arch/arm/cpu/arm720t/tegra20/
> > arch/arm/cpu/arm720t/tegra30/
> > arch/arm/cpu/arm720t/tegra114/
> > arch/arm/cpu/arm720t/tegra124/
> > arch/arm/cpu/armv7/tegra-common/
> > arch/arm/cpu/armv7/tegra20/
> > arch/arm/cpu/armv7/tegra30/
> > arch/arm/cpu/armv7/tegra114/
> > arch/arm/cpu/armv7/tegra124/
> > arch/arm/include/asm/arch-tegra/
> > arch/asm/include/asm/arch-tegra20/
> > arch/asm/include/asm/arch-tegra30/
> > arch/asm/include/asm/arch-tegra114/
> > arch/asm/include/asm/arch-tegra124/
> > 
> > 
> > They can be refactored
> > 
> > arch/arm/mach-tegra/                      : tegra common part
> > arch/arm/mach-tegra/tegra20/         : tegra20-specific
> > arch/arm/mach-tegra/tegra30/         : tegra30-specific
> > arch/arm/mach-tegra/tegra114/       : tegra114-specific
> > arch/arm/mach-tegra/tegra124/       : tegra124-specific
> 
> Again, we have different CPU cores here, and thus pretty much
> different code - what would be the benefit of mixing unrelated code
> in a single directory?
> 

At lease, they are developed by the same LSI vendor.
And the code is maintained by the same person:


Besides, 
arch/arm/cpu/armv7/tegra30/
arch/arm/cpu/armv7/tegra114/
arch/arm/cpu/armv7/tegra124/

are empty. 
These directories exist just to meet the requirement of
arch/${ARCH}/cpu/${CPU}/${SOC}  structure.

Without those dummy directories, build fails.



Best Regards
Masahiro Yamada