Refactor common Kconfigs for easier maintenance
Subsystems (8)
v4 cover Refactor common Kconfigs for easier maintenance
Common Kconfig options which depend on a long list of board- and SoC- specific Kconfigs can be cumbersome to maintain, leading to annoying merge conflicts (although rather trivial ones).
This series factors out the dependencies of CACHE_L2X0 and SMP so that the knowledge about when these can be enabled is moved to the relevant board/SoC Kconfig files instead. New MIGHT_HAVE_CACHE_L2X0 and HAVE_SMP options are defined to mediate the dependencies.
This series has been substantially reworked compared with the previous post, and is now in two parts:
* The first two patches simply refactor the way the Kconfig options for CACHE_L2X0 and SMP are implemented, without making any other changes.
* The final three patches apply functional changes suggested by the contributors to this series, to make the config dependencies more correct for some specific boards.
Thanks to Rob Herring, Shawn Guo and Russell King for their contributions to this series. Thanks also to David Brown for pointing out the lack of a comprehensive CC list.
I have briefly build-tested on some of the affected boards, but any further reviews or Tested-Bys would be much appreciated.
Dave Martin (5):
ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
ARM: SMP: Refactor Kconfig to be more maintainable
omap4: Unconditionally require l2x0 L2 cache controller support
highbank: Unconditionally require l2x0 L2 cache controller support
imx6q: Remove unconditional dependency on l2x0 L2 cache support
arch/arm/Kconfig | 23 +++++++++++++++++++---- arch/arm/mach-exynos/Kconfig | 2 ++ arch/arm/mach-imx/Kconfig | 3 ++- arch/arm/mach-msm/Kconfig | 1 + arch/arm/mach-omap2/Kconfig | 2 ++ arch/arm/mach-realview/Kconfig | 9 +++++++++ arch/arm/mach-vexpress/Kconfig | 2 ++ arch/arm/mm/Kconfig | 15 ++++++++------- arch/arm/plat-mxc/Kconfig | 1 + 9 files changed, 46 insertions(+), 12 deletions(-)
Signature · 1 line
1.7.4.1
PATCH v4 1/5 ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts.
This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other.
Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example.
--- arch/arm/Kconfig | 8 ++++++++ arch/arm/mach-exynos/Kconfig | 1 + arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-realview/Kconfig | 5 +++++ arch/arm/mach-vexpress/Kconfig | 1 + arch/arm/mm/Kconfig | 15 ++++++++------- arch/arm/plat-mxc/Kconfig | 1 + 7 files changed, 25 insertions(+), 7 deletions(-)
arch/arm/Kconfig +8 -0
@@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards.
@@ -361,6 +362,7 @@ config ARCH_CNS3XXX select CPU_V6K select GENERIC_CLOCKEVENTS select ARM_GIC + select MIGHT_HAVE_CACHE_L2X0 select MIGHT_HAVE_PCI select PCI_DOMAINS if PCI help
@@ -381,6 +383,7 @@ config ARCH_PRIMA2 select GENERIC_CLOCKEVENTS select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF select ZONE_DMA help
@@ -633,6 +636,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help This enables support for NVIDIA Tegra based systems (Tegra APX,
@@ -703,6 +707,7 @@ config ARCH_SHMOBILE select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT select SPARSE_IRQ select MULTI_IRQ_HANDLER
@@ -904,6 +909,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture
@@ -914,6 +920,7 @@ config ARCH_NOMADIK select CPU_ARM926T select CLKDEV_LOOKUP select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select ARCH_REQUIRE_GPIOLIB help Support for the Nomadik platform by ST-Ericsson
@@ -973,6 +980,7 @@ config ARCH_ZYNQ select ARM_GIC select ARM_AMBA select ICST + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for Xilinx Zynq ARM Cortex A9 Platform
arch/arm/mach-exynos/Kconfig +1 -0
@@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool "SAMSUNG EXYNOS4" + select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems
arch/arm/mach-omap2/Kconfig +1 -0
@@ -44,6 +44,7 @@ config ARCH_OMAP4 select CPU_V7 select ARM_GIC select LOCAL_TIMERS if SMP + select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789
arch/arm/mach-realview/Kconfig +5 -0
@@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool "Support Multicore Cortex-A9 Tile" depends on MACH_REALVIEW_EB select CPU_V7 + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the Realview(R) Emulation Baseboard platform.
@@ -21,6 +22,7 @@ config REALVIEW_EB_ARM11MP depends on MACH_REALVIEW_EB select CPU_V6K select ARCH_HAS_BARRIERS if SMP + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the ARM11MPCore tile fitted to the Realview(R) Emulation Baseboard platform.
@@ -39,6 +41,7 @@ config MACH_REALVIEW_PB11MP select CPU_V6K select ARM_GIC select HAVE_PATA_PLATFORM + select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_BARRIERS if SMP help Include support for the ARM(R) RealView(R) Platform Baseboard for
@@ -51,6 +54,7 @@ config MACH_REALVIEW_PB1176 select CPU_V6 select ARM_GIC select HAVE_TCM + select MIGHT_HAVE_CACHE_L2X0 help Include support for the ARM(R) RealView(R) Platform Baseboard for ARM1176JZF-S.
@@ -78,6 +82,7 @@ config MACH_REALVIEW_PBX bool "Support RealView(R) Platform Baseboard Explore" select ARM_GIC select HAVE_PATA_PLATFORM + select MIGHT_HAVE_CACHE_L2X0 select ARCH_SPARSEMEM_ENABLE if CPU_V7 && !REALVIEW_HIGH_PHYS_OFFSET select ZONE_DMA if SPARSEMEM help
arch/arm/mach-vexpress/Kconfig +1 -0
@@ -8,5 +8,6 @@ config ARCH_VEXPRESS_CA9X4 select ARM_ERRATA_720789 select ARM_ERRATA_751472 select ARM_ERRATA_753970 + select MIGHT_HAVE_CACHE_L2X0 endmenu
arch/arm/mm/Kconfig +8 -7
@@ -816,14 +816,15 @@ config CACHE_FEROCEON_L2_WRITETHROUGH Say Y here to use the Feroceon L2 cache in writethrough mode. Unless you specifically require this, say N for writeback mode. +config MIGHT_HAVE_CACHE_L2X0 + bool + help + This option should be selected by machines which have a L2x0 + or PL310 cache controller. + config CACHE_L2X0 - bool "Enable the L2x0 outer cache controller" - depends on REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || MACH_REALVIEW_PB1176 || \ - REALVIEW_EB_A9MP || ARCH_IMX_V6_V7 || MACH_REALVIEW_PBX || \ - ARCH_NOMADIK || ARCH_OMAP4 || ARCH_EXYNOS4 || ARCH_TEGRA || \ - ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || ARCH_SHMOBILE || \ - ARCH_PRIMA2 || ARCH_ZYNQ || ARCH_CNS3XXX || ARCH_HIGHBANK - default y + bool "Enable the L2x0 outer cache controller" if MIGHT_HAVE_CACHE_L2X0 + default MIGHT_HAVE_CACHE_L2X0 select OUTER_CACHE select OUTER_CACHE_SYNC help
arch/arm/plat-mxc/Kconfig +1 -0
@@ -20,6 +20,7 @@ config ARCH_IMX_V6_V7 bool "i.MX3, i.MX6" select AUTO_ZRELADDR if !ZBOOT_ROM select ARM_PATCH_PHYS_VIRT + select MIGHT_HAVE_CACHE_L2X0 help This enables support for systems based on the Freescale i.MX3 and i.MX6 family.
Signature · 1 line
1.7.4.1
PATCH v4 1/5 ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
Quoted 9 lines · Dave Martin
Making
CACHE_L2X0depend on (huge list ofMACH_andARCH_configs) is bothersome to maintain and likely to lead to merge conflicts.This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new
MIGHT_HAVE_CACHE_L2X0config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other.
Quoted 6 lines
Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select
CACHE_L2X0directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example.Signed-off-by Dave Martin <[email protected]>
For CNS3xxx bits:
Thanks!
Tony Lindgren
maintainerPATCH v4 1/5 ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
Quoted 15 lines · Anton Vorontsov
Quoted 14 lines · Dave Martin
Making
CACHE_L2X0depend on (huge list ofMACH_andARCH_configs) is bothersome to maintain and likely to lead to merge conflicts.This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new
MIGHT_HAVE_CACHE_L2X0config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other.Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select
CACHE_L2X0directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example.
Quoted 5 lines
Quoted 1 line
Signed-off-by Dave Martin <[email protected]>For CNS3xxx bits:
Acked-by Anton Vorontsov <[email protected]>
For omap:
PATCH v4 2/5 ARM: SMP: Refactor Kconfig to be more maintainable
In reply to Dave MartinMaking SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts.
This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration.
--- arch/arm/Kconfig | 15 +++++++++++---- arch/arm/mach-exynos/Kconfig | 1 + arch/arm/mach-imx/Kconfig | 1 + arch/arm/mach-msm/Kconfig | 1 + arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-realview/Kconfig | 4 ++++ arch/arm/mach-vexpress/Kconfig | 1 + 7 files changed, 20 insertions(+), 4 deletions(-)
arch/arm/Kconfig +11 -4
@@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select USE_OF help
@@ -636,6 +637,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help
@@ -706,6 +708,7 @@ config ARCH_SHMOBILE select HAVE_CLK select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV + select HAVE_SMP select GENERIC_CLOCKEVENTS select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT
@@ -909,6 +912,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture
@@ -1430,14 +1434,17 @@ menu "Kernel Features" source "kernel/time/Kconfig" +config HAVE_SMP + bool + help + This option should be selected by machines which have an SMP- + capable CPU. + config SMP bool "Symmetric Multi-Processing" depends on CPU_V6K || CPU_V7 depends on GENERIC_CLOCKEVENTS - depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \ - MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \ - ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \ - ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || ARCH_HIGHBANK || SOC_IMX6Q + depends on HAVE_SMP depends on MMU select USE_GENERIC_SMP_HELPERS select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
arch/arm/mach-exynos/Kconfig +1 -0
@@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool "SAMSUNG EXYNOS4" + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems
arch/arm/mach-imx/Kconfig +1 -0
@@ -615,6 +615,7 @@ config SOC_IMX6Q select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC + select HAVE_SMP select USE_OF help
arch/arm/mach-msm/Kconfig +1 -0
@@ -67,6 +67,7 @@ config MSM_SOC_REV_A bool config ARCH_MSM_SCORPIONMP bool + select HAVE_SMP config ARCH_MSM_ARM11 bool
arch/arm/mach-omap2/Kconfig +1 -0
@@ -43,6 +43,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select HAVE_SMP select LOCAL_TIMERS if SMP select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369
arch/arm/mach-realview/Kconfig +4 -0
@@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool "Support Multicore Cortex-A9 Tile" depends on MACH_REALVIEW_EB select CPU_V7 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the
@@ -22,6 +23,7 @@ config REALVIEW_EB_ARM11MP depends on MACH_REALVIEW_EB select CPU_V6K select ARCH_HAS_BARRIERS if SMP + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Enable support for the ARM11MPCore tile fitted to the Realview(R)
@@ -41,6 +43,7 @@ config MACH_REALVIEW_PB11MP select CPU_V6K select ARM_GIC select HAVE_PATA_PLATFORM + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_BARRIERS if SMP help
@@ -82,6 +85,7 @@ config MACH_REALVIEW_PBX bool "Support RealView(R) Platform Baseboard Explore" select ARM_GIC select HAVE_PATA_PLATFORM + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select ARCH_SPARSEMEM_ENABLE if CPU_V7 && !REALVIEW_HIGH_PHYS_OFFSET select ZONE_DMA if SPARSEMEM
arch/arm/mach-vexpress/Kconfig +1 -0
@@ -8,6 +8,7 @@ config ARCH_VEXPRESS_CA9X4 select ARM_ERRATA_720789 select ARM_ERRATA_751472 select ARM_ERRATA_753970 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 endmenu
Signature · 1 line
1.7.4.1
Tony Lindgren
maintainerPATCH v4 2/5 ARM: SMP: Refactor Kconfig to be more maintainable
Quoted 7 lines · Dave Martin
Making SMP depend on (huge list of
MACH_andARCH_configs) is bothersome to maintain and likely to lead to merge conflicts.This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new
HAVE_SMPconfig option is introduced to allow machines to indicate that they can run in a SMP configuration.
For omap:
PATCH v4 2/5 ARM: SMP: Refactor Kconfig to be more maintainable
In reply to Dave MartinQuoted 7 lines · Dave Martin
Making SMP depend on (huge list of
MACH_andARCH_configs) is bothersome to maintain and likely to lead to merge conflicts.This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new
HAVE_SMPconfig option is introduced to allow machines to indicate that they can run in a SMP configuration.
There still seem to be several people and lists from the get_maintainer.pl output that are missing. Russell should be included, as well as the MSM maintainers and that list.
David
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
PATCH v4 2/5 ARM: SMP: Refactor Kconfig to be more maintainable
In reply to Dave MartinQuoted 9 lines · Dave Martin
Making SMP depend on (huge list of
MACH_andARCH_configs) is bothersome to maintain and likely to lead to merge conflicts.This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new
HAVE_SMPconfig option is introduced to allow machines to indicate that they can run in a SMP configuration.arch/arm/mach-msm/Kconfig | 1 +
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
PATCH v4 3/5 omap4: Unconditionally require l2x0 L2 cache controller support
In reply to Dave MartinIf running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
Thanks to Rob Herring for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
--- arch/arm/mach-omap2/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/Kconfig +1 -1
@@ -41,11 +41,11 @@ config ARCH_OMAP4 bool "TI OMAP4" default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789
Signature · 1 line
1.7.4.1
Tony Lindgren
maintainerPATCH v4 3/5 omap4: Unconditionally require l2x0 L2 cache controller support
Quoted 4 lines · Dave Martin
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented.
BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux.
The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :(
Sounds like devicetree is the only safe way to deal with the L2 control options.
Regards,
Tony
Quoted 31 lines
This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
Thanks to Rob Herring for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
--- arch/arm/mach-omap2/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-omap2/Kconfig +1
-1@@ -41,11 +41,11 @@ config ARCH_OMAP4 bool "TI OMAP4" default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789Signature · 1 line
1.7.4.1
PATCH v4 3/5 omap4: Unconditionally require l2x0 L2 cache controller support
Quoted 49 lines · Tony Lindgren
Quoted 4 lines · Dave Martin
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented.
BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux.
The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :(
Sounds like devicetree is the only safe way to deal with the L2 control options.
Regards,
Tony
Quoted 23 lines
This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
Thanks to Rob Herring for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
--- arch/arm/mach-omap2/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-omap2/Kconfig +1
-0@@ -41,11 +41,11 @@ config ARCH_OMAP4 bool "TI OMAP4" default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP
Quoted 8 lines
Quoted 8 lines
arch/arm/mach-omap2/Kconfig +0
-1select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789Signature · 1 line
1.7.4.1
To clarify, are you suggesting we retain this patch, or not?
(If we only know what l2x0 support will be needed once the dts is parsed at runtime, there could be an argument for keeping the select CACHE_L2X0 here -- unless we have specific kconfigs for the different security variants of omap.)
Cheers
---Dave
Tony Lindgren
maintainerPATCH v4 3/5 omap4: Unconditionally require l2x0 L2 cache controller support
Quoted 52 lines · Dave Martin
Quoted 51 lines · Tony Lindgren
Quoted 4 lines · Dave Martin
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented.
BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux.
The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :(
Sounds like devicetree is the only safe way to deal with the L2 control options.
Regards,
Tony
Quoted 25 lines
This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
Thanks to Rob Herring for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
--- arch/arm/mach-omap2/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-omap2/Kconfig +1
-1@@ -41,11 +41,11 @@ config ARCH_OMAP4 bool "TI OMAP4" default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
arch/arm/mach-omap2/Kconfig +0
-0select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789Signature · 1 line
1.7.4.1To clarify, are you suggesting we retain this patch, or not?
I think we should keep L2 configurable for omaps until we have some way of getting the configuration dynamically or from device tree.
Quoted 4 lines
(If we only know what l2x0 support will be needed once the dts is parsed at runtime, there could be an argument for keeping the select
CACHE_L2X0here -- unless we have specific kconfigs for the different security variants of omap.)
Well we can detect if it's an HS omap, but we may not know what SMI it uses for enabling and disabling L2.. That can depend on the board version.
Is there some problem keeping MIGHT_HAVE_CACHE_L2X0? This is pretty important from debugging cache issues point of view.
Regards,
Tony
PATCH v4 3/5 omap4: Unconditionally require l2x0 L2 cache controller support
Quoted 62 lines · Tony Lindgren
Quoted 52 lines · Dave Martin
Quoted 51 lines · Tony Lindgren
Quoted 4 lines · Dave Martin
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented.
BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux.
The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :(
Sounds like devicetree is the only safe way to deal with the L2 control options.
Regards,
Tony
Quoted 25 lines
This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
Thanks to Rob Herring for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
--- arch/arm/mach-omap2/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-omap2/Kconfig +1
-1@@ -41,11 +41,11 @@ config ARCH_OMAP4 bool "TI OMAP4" default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
arch/arm/mach-omap2/Kconfig +0
-0select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789Signature · 1 line
1.7.4.1To clarify, are you suggesting we retain this patch, or not?
Quoted 3 lines
I think we should keep L2 configurable for omaps until we have some way of getting the configuration dynamically or from device tree.
This already exists with l2x0_of_init. OMAP just needs to start using it. It will initialize the l2 if present in the DT and skip it if not present.
Rob
Quoted 15 lines
Quoted 4 lines
(If we only know what l2x0 support will be needed once the dts is parsed at runtime, there could be an argument for keeping the select
CACHE_L2X0here -- unless we have specific kconfigs for the different security variants of omap.)Well we can detect if it's an HS omap, but we may not know what SMI it uses for enabling and disabling L2.. That can depend on the board version.
Is there some problem keeping
MIGHT_HAVE_CACHE_L2X0? This is pretty important from debugging cache issues point of view.Regards,
Tony
Tony Lindgren
maintainerPATCH v4 3/5 omap4: Unconditionally require l2x0 L2 cache controller support
Quoted 10 lines · Rob Herring
Quoted 4 lines · Tony Lindgren
I think we should keep L2 configurable for omaps until we have some way of getting the configuration dynamically or from device tree.
This already exists with
l2x0_of_init. OMAP just needs to start using it. It will initialize the l2 if present in the DT and skip it if not present.
That's great, that will allow doing the right thing with setting up how to enable and disable it :) Considering that, this patch should be OK to apply:
PATCH v4 4/5 highbank: Unconditionally require l2x0 L2 cache controller support
In reply to Dave MartinIf running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
This patch unconditionally enables l2x0 support for the Highbank SoC.
Thanks to Rob Herring for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
--- arch/arm/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/Kconfig +1 -1
@@ -340,12 +340,12 @@ config ARCH_HIGHBANK select ARM_AMBA select ARM_GIC select ARM_TIMER_SP804 + select CACHE_L2X0 select CLKDEV_LOOKUP select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU select HAVE_SMP - select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards.
Signature · 1 line
1.7.4.1
PATCH v4 4/5 highbank: Unconditionally require l2x0 L2 cache controller support
Quoted 5 lines · Dave Martin
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
Quoted 8 lines
This patch unconditionally enables l2x0 support for the Highbank SoC.
Thanks to Rob Herring for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
Doesn't this need to be above the SOB? Otherwise:
Quoted 22 lines
--- arch/arm/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/Kconfig +1
-1@@ -340,12 +340,12 @@ config ARCH_HIGHBANK select ARM_AMBA select ARM_GIC select ARM_TIMER_SP804 + select CACHE_L2X0 select CLKDEV_LOOKUP select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU select HAVE_SMP - select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards.
PATCH v4 4/5 highbank: Unconditionally require l2x0 L2 cache controller support
Quoted 10 lines · Rob Herring
Quoted 8 lines · Dave Martin
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in.
This patch unconditionally enables l2x0 support for the Highbank SoC.
Quoted 7 lines
Quoted 5 lines
Thanks to Rob Herring for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
Doesn't this need to be above the SOB? Otherwise:
You may be right ... certainly I see no reason _not_ to change it. So I'll change it.
Quoted 2 lines
Acked-by Rob Herring <[email protected]>
Thanks
---Dave
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
In reply to Dave MartinThe i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead.
This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mach-imx/Kconfig +1 -1
@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Q bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help
Signature · 1 line
1.7.4.1
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
Hi Dave,
Sorry for that I did not look into previous post to point it out.
Quoted 22 lines · Dave Martin
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on
CACHE_L2X0and selectsMIGHT_HAVE_CACHE_L2X0instead.This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-imx/Kconfig +0
-0@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Q
arch/arm/mach-imx/Kconfig comment "i.MX6 family:" · line 618
Quoted 10 lines
arch/arm/mach-imx/Kconfig +1
-1bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0
The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here.
Regards,
Shawn
Quoted 12 lines
arch/arm/mach-imx/Kconfig +0
-0select USE_OF helpSignature · 7 lines
1.7.4.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
Quoted 33 lines · Shawn Guo
Hi Dave,
Sorry for that I did not look into previous post to point it out.
Quoted 28 lines · Dave Martin
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on
CACHE_L2X0and selectsMIGHT_HAVE_CACHE_L2X0instead.This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-imx/Kconfig +0
-1@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Q bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC
Quoted 8 lines
arch/arm/mach-imx/Kconfig comment "i.MX6 family:" · line 618
Quoted 4 lines
arch/arm/mach-imx/Kconfig +1
-0select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0The option
SOC_IMX6Qis only available whenARCH_IMX_V6_V7is selected. SinceMIGHT_HAVE_CACHE_L2X0has been selected byARCH_IMX_V6_V7in patch #1, this line seems redundant here.
Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0.
Thanks
Richard
Quoted 22 lines
Regards,
ShawnQuoted 12 lines
arch/arm/mach-imx/Kconfig +0
-0select USE_OF helpSignature · 7 lines
1.7.4.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
Quoted 42 lines · Richard Zhao
Quoted 33 lines · Shawn Guo
Hi Dave,
Sorry for that I did not look into previous post to point it out.
Quoted 28 lines · Dave Martin
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on
CACHE_L2X0and selectsMIGHT_HAVE_CACHE_L2X0instead.This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-imx/Kconfig +0
-1@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Q bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPCQuoted 8 lines
arch/arm/mach-imx/Kconfig comment "i.MX6 family:" · line 618
Quoted 4 lines
arch/arm/mach-imx/Kconfig +1
-0select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0The option
SOC_IMX6Qis only available whenARCH_IMX_V6_V7is selected. SinceMIGHT_HAVE_CACHE_L2X0has been selected byARCH_IMX_V6_V7in patch #1, this line seems redundant here.
Quoted 2 lines
Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0.
Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select it only from SOC_IMX6Q?
Cheers
---Dave
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
Quoted 43 lines · Dave Martin
Quoted 42 lines · Richard Zhao
Quoted 41 lines · Shawn Guo
Hi Dave,
Sorry for that I did not look into previous post to point it out.
Quoted 22 lines · Dave Martin
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on
CACHE_L2X0and selectsMIGHT_HAVE_CACHE_L2X0instead.This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-imx/Kconfig +0
-0@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Qarch/arm/mach-imx/Kconfig comment "i.MX6 family:" · line 618
Quoted 10 lines
arch/arm/mach-imx/Kconfig +1
-1bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0The option
SOC_IMX6Qis only available whenARCH_IMX_V6_V7is selected. SinceMIGHT_HAVE_CACHE_L2X0has been selected byARCH_IMX_V6_V7in patch #1, this line seems redundant here.
Quoted 5 lines
Quoted 2 lines
Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0.
Do you mean to remove
MIGHT_HAVE_CACHE_L2X0fromARCH_IMX_V6_V7, and select it only fromSOC_IMX6Q?
Yes, I think it's more precise. Shawn?
Thansk
Richard
Quoted 9 lines
Cheers
---Dave_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
Quoted 44 lines · Richard Zhao
Quoted 43 lines · Dave Martin
Quoted 42 lines · Richard Zhao
Quoted 41 lines · Shawn Guo
Hi Dave,
Sorry for that I did not look into previous post to point it out.
Quoted 22 lines · Dave Martin
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on
CACHE_L2X0and selectsMIGHT_HAVE_CACHE_L2X0instead.This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-imx/Kconfig +0
-0@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Qarch/arm/mach-imx/Kconfig comment "i.MX6 family:" · line 618
Quoted 10 lines
arch/arm/mach-imx/Kconfig +1
-1bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0The option
SOC_IMX6Qis only available whenARCH_IMX_V6_V7is selected. SinceMIGHT_HAVE_CACHE_L2X0has been selected byARCH_IMX_V6_V7in patch #1, this line seems redundant here.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0.
Do you mean to remove
MIGHT_HAVE_CACHE_L2X0fromARCH_IMX_V6_V7, and select it only fromSOC_IMX6Q?Yes, I think it's more precise. Shawn?
No.
* imx5 hardware does have L2, and it's just not set up in the kernel (I do not know why).
* Currently, ARCH_IMX_V6_V7 only covers imx3 and imx6, and both are calling l2x0 init function to set L2 up.
* When we merge mach-mx5 into mach-imx to have ARCH_IMX_V6_V7 cover imx3, imx5 and imx6, there is no reason for us to not set L2 up for imx5 too.
So MIGHT_HAVE_CACHE_L2X0 really should be selected by ARCH_IMX_V6_V7.
Signature · 2 lines
Regards, Shawn
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
Quoted 62 lines · Shawn Guo
Quoted 44 lines · Richard Zhao
Quoted 43 lines · Dave Martin
Quoted 42 lines · Richard Zhao
Quoted 41 lines · Shawn Guo
Hi Dave,
Sorry for that I did not look into previous post to point it out.
Quoted 22 lines · Dave Martin
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on
CACHE_L2X0and selectsMIGHT_HAVE_CACHE_L2X0instead.This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-imx/Kconfig +0
-0@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Qarch/arm/mach-imx/Kconfig comment "i.MX6 family:" · line 618
Quoted 10 lines
arch/arm/mach-imx/Kconfig +1
-1bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0The option
SOC_IMX6Qis only available whenARCH_IMX_V6_V7is selected. SinceMIGHT_HAVE_CACHE_L2X0has been selected byARCH_IMX_V6_V7in patch #1, this line seems redundant here.Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0.
Do you mean to remove
MIGHT_HAVE_CACHE_L2X0fromARCH_IMX_V6_V7, and select it only fromSOC_IMX6Q?Yes, I think it's more precise. Shawn?
No.
* imx5 hardware does have L2, and it's just not set up in the kernel (I do not know why).
* Currently,ARCH_IMX_V6_V7only covers imx3 and imx6, and both are calling l2x0 init function to set L2 up.
* When we merge mach-mx5 into mach-imx to haveARCH_IMX_V6_V7cover imx3, imx5 and imx6, there is no reason for us to not set L2 up for imx5 too.
Quoted 1 line
So
MIGHT_HAVE_CACHE_L2X0really should be selected byARCH_IMX_V6_V7.
mx5/cortex-a8 don't use L2X0. But that's ok. MIGHT_HAVE_CACHE_L2X0 is just a hint. Please Shawn's suggestion.
Thanks
Richard
Quoted 4 lines
Signature · 3 lines
-- Regards, Shawn
PATCH v4 5/5 imx6q: Remove unconditional dependency on l2x0 L2 cache support
Quoted 63 lines · Richard Zhao
Quoted 62 lines · Shawn Guo
Quoted 44 lines · Richard Zhao
Quoted 43 lines · Dave Martin
Quoted 42 lines · Richard Zhao
Quoted 41 lines · Shawn Guo
Hi Dave,
Sorry for that I did not look into previous post to point it out.
Quoted 22 lines · Dave Martin
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on
CACHE_L2X0and selectsMIGHT_HAVE_CACHE_L2X0instead.This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc.
Thanks to Shawn Guo for this suggestion. [1]
Signed-off-by Dave Martin <[email protected]>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
--- arch/arm/mach-imx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-imx/Kconfig +0
-0@@ -609,13 +609,13 @@ comment "i.MX6 family:" config SOC_IMX6Qarch/arm/mach-imx/Kconfig comment "i.MX6 family:" · line 618
Quoted 10 lines
arch/arm/mach-imx/Kconfig +1
-1bool "i.MX6 Quad support" select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0The option
SOC_IMX6Qis only available whenARCH_IMX_V6_V7is selected. SinceMIGHT_HAVE_CACHE_L2X0has been selected byARCH_IMX_V6_V7in patch #1, this line seems redundant here.Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0.
Do you mean to remove
MIGHT_HAVE_CACHE_L2X0fromARCH_IMX_V6_V7, and select it only fromSOC_IMX6Q?Yes, I think it's more precise. Shawn?
No.
* imx5 hardware does have L2, and it's just not set up in the kernel (I do not know why).
* Currently,ARCH_IMX_V6_V7only covers imx3 and imx6, and both are calling l2x0 init function to set L2 up.
* When we merge mach-mx5 into mach-imx to haveARCH_IMX_V6_V7cover imx3, imx5 and imx6, there is no reason for us to not set L2 up for imx5 too.
Quoted 3 lines
Quoted 1 line
So
MIGHT_HAVE_CACHE_L2X0really should be selected byARCH_IMX_V6_V7.mx5/cortex-a8 don't use L2X0. But that's ok.
MIGHT_HAVE_CACHE_L2X0is just a hint. Please Shawn's suggestion.
OK, my local series has what I believe to be the correct change; I will repost based on that.
Cheers
---Dave