Dear Macpaul Lin,
In message AANLkTinWnzXRV=iUqNrp_fsbN+4uKBpJLHYuXj_KOU0w@mail.gmail.com you wrote:
- Include path problem.
For example, Faraday a320 uses the same peripheral as AndesTech ag101. A320 and Ag101 will include the same header files for the same peripheral devices which are built-in into the SoC.
These SoC built-in devices include, ftsmc020.c (flash controller, arch/arm/cpu/arm920t/a320/ftsmc020.c), ftsmc020.h (flash controller, arch/arm/include/asm/arch-a320/ftsmc020.h),
ftpmu010.h (power controller, arch/arm/include/asm/arch-a320/ftpmu010.h), ftsdmc020.h (SDRAM controller, arch/arm/include/asm/arch-a320/ftsdmc020.h), fttmr010.h (RTC, arch/arm/include/asm/arch-a320/fttmr010.h).
The flash controller ftsmc020 has both assembly (offset table) and C code (structure).
The offset table should be removed. We can and should use include/generated/*-asm-offsets.h now. Just make sure the needed symbols are included.
The other devices as assembly code only because they will be initialized in lowlevel_init.S or in board.S
This is something that should be reconsidered. Why has this to be done in assembler code, and cannot - for example - be delayed until we have a C environment?
Especially the SDRAM initialization is normally done from C anyway, so why do we need it here?
1.1 At current situation, if ag101 want to include the device header file above, the code whether in "include/configs/adp-ag101.h" or in lowlevel_init.S will looks like.
#define CONFIG_FTSMC020 #ifdef CONFIG_FTSMC020 #include "../../../arch/arm/includes/asm/arch-a320/ftsmc020.h"
This is just an indication that the location of the file is not correct. If it's not a320 specific (which obliously is the case) it should be moved into a common header directory.
1.2 Even we move those header files into proper place, this problem still occur. For example, if we put ftsmc020.h and ftsmc020.c into "drivers/mtd" folder.
It seems this is not an appropriate folder. Why do you suggest this one?
- There is possibility we initialize device in lowlevel_init.S then
reconfigure it in C level code. Such as sdram controller and flash controller.
SDRAM should not be initialized in lowlevel_init.S. Please use the (new for ARM, shared with PPC which has always been using this) model where RAM initialization is done in dram_init(), i. e. as part of the init sequence in arch/arm/lib/board.c
For example, in "arch/arm/include/asm/arch-at91/at91_mc.h" and in "arch/arm/include/asm/arch-a320/ftsmc020.h" There both exist assembly offset and C type structures. Once other SoC use the same device controller whether in lowlevel_int.S and in board.c, it will have include problem as described in #1 and in #2.
See above - this means that the header file needs to be moved to acommon include directory.
- If you execute 'grep -rnH "../../Marvell/" *' in the root of u-boot
code, you will find the similar situation about sharing header files with same devices. Includes, pci.h, memory.h, core.h, i2c.h. I guess even these devices is built-in in the SoC (chip), it is better to go to "drivers" folder
drivers is not a common include directory, and thus not the right place.
instead of "board/Marvell/common/".
That may be true.
However, even we created a folder specific for a set of built-in devices, we still encounter the include path like:
Why do you make it so complicated? Just move common files to a _common_ header directory under include/ (and not drivers/).
- Some shared header files of devices like "ftpmu010.h".
The header file "ftpmu010.h" has only register and offset definitions. Should this kind of file go to "drivers" folder or go to "include" folder?
1) offset definitions should be removed; instead, *-asm-offsets.h should be used.
2) drivers/ is not a location for common header files that are referenced by non-driver code. Use include/ for such common code, assuming it is really common to all architectures. Use arch/arm/include/ if it's common to ARM systems only.
Since they are configured like a device drivers in a SoC (in board.c or in lowlevel_init.S). I guess they should be put into "drivers" folder.
If this is common driver code, the code itself should be moved to drivers (and then, and only then, the header files with the code).
Best regards,
Wolfgang Denk