* [U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC @ 2019-02-18 13:05 Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 2/6] ARM: rmobile: Imply pinctrl " Marek Vasut ` (4 more replies) 0 siblings, 5 replies; 13+ messages in thread From: Marek Vasut @ 2019-02-18 13:05 UTC (permalink / raw) To: u-boot Imply preferred clock driver per SoC, no functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> --- arch/arm/mach-rmobile/Kconfig.32 | 5 +++++ arch/arm/mach-rmobile/Kconfig.64 | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32 index 076a019135..5d9da49c92 100644 --- a/arch/arm/mach-rmobile/Kconfig.32 +++ b/arch/arm/mach-rmobile/Kconfig.32 @@ -16,25 +16,30 @@ config R8A7790 bool "Renesas SoC R8A7790" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7790 config R8A7791 bool "Renesas SoC R8A7791" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7791 config R8A7792 bool "Renesas SoC R8A7792" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7792 config R8A7793 bool "Renesas SoC R8A7793" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7793 config R8A7794 bool "Renesas SoC R8A7794" select RCAR_GEN2 + imply CLK_R8A7794 choice prompt "Renesas ARM SoCs board select" diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64 index cb9f569e5f..d84c0617d1 100644 --- a/arch/arm/mach-rmobile/Kconfig.64 +++ b/arch/arm/mach-rmobile/Kconfig.64 @@ -5,18 +5,23 @@ choice config R8A7795 bool "Renesas SoC R8A7795" + imply CLK_R8A7795 config R8A7796 bool "Renesas SoC R8A7796" + imply CLK_R8A7796 config R8A77970 bool "Renesas SoC R8A77970" + imply CLK_R8A77970 config R8A77990 bool "Renesas SoC R8A77990" + imply CLK_R8A77990 config R8A77995 bool "Renesas SoC R8A77995" + imply CLK_R8A77995 endchoice -- 2.19.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/6] ARM: rmobile: Imply pinctrl drivers per SoC 2019-02-18 13:05 [U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC Marek Vasut @ 2019-02-18 13:05 ` Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 3/6] clk: rmobile: Drop def_bool " Marek Vasut ` (3 subsequent siblings) 4 siblings, 0 replies; 13+ messages in thread From: Marek Vasut @ 2019-02-18 13:05 UTC (permalink / raw) To: u-boot Imply preferred pin control driver per SoC, no functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> --- arch/arm/mach-rmobile/Kconfig.32 | 5 +++++ arch/arm/mach-rmobile/Kconfig.64 | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32 index 5d9da49c92..67f669a6fc 100644 --- a/arch/arm/mach-rmobile/Kconfig.32 +++ b/arch/arm/mach-rmobile/Kconfig.32 @@ -17,29 +17,34 @@ config R8A7790 select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7790 + imply PINCTRL_PFC_R8A7790 config R8A7791 bool "Renesas SoC R8A7791" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7791 + imply PINCTRL_PFC_R8A7791 config R8A7792 bool "Renesas SoC R8A7792" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7792 + imply PINCTRL_PFC_R8A7792 config R8A7793 bool "Renesas SoC R8A7793" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7793 + imply PINCTRL_PFC_R8A7793 config R8A7794 bool "Renesas SoC R8A7794" select RCAR_GEN2 imply CLK_R8A7794 + imply PINCTRL_PFC_R8A7794 choice prompt "Renesas ARM SoCs board select" diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64 index d84c0617d1..d231263574 100644 --- a/arch/arm/mach-rmobile/Kconfig.64 +++ b/arch/arm/mach-rmobile/Kconfig.64 @@ -6,22 +6,27 @@ choice config R8A7795 bool "Renesas SoC R8A7795" imply CLK_R8A7795 + imply PINCTRL_PFC_R8A7795 config R8A7796 bool "Renesas SoC R8A7796" imply CLK_R8A7796 + imply PINCTRL_PFC_R8A7796 config R8A77970 bool "Renesas SoC R8A77970" imply CLK_R8A77970 + imply PINCTRL_PFC_R8A77970 config R8A77990 bool "Renesas SoC R8A77990" imply CLK_R8A77990 + imply PINCTRL_PFC_R8A77990 config R8A77995 bool "Renesas SoC R8A77995" imply CLK_R8A77995 + imply PINCTRL_PFC_R8A77995 endchoice -- 2.19.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 3/6] clk: rmobile: Drop def_bool per SoC 2019-02-18 13:05 [U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 2/6] ARM: rmobile: Imply pinctrl " Marek Vasut @ 2019-02-18 13:05 ` Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 4/6] pinctrl: renesas: " Marek Vasut ` (2 subsequent siblings) 4 siblings, 0 replies; 13+ messages in thread From: Marek Vasut @ 2019-02-18 13:05 UTC (permalink / raw) To: u-boot Drop per SoC def_bool on each driver, since this is now implied by SoC Kconfig option instead. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> --- drivers/clk/renesas/Kconfig | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig index 578e6a8049..e062eccdae 100644 --- a/drivers/clk/renesas/Kconfig +++ b/drivers/clk/renesas/Kconfig @@ -13,35 +13,30 @@ config CLK_RCAR_GEN2 config CLK_R8A7790 bool "Renesas R8A7790 clock driver" - def_bool y if R8A7790 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7790 SoC. config CLK_R8A7791 bool "Renesas R8A7791 clock driver" - def_bool y if R8A7791 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7791 SoC. config CLK_R8A7792 bool "Renesas R8A7792 clock driver" - def_bool y if R8A7792 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7792 SoC. config CLK_R8A7793 bool "Renesas R8A7793 clock driver" - def_bool y if R8A7793 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7793 SoC. config CLK_R8A7794 bool "Renesas R8A7794 clock driver" - def_bool y if R8A7794 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7794 SoC. @@ -55,35 +50,30 @@ config CLK_RCAR_GEN3 config CLK_R8A7795 bool "Renesas R8A7795 clock driver" - def_bool y if R8A7795 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A7795 SoC. config CLK_R8A7796 bool "Renesas R8A7796 clock driver" - def_bool y if R8A7796 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A7796 SoC. config CLK_R8A77970 bool "Renesas R8A77970 clock driver" - def_bool y if R8A77970 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A77970 SoC. config CLK_R8A77990 bool "Renesas R8A77990 clock driver" - def_bool y if R8A77990 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A77990 SoC. config CLK_R8A77995 bool "Renesas R8A77995 clock driver" - def_bool y if R8A77995 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A77995 SoC. -- 2.19.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 4/6] pinctrl: renesas: Drop def_bool per SoC 2019-02-18 13:05 [U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 2/6] ARM: rmobile: Imply pinctrl " Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 3/6] clk: rmobile: Drop def_bool " Marek Vasut @ 2019-02-18 13:05 ` Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 5/6] ARM: rmobile: Imply SoC per board Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs Marek Vasut 4 siblings, 0 replies; 13+ messages in thread From: Marek Vasut @ 2019-02-18 13:05 UTC (permalink / raw) To: u-boot Drop per SoC def_bool on each driver, since this is now implied by SoC Kconfig option instead. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> --- drivers/pinctrl/renesas/Kconfig | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/pinctrl/renesas/Kconfig b/drivers/pinctrl/renesas/Kconfig index 1baab9088a..0cb577037c 100644 --- a/drivers/pinctrl/renesas/Kconfig +++ b/drivers/pinctrl/renesas/Kconfig @@ -8,7 +8,6 @@ config PINCTRL_PFC config PINCTRL_PFC_R8A7790 bool "Renesas RCar Gen2 R8A7790 pin control driver" - def_bool y if R8A7790 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7790 SoCs. @@ -19,7 +18,6 @@ config PINCTRL_PFC_R8A7790 config PINCTRL_PFC_R8A7791 bool "Renesas RCar Gen2 R8A7791 pin control driver" - def_bool y if R8A7791 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7791 SoCs. @@ -30,7 +28,6 @@ config PINCTRL_PFC_R8A7791 config PINCTRL_PFC_R8A7792 bool "Renesas RCar Gen2 R8A7792 pin control driver" - def_bool y if R8A7792 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7792 SoCs. @@ -41,7 +38,6 @@ config PINCTRL_PFC_R8A7792 config PINCTRL_PFC_R8A7793 bool "Renesas RCar Gen2 R8A7793 pin control driver" - def_bool y if R8A7793 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7793 SoCs. @@ -52,7 +48,6 @@ config PINCTRL_PFC_R8A7793 config PINCTRL_PFC_R8A7794 bool "Renesas RCar Gen2 R8A7794 pin control driver" - def_bool y if R8A7794 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7794 SoCs. @@ -63,7 +58,6 @@ config PINCTRL_PFC_R8A7794 config PINCTRL_PFC_R8A7795 bool "Renesas RCar Gen3 R8A7795 pin control driver" - def_bool y if R8A7795 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7795 SoCs. @@ -74,7 +68,6 @@ config PINCTRL_PFC_R8A7795 config PINCTRL_PFC_R8A7796 bool "Renesas RCar Gen3 R8A7796 pin control driver" - def_bool y if R8A7796 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7796 SoCs. @@ -85,7 +78,6 @@ config PINCTRL_PFC_R8A7796 config PINCTRL_PFC_R8A77970 bool "Renesas RCar Gen3 R8A77970 pin control driver" - def_bool y if R8A77970 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A77970 SoCs. @@ -96,7 +88,6 @@ config PINCTRL_PFC_R8A77970 config PINCTRL_PFC_R8A77990 bool "Renesas RCar Gen3 R8A77990 pin control driver" - def_bool y if R8A77990 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A77990 SoCs. @@ -107,7 +98,6 @@ config PINCTRL_PFC_R8A77990 config PINCTRL_PFC_R8A77995 bool "Renesas RCar Gen3 R8A77995 pin control driver" - def_bool y if R8A77995 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A77995 SoCs. -- 2.19.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 5/6] ARM: rmobile: Imply SoC per board 2019-02-18 13:05 [U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC Marek Vasut ` (2 preceding siblings ...) 2019-02-18 13:05 ` [U-Boot] [PATCH 4/6] pinctrl: renesas: " Marek Vasut @ 2019-02-18 13:05 ` Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs Marek Vasut 4 siblings, 0 replies; 13+ messages in thread From: Marek Vasut @ 2019-02-18 13:05 UTC (permalink / raw) To: u-boot Imply all SoCs supported by a given board. This allows building single U-Boot binary for boards which can have multiple SoCs. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> --- arch/arm/mach-rmobile/Kconfig.64 | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64 index d231263574..b2ac1cdad7 100644 --- a/arch/arm/mach-rmobile/Kconfig.64 +++ b/arch/arm/mach-rmobile/Kconfig.64 @@ -1,7 +1,6 @@ if RCAR_GEN3 -choice - prompt "Select Target SoC" +menu "Select Target SoC" config R8A7795 bool "Renesas SoC R8A7795" @@ -28,34 +27,41 @@ config R8A77995 imply CLK_R8A77995 imply PINCTRL_PFC_R8A77995 -endchoice +endmenu choice - prompt "Renesus ARM64 SoCs board select" + prompt "Renesas ARM64 SoCs board select" optional config TARGET_DRAAK bool "Draak board" + imply R8A77995 help Support for Renesas R-Car Gen3 Draak platform config TARGET_EAGLE bool "Eagle board" + imply R8A77970 help Support for Renesas R-Car Gen3 Eagle platform config TARGET_EBISU bool "Ebisu board" + imply R8A77990 help Support for Renesas R-Car Gen3 Ebisu platform config TARGET_SALVATOR_X bool "Salvator-X board" + imply R8A7795 + imply R8A7796 help Support for Renesas R-Car Gen3 platform config TARGET_ULCB bool "ULCB board" + imply R8A7795 + imply R8A7796 help Support for Renesas R-Car Gen3 ULCB platform -- 2.19.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-02-18 13:05 [U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC Marek Vasut ` (3 preceding siblings ...) 2019-02-18 13:05 ` [U-Boot] [PATCH 5/6] ARM: rmobile: Imply SoC per board Marek Vasut @ 2019-02-18 13:05 ` Marek Vasut 2019-03-04 21:36 ` Eugeniu Rosca 4 siblings, 1 reply; 13+ messages in thread From: Marek Vasut @ 2019-02-18 13:05 UTC (permalink / raw) To: u-boot Synchronize Gen3 defconfigs in wake of the Kconfig option changes. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> --- configs/r8a77965_salvator-x_defconfig | 1 - configs/r8a7796_salvator-x_defconfig | 1 - configs/r8a7796_ulcb_defconfig | 1 - 3 files changed, 3 deletions(-) diff --git a/configs/r8a77965_salvator-x_defconfig b/configs/r8a77965_salvator-x_defconfig index 82ebab06c3..9965036123 100644 --- a/configs/r8a77965_salvator-x_defconfig +++ b/configs/r8a77965_salvator-x_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x50000000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_SALVATOR_X=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y diff --git a/configs/r8a7796_salvator-x_defconfig b/configs/r8a7796_salvator-x_defconfig index ae0555cd85..09626bf8b6 100644 --- a/configs/r8a7796_salvator-x_defconfig +++ b/configs/r8a7796_salvator-x_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x50000000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_SALVATOR_X=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y diff --git a/configs/r8a7796_ulcb_defconfig b/configs/r8a7796_ulcb_defconfig index f3781a57e2..1f2de9d71b 100644 --- a/configs/r8a7796_ulcb_defconfig +++ b/configs/r8a7796_ulcb_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x50000000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_ULCB=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y -- 2.19.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-02-18 13:05 ` [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs Marek Vasut @ 2019-03-04 21:36 ` Eugeniu Rosca 2019-03-04 22:03 ` Marek Vasut 0 siblings, 1 reply; 13+ messages in thread From: Eugeniu Rosca @ 2019-03-04 21:36 UTC (permalink / raw) To: u-boot Hello Marek, Thanks to great maintenance, the R-Car3 defconfigs look strikingly similar. Do you think it would make sense to relocate the common parts into rcar{3,-gen3}_defconfig and the unique per-board options into config fragments resembling the current R-Car3 defconfig structure? $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/' configs/r8a7795_salvator-x.cfg configs/r8a7795_ulcb.cfg configs/r8a77965_salvator-x.cfg configs/r8a7796_salvator-x.cfg configs/r8a7796_ulcb.cfg configs/r8a77970_eagle.cfg configs/r8a77990_ebisu.cfg configs/r8a77995_draak.cfg In this case, I believe each fragment would contain under 10 Kconfig symbols and the `make <board>_defconfig` procedure would change to `make rcar{3,-gen3}_defconfig <board>.cfg`. Best regards, Eugeniu. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-03-04 21:36 ` Eugeniu Rosca @ 2019-03-04 22:03 ` Marek Vasut 2019-03-04 23:40 ` Eugeniu Rosca 0 siblings, 1 reply; 13+ messages in thread From: Marek Vasut @ 2019-03-04 22:03 UTC (permalink / raw) To: u-boot On 3/4/19 10:36 PM, Eugeniu Rosca wrote: > Hello Marek, Hi, > Thanks to great maintenance, the R-Car3 defconfigs look strikingly similar. That's the goal for this release, to make them look similar. > Do you think it would make sense to relocate the common parts into > rcar{3,-gen3}_defconfig and the unique per-board options into config > fragments resembling the current R-Car3 defconfig structure? > > $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/' > configs/r8a7795_salvator-x.cfg > configs/r8a7795_ulcb.cfg > configs/r8a77965_salvator-x.cfg > configs/r8a7796_salvator-x.cfg > configs/r8a7796_ulcb.cfg > configs/r8a77970_eagle.cfg > configs/r8a77990_ebisu.cfg > configs/r8a77995_draak.cfg > > In this case, I believe each fragment would contain under 10 Kconfig > symbols and the `make <board>_defconfig` procedure would change > to `make rcar{3,-gen3}_defconfig <board>.cfg`. I was pondering whether there's some way to factor out the common parts, or maybe even replace some of the defconfigs with a placeholder for compatibility reasons and just go with one full defconfig for all SoCs (H3/M3W/M3N) that can be on such a board. I'd still like to be able to do "make soc_board_defconfig ; make" without having to rack my brain which other .cfg files I need to append. I didn't find a good solution for this however. Do you know of one ? -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-03-04 22:03 ` Marek Vasut @ 2019-03-04 23:40 ` Eugeniu Rosca 2019-03-05 3:36 ` Marek Vasut 2019-03-07 13:54 ` Masahiro Yamada 0 siblings, 2 replies; 13+ messages in thread From: Eugeniu Rosca @ 2019-03-04 23:40 UTC (permalink / raw) To: u-boot cc: Masahiro (due to Kconfig topic) Hi Marek, On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote: > On 3/4/19 10:36 PM, Eugeniu Rosca wrote: > > Hello Marek, <-snip-> > > Do you think it would make sense to relocate the common parts into > > rcar{3,-gen3}_defconfig and the unique per-board options into config > > fragments resembling the current R-Car3 defconfig structure? > > > > $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/' > > configs/r8a7795_salvator-x.cfg > > configs/r8a7795_ulcb.cfg > > configs/r8a77965_salvator-x.cfg > > configs/r8a7796_salvator-x.cfg > > configs/r8a7796_ulcb.cfg > > configs/r8a77970_eagle.cfg > > configs/r8a77990_ebisu.cfg > > configs/r8a77995_draak.cfg > > > > In this case, I believe each fragment would contain under 10 Kconfig > > symbols and the `make <board>_defconfig` procedure would change > > to `make rcar{3,-gen3}_defconfig <board>.cfg`. > > I was pondering whether there's some way to factor out the common parts, > or maybe even replace some of the defconfigs with a placeholder for > compatibility reasons and just go with one full defconfig for all SoCs > (H3/M3W/M3N) that can be on such a board. > > I'd still like to be able to do "make soc_board_defconfig ; make" > without having to rack my brain which other .cfg files I need to append. > I didn't find a good solution for this however. Do you know of one ? I think we have proper tools to track the correctness of the defconfig files (i.e. savedefconfig Kbuild target), but we don't seem to have proper tools to validate configuration fragments. So, I agree the contents of the fragments would potentially go wild. I think having either a built-in Kbuild/Kconfig procedure or some scripted way to keep the fragments under control would greatly increase the confidence in using them, but I am unaware of such. JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3 defconfigs: $> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779* configs/r8a7795_salvator-x_defconfig configs/r8a7795_salvator-xs-2x2g_defconfig configs/r8a7795_salvator-xs-4x2g_defconfig configs/r8a7795_salvator-xs_defconfig configs/r8a7795_ulcb-4x2g_defconfig configs/r8a7795_ulcb_defconfig configs/r8a77965_salvator-x_defconfig configs/r8a77965_salvator-xs_defconfig configs/r8a77965_ulcb_defconfig configs/r8a7796_salvator-x_defconfig configs/r8a7796_salvator-xs_defconfig configs/r8a7796_ulcb_defconfig configs/r8a77970_eagle_defconfig configs/r8a77990_ebisu-4d_defconfig configs/r8a77990_ebisu_defconfig configs/r8a77995_draak_defconfig So, changing/adding/removing a common option (most of them are) implies quite an amount of maintenance effort on our side. I would greatly appreciate any ideas how to alleviate that. > > -- > Best regards, > Marek Vasut Best regards, Eugeniu. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-03-04 23:40 ` Eugeniu Rosca @ 2019-03-05 3:36 ` Marek Vasut 2019-03-07 13:54 ` Masahiro Yamada 1 sibling, 0 replies; 13+ messages in thread From: Marek Vasut @ 2019-03-05 3:36 UTC (permalink / raw) To: u-boot On 3/5/19 12:40 AM, Eugeniu Rosca wrote: > cc: Masahiro (due to Kconfig topic) > > Hi Marek, Hi, > On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote: >> On 3/4/19 10:36 PM, Eugeniu Rosca wrote: >>> Hello Marek, > > <-snip-> > >>> Do you think it would make sense to relocate the common parts into >>> rcar{3,-gen3}_defconfig and the unique per-board options into config >>> fragments resembling the current R-Car3 defconfig structure? >>> >>> $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/' >>> configs/r8a7795_salvator-x.cfg >>> configs/r8a7795_ulcb.cfg >>> configs/r8a77965_salvator-x.cfg >>> configs/r8a7796_salvator-x.cfg >>> configs/r8a7796_ulcb.cfg >>> configs/r8a77970_eagle.cfg >>> configs/r8a77990_ebisu.cfg >>> configs/r8a77995_draak.cfg >>> >>> In this case, I believe each fragment would contain under 10 Kconfig >>> symbols and the `make <board>_defconfig` procedure would change >>> to `make rcar{3,-gen3}_defconfig <board>.cfg`. >> >> I was pondering whether there's some way to factor out the common parts, >> or maybe even replace some of the defconfigs with a placeholder for >> compatibility reasons and just go with one full defconfig for all SoCs >> (H3/M3W/M3N) that can be on such a board. >> >> I'd still like to be able to do "make soc_board_defconfig ; make" >> without having to rack my brain which other .cfg files I need to append. >> I didn't find a good solution for this however. Do you know of one ? > > I think we have proper tools to track the correctness of the defconfig > files (i.e. savedefconfig Kbuild target), but we don't seem to have > proper tools to validate configuration fragments. So, I agree the > contents of the fragments would potentially go wild. I think having > either a built-in Kbuild/Kconfig procedure or some scripted way to keep > the fragments under control would greatly increase the confidence in > using them, but I am unaware of such. > > JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3 > defconfigs: > > $> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779* > configs/r8a7795_salvator-x_defconfig > configs/r8a7795_salvator-xs-2x2g_defconfig > configs/r8a7795_salvator-xs-4x2g_defconfig > configs/r8a7795_salvator-xs_defconfig > configs/r8a7795_ulcb-4x2g_defconfig > configs/r8a7795_ulcb_defconfig > configs/r8a77965_salvator-x_defconfig > configs/r8a77965_salvator-xs_defconfig > configs/r8a77965_ulcb_defconfig > configs/r8a7796_salvator-x_defconfig > configs/r8a7796_salvator-xs_defconfig > configs/r8a7796_ulcb_defconfig > configs/r8a77970_eagle_defconfig > configs/r8a77990_ebisu-4d_defconfig > configs/r8a77990_ebisu_defconfig > configs/r8a77995_draak_defconfig > > So, changing/adding/removing a common option (most of them are) implies > quite an amount of maintenance effort on our side. I would greatly > appreciate any ideas how to alleviate that. Mainline ATF passes the DRAM configuration to U-Boot as a DT fragment in register x1, so that takes care of those defconfigs for different DRAM sizes (I just need to upstream patch which parses that DT fragment, which is work in progress [1]; for next release). The salvator-x and salvator-xs differences aren't applicable to U-Boot, so we can ignore those for now. Once they become applicable, we can probably use the ATF DT fragment to discern those two board revisions too. r8a779{5,6,65}_salvator-x_defconfig and r8a779{5,6,65}_ulcb_defconfig could be merged into single defconfig using multi-dtb FIT, it makes the U-Boot grow quite a bit, but this might be OK here. We already do that. And ultimately, I don't think we'll need any fragments if we end up with a defconfig for r8a779*_salvator-x, r8a779*_ulcb, r8a77970_eagle, r8a77990_ebisu, r8a77995_draak , that's 5 targets in total. We might add r8a77980_condor at some point, but that's still manageable. So in my opinion, all we need to figure out now is how to maintain some sort of backward compatibility, and have eg r8a7795_salvator-x_defconfig become a symlink (?) to some r8a779x_salvator-x_defconfig . Thoughts ? [1] http://patchwork.ozlabs.org/project/uboot/list/?series=95413 -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-03-04 23:40 ` Eugeniu Rosca 2019-03-05 3:36 ` Marek Vasut @ 2019-03-07 13:54 ` Masahiro Yamada 2019-03-07 14:47 ` Ismael Luceno Cortes 2019-03-07 20:21 ` Marek Vasut 1 sibling, 2 replies; 13+ messages in thread From: Masahiro Yamada @ 2019-03-07 13:54 UTC (permalink / raw) To: u-boot Hi. Sorry for chiming in late. On Tue, Mar 5, 2019 at 8:41 AM Eugeniu Rosca <erosca@de.adit-jv.com> wrote: > > cc: Masahiro (due to Kconfig topic) > > Hi Marek, > > On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote: > > On 3/4/19 10:36 PM, Eugeniu Rosca wrote: > > > Hello Marek, > > <-snip-> > > > > Do you think it would make sense to relocate the common parts into > > > rcar{3,-gen3}_defconfig and the unique per-board options into config > > > fragments resembling the current R-Car3 defconfig structure? > > > > > > $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/' > > > configs/r8a7795_salvator-x.cfg > > > configs/r8a7795_ulcb.cfg > > > configs/r8a77965_salvator-x.cfg > > > configs/r8a7796_salvator-x.cfg > > > configs/r8a7796_ulcb.cfg > > > configs/r8a77970_eagle.cfg > > > configs/r8a77990_ebisu.cfg > > > configs/r8a77995_draak.cfg > > > > > > In this case, I believe each fragment would contain under 10 Kconfig > > > symbols and the `make <board>_defconfig` procedure would change > > > to `make rcar{3,-gen3}_defconfig <board>.cfg`. In fact, I suggested make <soc>_defconfig <board>.config some time ago, but I did not get positive feedback. The reason was, it would be tedious to type a series of config files, and also it would break the upper-level projects such as OE recipes, buildroot, etc. > > I was pondering whether there's some way to factor out the common parts, > > or maybe even replace some of the defconfigs with a placeholder for > > compatibility reasons and just go with one full defconfig for all SoCs > > (H3/M3W/M3N) that can be on such a board. I manage my boards this way. I have only three defconfig files: uniphier_ld4_sld8_defconfig uniphier_v7_defconfig uniphier_v8_defconfig Each defconfig supports multiple boards by using a different DEVICE_TREE. If you are interested, doc/README.uniphier explains it supports much more boards than defconfig. The drawback of this ways will increase the image size since it needs to compile-in all necessary boot-code and drivers. So, this solution only works when you have enough memory footprint. > > > > I'd still like to be able to do "make soc_board_defconfig ; make" > > without having to rack my brain which other .cfg files I need to append. > > I didn't find a good solution for this however. Do you know of one ? One idea might be, to hack scripts/kconfig/Makefile to allow a defconfig to contain shell scripts. For example, r8a7795_salvator-x_defconfig will look like: #!/bin/sh $MAKE r8a7795_defconfig $MAKE r8a7795_salvator-x.config Makefile will run it if the first line is shebang, otherwise handle it as a normal defconfig. I am not so sure if this is the right thing to do. So, it should be discussed widely anyway if we try to introduce something new. A problem in this way is, as Eugeniu pointed out, we have no way to sync .config fragment files. > I think we have proper tools to track the correctness of the defconfig > files (i.e. savedefconfig Kbuild target), but we don't seem to have > proper tools to validate configuration fragments. So, I agree the > contents of the fragments would potentially go wild. I think having > either a built-in Kbuild/Kconfig procedure or some scripted way to keep > the fragments under control would greatly increase the confidence in > using them, but I am unaware of such. You are right. We will need something like savedefconfig for .config files, but we do not have a good tool. At least, I do not know. Thanks. > JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3 > defconfigs: > > $> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779* > configs/r8a7795_salvator-x_defconfig > configs/r8a7795_salvator-xs-2x2g_defconfig > configs/r8a7795_salvator-xs-4x2g_defconfig > configs/r8a7795_salvator-xs_defconfig > configs/r8a7795_ulcb-4x2g_defconfig > configs/r8a7795_ulcb_defconfig > configs/r8a77965_salvator-x_defconfig > configs/r8a77965_salvator-xs_defconfig > configs/r8a77965_ulcb_defconfig > configs/r8a7796_salvator-x_defconfig > configs/r8a7796_salvator-xs_defconfig > configs/r8a7796_ulcb_defconfig > configs/r8a77970_eagle_defconfig > configs/r8a77990_ebisu-4d_defconfig > configs/r8a77990_ebisu_defconfig > configs/r8a77995_draak_defconfig > > So, changing/adding/removing a common option (most of them are) implies > quite an amount of maintenance effort on our side. I would greatly > appreciate any ideas how to alleviate that. > > > > > -- > > Best regards, > > Marek Vasut > > Best regards, > Eugeniu. > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-03-07 13:54 ` Masahiro Yamada @ 2019-03-07 14:47 ` Ismael Luceno Cortes 2019-03-07 20:21 ` Marek Vasut 1 sibling, 0 replies; 13+ messages in thread From: Ismael Luceno Cortes @ 2019-03-07 14:47 UTC (permalink / raw) To: u-boot On 07/Mar/2019 22:54, Masahiro Yamada wrote: <...> > Each defconfig supports multiple boards > by using a different DEVICE_TREE. > > If you are interested, doc/README.uniphier > explains it supports much more boards than defconfig. > > The drawback of this ways will increase the image size > since it needs to compile-in all necessary > boot-code and drivers. > So, this solution only works when you have enough > memory footprint. > > > > > > > > I'd still like to be able to do "make soc_board_defconfig ; make" > > > without having to rack my brain which other .cfg files I need to append. > > > I didn't find a good solution for this however. Do you know of one ? > > One idea might be, > to hack scripts/kconfig/Makefile > to allow a defconfig to contain shell scripts. > > > For example, r8a7795_salvator-x_defconfig will look like: > > #!/bin/sh > $MAKE r8a7795_defconfig > $MAKE r8a7795_salvator-x.config > > > Makefile will run it if the first line is shebang, > otherwise handle it as a normal defconfig. > > > I am not so sure if this is the right thing to do. > So, it should be discussed widely anyway if we try to > introduce something new. > > A problem in this way is, as Eugeniu pointed out, > we have no way to sync .config fragment files. > > > > I think we have proper tools to track the correctness of the defconfig > > files (i.e. savedefconfig Kbuild target), but we don't seem to have > > proper tools to validate configuration fragments. So, I agree the > > contents of the fragments would potentially go wild. I think having > > either a built-in Kbuild/Kconfig procedure or some scripted way to keep > > the fragments under control would greatly increase the confidence in > > using them, but I am unaware of such. > > You are right. > > We will need something like savedefconfig for .config files, > but we do not have a good tool. At least, I do not know. Perhaps a simpler solution would be to add support for some sort of selection mechanism. E.g.: family_defconfig: A=y if (SOC in {"A", "B", "C"}) board_A.config: SOC="C" So that .config files can contain only simple meta-data; and both things would be easy to validate. There's a little impedance mismatch here and there, but it could work, and the needed effort seems reasonable. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs 2019-03-07 13:54 ` Masahiro Yamada 2019-03-07 14:47 ` Ismael Luceno Cortes @ 2019-03-07 20:21 ` Marek Vasut 1 sibling, 0 replies; 13+ messages in thread From: Marek Vasut @ 2019-03-07 20:21 UTC (permalink / raw) To: u-boot On 3/7/19 2:54 PM, Masahiro Yamada wrote: > Hi. Hi! > Sorry for chiming in late. > > > On Tue, Mar 5, 2019 at 8:41 AM Eugeniu Rosca <erosca@de.adit-jv.com> wrote: >> >> cc: Masahiro (due to Kconfig topic) >> >> Hi Marek, >> >> On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote: >>> On 3/4/19 10:36 PM, Eugeniu Rosca wrote: >>>> Hello Marek, >> >> <-snip-> >> >>>> Do you think it would make sense to relocate the common parts into >>>> rcar{3,-gen3}_defconfig and the unique per-board options into config >>>> fragments resembling the current R-Car3 defconfig structure? >>>> >>>> $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/' >>>> configs/r8a7795_salvator-x.cfg >>>> configs/r8a7795_ulcb.cfg >>>> configs/r8a77965_salvator-x.cfg >>>> configs/r8a7796_salvator-x.cfg >>>> configs/r8a7796_ulcb.cfg >>>> configs/r8a77970_eagle.cfg >>>> configs/r8a77990_ebisu.cfg >>>> configs/r8a77995_draak.cfg >>>> >>>> In this case, I believe each fragment would contain under 10 Kconfig >>>> symbols and the `make <board>_defconfig` procedure would change >>>> to `make rcar{3,-gen3}_defconfig <board>.cfg`. > > > In fact, I suggested > > make <soc>_defconfig <board>.config > > some time ago, but I did not get positive feedback. I can imagine, this looks like crappy. It should be automatic, like some sort of Kconfig "include directives" or somesuch. > The reason was, it would be tedious to type a series of config files, > and also it would break the upper-level projects > such as OE recipes, buildroot, etc. Right >>> I was pondering whether there's some way to factor out the common parts, >>> or maybe even replace some of the defconfigs with a placeholder for >>> compatibility reasons and just go with one full defconfig for all SoCs >>> (H3/M3W/M3N) that can be on such a board. > > I manage my boards this way. > > I have only three defconfig files: > uniphier_ld4_sld8_defconfig > uniphier_v7_defconfig > uniphier_v8_defconfig > > > Each defconfig supports multiple boards > by using a different DEVICE_TREE. > > If you are interested, doc/README.uniphier > explains it supports much more boards than defconfig. > > The drawback of this ways will increase the image size > since it needs to compile-in all necessary > boot-code and drivers. > So, this solution only works when you have enough > memory footprint. That's fine, I'm mostly looking for some backward compatibility option, so that I can retain the old defconfig names and e.g. turn them into symlinks. Maybe I should just remove the soon-to-be-duplicate files and be done with it, might be the easiest solution. >>> I'd still like to be able to do "make soc_board_defconfig ; make" >>> without having to rack my brain which other .cfg files I need to append. >>> I didn't find a good solution for this however. Do you know of one ? > > One idea might be, > to hack scripts/kconfig/Makefile > to allow a defconfig to contain shell scripts. > > > For example, r8a7795_salvator-x_defconfig will look like: > > #!/bin/sh > $MAKE r8a7795_defconfig > $MAKE r8a7795_salvator-x.config > > > Makefile will run it if the first line is shebang, > otherwise handle it as a normal defconfig. > > > I am not so sure if this is the right thing to do. > So, it should be discussed widely anyway if we try to > introduce something new. > > A problem in this way is, as Eugeniu pointed out, > we have no way to sync .config fragment files. > > >> I think we have proper tools to track the correctness of the defconfig >> files (i.e. savedefconfig Kbuild target), but we don't seem to have >> proper tools to validate configuration fragments. So, I agree the >> contents of the fragments would potentially go wild. I think having >> either a built-in Kbuild/Kconfig procedure or some scripted way to keep >> the fragments under control would greatly increase the confidence in >> using them, but I am unaware of such. > > You are right. > > We will need something like savedefconfig for .config files, > but we do not have a good tool. At least, I do not know. > > > Thanks. > > > >> JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3 >> defconfigs: >> >> $> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779* >> configs/r8a7795_salvator-x_defconfig >> configs/r8a7795_salvator-xs-2x2g_defconfig >> configs/r8a7795_salvator-xs-4x2g_defconfig >> configs/r8a7795_salvator-xs_defconfig >> configs/r8a7795_ulcb-4x2g_defconfig >> configs/r8a7795_ulcb_defconfig >> configs/r8a77965_salvator-x_defconfig >> configs/r8a77965_salvator-xs_defconfig >> configs/r8a77965_ulcb_defconfig >> configs/r8a7796_salvator-x_defconfig >> configs/r8a7796_salvator-xs_defconfig >> configs/r8a7796_ulcb_defconfig >> configs/r8a77970_eagle_defconfig >> configs/r8a77990_ebisu-4d_defconfig >> configs/r8a77990_ebisu_defconfig >> configs/r8a77995_draak_defconfig >> >> So, changing/adding/removing a common option (most of them are) implies >> quite an amount of maintenance effort on our side. I would greatly >> appreciate any ideas how to alleviate that. >> >>> >>> -- >>> Best regards, >>> Marek Vasut >> >> Best regards, >> Eugeniu. >> _______________________________________________ >> U-Boot mailing list >> U-Boot at lists.denx.de >> https://lists.denx.de/listinfo/u-boot > > > > -- > Best Regards > Masahiro Yamada > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-03-07 20:21 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-18 13:05 [U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 2/6] ARM: rmobile: Imply pinctrl " Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 3/6] clk: rmobile: Drop def_bool " Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 4/6] pinctrl: renesas: " Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 5/6] ARM: rmobile: Imply SoC per board Marek Vasut 2019-02-18 13:05 ` [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs Marek Vasut 2019-03-04 21:36 ` Eugeniu Rosca 2019-03-04 22:03 ` Marek Vasut 2019-03-04 23:40 ` Eugeniu Rosca 2019-03-05 3:36 ` Marek Vasut 2019-03-07 13:54 ` Masahiro Yamada 2019-03-07 14:47 ` Ismael Luceno Cortes 2019-03-07 20:21 ` Marek Vasut
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.