ARM: multi-cluster aware boot protocol
Subsystems (2)
v2 cover ARM: multi-cluster aware boot protocol
This series is v2, referred to this previous posting:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/125878.html
Changes in v2:
- Reworded and added compatible property to cpus.txt
- Replaced while loop in arm_dt_init_cpu_maps() with a combination of of_find_node_by_path and for_each_child_of_node
- Replaced of_get_property with of_property_read_u32
- Added further checks for DT /cpu nodes and implemented stashed array to avoid overwriting the cpu_logical_map if DT contains errors
- Added GIC CPU IF define in the GIC probing code
- Removed printk for boot CPU MPIDR and added a patch that prints the full extent of MPIDR in smp_setup_processor_id()
- Updated smp_setup_processor_id() so that it uses nr_cpu_ids
- Dropped RFC tag
The introduction of multi-cluster ARM systems in SoC designs requires the kernel to become cluster aware, so that it can be booted on every CPU in the system and it can build an appropriate HW-to-logical cpu map.
Current code in the kernel, in particular the boot sequence, hinges upon a sequential mapping of MPIDR values for cpus and related interrupt controller CPU interfaces to logical cpu indexing.
This hypothesis is not valid when the concept of cluster is introduced since the MPIDR cannot be represented as a single index and interrupt controller CPU interfaces can be wired with a numbering scheme following per-SoC design parameters which can be only detected through probing or device tree representation.
Through the device tree and "cpu" nodes bindings, the kernel is provided with HW values for MPIDR registers that allow the kernel to identify the HW CPU ids that are present in the platform.
The GIC code has been extended to allow automatic detection of GIC CPU IF ids at boot. IPIs are broadcast to all possible CPUs, and every time a secondary CPU is booted, it initializes its own mask and clears itself from the mask of all other logical CPUs.
The device tree bindings and GIC probing allow to boot the Linux kernel on any CPU of a multi-cluster system without relying on a platform specific hook to identify the number of CPUs and hypothesis on the sequential pattern of MPIDRs and relative GIC CPU IF ids.
Pen release code for all converted platforms will need patching to extend the current MPIDR range check; this will take place as soon as the bindings and code for the multi-cluster boot protocol will be reviewed and accepted.
The patchset has been tested on:
- TC2 testchip
to boot a 5-core dual-cluster system on every possible CPU.
Lorenzo Pieralisi (4):
ARM: kernel: smp_setup_processor_id() updates
ARM: kernel: add device tree init map function
ARM: kernel: add cpu logical map DT init in setup_arch
ARM: kernel: add logical mappings look-up
Nicolas Pitre (1):
ARM: gic: use a private mapping for CPU target interfaces
Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++ arch/arm/common/gic.c | 45 +++++++++++--- arch/arm/include/asm/prom.h | 2 + arch/arm/include/asm/smp_plat.h | 17 ++++++ arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++ arch/arm/kernel/setup.c | 8 ++- 6 files changed, 220 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
Signature · 1 line
1.7.12
PATCH v2 1/5 ARM: kernel: smp_setup_processor_id() updates
This patch applies some basic changes to the smp_setup_processor_id() ARM implementation to make the code that builds cpu_logical_map more uniform across the kernel.
The function now prints the full extent of the boot CPU MPIDR[23:0] and initializes the cpu_logical_map for CPUs up to nr_cpu_ids.
--- arch/arm/kernel/setup.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
arch/arm/kernel/setup.c +4 -3
@@ -426,13 +426,14 @@ int __cpu_logical_map[NR_CPUS];void __init smp_setup_processor_id (void ) {int i; -u32 cpu =is_smp () ?read_cpuid_mpidr () &0xff :0 ; +u32 mpidr =read_cpuid_mpidr () &0xffffff ; +u32 cpu =is_smp () ? mpidr &0xff :0 ;cpu_logical_map (0 ) = cpu; -for (i =1 ; i <NR_CPUS ; ++i) +for (i =1 ; i < nr_cpu_ids; ++i)cpu_logical_map (i) = i == cpu ?0 : i; -printk (KERN_INFO "Booting Linux on physical CPU %d\n" , cpu); +printk (KERN_INFO "Booting Linux on physical CPU 0x%x\n" , mpidr); }static void __init setup_processor (void )
Signature · 1 line
1.7.12
PATCH v2 1/5 ARM: kernel: smp_setup_processor_id() updates
Quoted 17 lines · Lorenzo Pieralisi
This patch applies some basic changes to the
smp_setup_processor_id()ARM implementation to make the code that buildscpu_logical_mapmore uniform across the kernel.The function now prints the full extent of the boot CPU MPIDR[23:0] and initializes the
cpu_logical_mapfor CPUs up tonr_cpu_ids.Signed-off-by Lorenzo Pieralisi <[email protected]>--- arch/arm/kernel/setup.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)arch/arm/kernel/setup.c +0
-0
arch/arm/kernel/setup.c int __cpu_logical_map[NR_CPUS]; · line 429
Quoted 5 lines
arch/arm/kernel/setup.c +1
-1@@ -426,13 +426,14 @@ int __cpu_logical_map[NR_CPUS];void __init smp_setup_processor_id (void ) {int i; -u32 cpu =is_smp () ?read_cpuid_mpidr () &0xff :0 ; +u32 mpidr =read_cpuid_mpidr () &0xffffff ;
We need that is_smp() check, otherwise we'll go and do a funky CP15 operation on CPU's that might not be too happy about it.
Will
PATCH v2 1/5 ARM: kernel: smp_setup_processor_id() updates
Quoted 13 lines · Will Deacon
Quoted 12 lines · Lorenzo Pieralisi
This patch applies some basic changes to the
smp_setup_processor_id()ARM implementation to make the code that buildscpu_logical_mapmore uniform across the kernel.The function now prints the full extent of the boot CPU MPIDR[23:0] and initializes the
cpu_logical_mapfor CPUs up tonr_cpu_ids.Signed-off-by Lorenzo Pieralisi <[email protected]>--- arch/arm/kernel/setup.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Quoted 13 lines
arch/arm/kernel/setup.c int __cpu_logical_map[NR_CPUS]; · line 429
Quoted 10 lines
arch/arm/kernel/setup.c +1
-1@@ -426,13 +426,14 @@ int __cpu_logical_map[NR_CPUS];void __init smp_setup_processor_id (void ) {int i; -u32 cpu =is_smp () ?read_cpuid_mpidr () &0xff :0 ; +u32 mpidr =read_cpuid_mpidr () &0xffffff ;We need that
is_smp()check, otherwise we'll go and do a funky CP15 operation on CPU's that might not be too happy about it.
It is there :-) I just added a local variable for mpidr to avoid reading it again later on when printing. The change moved the is_smp() check one line down.
Thanks,
Lorenzo
PATCH v2 1/5 ARM: kernel: smp_setup_processor_id() updates
In reply to Will DeaconQuoted 13 lines · Will Deacon
Quoted 12 lines · Lorenzo Pieralisi
This patch applies some basic changes to the
smp_setup_processor_id()ARM implementation to make the code that buildscpu_logical_mapmore uniform across the kernel.The function now prints the full extent of the boot CPU MPIDR[23:0] and initializes the
cpu_logical_mapfor CPUs up tonr_cpu_ids.Signed-off-by Lorenzo Pieralisi <[email protected]>--- arch/arm/kernel/setup.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Quoted 13 lines
arch/arm/kernel/setup.c int __cpu_logical_map[NR_CPUS]; · line 429
Quoted 10 lines
arch/arm/kernel/setup.c +1
-1@@ -426,13 +426,14 @@ int __cpu_logical_map[NR_CPUS];void __init smp_setup_processor_id (void ) {int i; -u32 cpu =is_smp () ?read_cpuid_mpidr () &0xff :0 ; +u32 mpidr =read_cpuid_mpidr () &0xffffff ;We need that
is_smp()check, otherwise we'll go and do a funky CP15 operation on CPU's that might not be too happy about it.
You are right, sorry my apologies.
I will have to check it even when parsing the DT then.
Lorenzo
PATCH v2 2/5 ARM: kernel: add device tree init map function
In reply to Lorenzo PieralisiWhen booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txt
--- Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++ arch/arm/include/asm/prom.h | 2 + arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++ 3 files changed, 162 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
Documentation/devicetree/bindings/arm/cpus.txt new file +84 -0
@@ -0,0 +1,84 @@ +* ARM CPUs binding description + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the ePAPR standard, available from: + +http://devicetree.org + +For the ARM architecture every CPU node must contain the following properties: + +- reg : property matching the CPU MPIDR[23:0] register bits +- compatible: must be set to "arm, <cpu-model>" + where <cpu-model> is the full processor name as used in the + processor Technical Reference Manual, eg: + - for a Cortex A9 processor + compatible = <arm, cortex-a9>; + - for a Cortex A15 processor + compatible = <arm, cortex-a15>; + +List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110> +<arm, sa1100> +<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7> +<arm, cortex-a8> +<arm, cortex-a9> +<arm, cortex-a15> +<arm, arm1136> +<arm, arm11-mpcore> + +Every cpu node is required to set its device_type to "cpu". + +Example: + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu at 0 { + device_type = "cpu"; + compatible = <arm, cortex-a15>; + reg = <0x0>; + }; + + CPU1: cpu at 1 { + device_type = "cpu"; + compatible = <arm, cortex-a15>; + reg = <0x1>; + }; + + CPU2: cpu at 100 { + device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x100>; + }; + + CPU3: cpu at 101 { + device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x101>; + }; + };
arch/arm/include/asm/prom.h +2 -0
@@ -15,6 +15,7 @@extern struct machine_desc *setup_machine_fdt (unsigned int dt_phys);extern void arm_dt_memblock_reserve (void ); +extern void __init arm_dt_init_cpu_maps (void );#else /* CONFIG_OF */
@@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys) }static inline void arm_dt_memblock_reserve (void ) { } +static inline void arm_dt_init_cpu_maps (void ) { }#endif /* CONFIG_OF */ #endif /* ASMARM_PROM_H */
arch/arm/kernel/devtree.c +76 -0
90 lines not on this page · raw message
Signature · 1 line
1.7.12
PATCH v2 2/5 ARM: kernel: add device tree init map function
Quoted 20 lines · Lorenzo Pieralisi
When booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txtSigned-off-by Lorenzo Pieralisi <[email protected]>
[...]
Quoted 20 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +20
-0+List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110>
Documentation/devicetree/bindings/arm/cpus.txt line 51
Quoted 10 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +10
-0+<arm, sa1100> +<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7> +<arm, cortex-a8> +<arm, cortex-a9> +<arm, cortex-a15> +<arm, arm1136> +<arm, arm11-mpcore>
Is this supposed to be an exhaustive list? What about 1156 and 1176? Also, "arm11mpcore" should probably be used instead of "arm11-mpcore".
Will
PATCH v2 2/5 ARM: kernel: add device tree init map function
Quoted 49 lines · Will Deacon
Quoted 20 lines · Lorenzo Pieralisi
When booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txtSigned-off-by Lorenzo Pieralisi <[email protected]>[...]
Quoted 25 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +25
-0+List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110> +<arm, sa1100> +<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7>
Quoted 8 lines
Quoted 5 lines
+<arm, cortex-a8>
+<arm, cortex-a9>
+<arm, cortex-a15>
+<arm, arm1136>
+<arm, arm11-mpcore>Is this supposed to be an exhaustive list? What about 1156 and 1176? Also, "arm11mpcore" should probably be used instead of "arm11-mpcore".
I added the list since IMHO defining a compatible property and not defining a list of possible strings can encourage abuse. Happy to do whatever DT guys think I should do with it.
I will add the processor version strings you suggested.
Thanks,
Lorenzo
PATCH v2 2/5 ARM: kernel: add device tree init map function
In reply to Lorenzo PieralisiQuoted 75 lines · Lorenzo Pieralisi
When booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txtSigned-off-by Lorenzo Pieralisi <[email protected]>--- Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++ arch/arm/include/asm/prom.h | 2 + arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++ 3 files changed, 162 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cpus.txtDocumentation/devicetree/bindings/arm/cpus.txt new file +42
-0@@ -0,0 +1,84 @@ +* ARM CPUs binding description + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the ePAPR standard, available from: + +http://devicetree.org + +For the ARM architecture every CPU node must contain the following properties: + +- reg : property matching the CPU MPIDR[23:0] register bits +- compatible: must be set to "arm, <cpu-model>" + where <cpu-model> is the full processor name as used in the + processor Technical Reference Manual, eg: + - for a Cortex A9 processor + compatible = <arm, cortex-a9>; + - for a Cortex A15 processor + compatible = <arm, cortex-a15>; + +List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110> +<arm, sa1100>
Documentation/devicetree/bindings/arm/cpus.txt line 52
Quoted 10 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +10
-0+<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7> +<arm, cortex-a8> +<arm, cortex-a9> +<arm, cortex-a15> +<arm, arm1136> +<arm, arm11-mpcore> +
Is there any reason for the spaces in the compatible string? No other binding seems to do this.
Is <STRING> a valid dts format? Should these not be "STRING" instead?
For consistency, it would be nice to have the compatible strings tab-indented as in Documentation/devicetree/bindings/arm/pmu.txt.
Thanks,
Mark
PATCH v2 2/5 ARM: kernel: add device tree init map function
Hi Mark,
Quoted 90 lines · Mark Rutland
Quoted 75 lines · Lorenzo Pieralisi
When booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txtSigned-off-by Lorenzo Pieralisi <[email protected]>--- Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++ arch/arm/include/asm/prom.h | 2 + arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++ 3 files changed, 162 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cpus.txtDocumentation/devicetree/bindings/arm/cpus.txt new file +42
-0@@ -0,0 +1,84 @@ +* ARM CPUs binding description + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the ePAPR standard, available from: + +http://devicetree.org + +For the ARM architecture every CPU node must contain the following properties: + +- reg : property matching the CPU MPIDR[23:0] register bits +- compatible: must be set to "arm, <cpu-model>" + where <cpu-model> is the full processor name as used in the + processor Technical Reference Manual, eg: + - for a Cortex A9 processor + compatible = <arm, cortex-a9>; + - for a Cortex A15 processor + compatible = <arm, cortex-a15>; + +List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110> +<arm, sa1100>Documentation/devicetree/bindings/arm/cpus.txt line 52
Quoted 10 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +10
-0+<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7> +<arm, cortex-a8> +<arm, cortex-a9> +<arm, cortex-a15> +<arm, arm1136> +<arm, arm11-mpcore> +Is there any reason for the spaces in the compatible string? No other binding seems to do this.
Quoted 4 lines
Is <STRING> a valid dts format? Should these not be "STRING" instead?
For consistency, it would be nice to have the compatible strings tab-indented as in
Documentation/devicetree/bindings/arm/pmu.txt.
You are absolutely right on all points, I will update the description.
Thanks,
Lorenzo
PATCH v2 2/5 ARM: kernel: add device tree init map function
In reply to Lorenzo PieralisiQuoted 74 lines · Lorenzo Pieralisi
When booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txtSigned-off-by Lorenzo Pieralisi <[email protected]>--- Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++ arch/arm/include/asm/prom.h | 2 + arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++ 3 files changed, 162 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cpus.txtDocumentation/devicetree/bindings/arm/cpus.txt new file +41
-0@@ -0,0 +1,84 @@ +* ARM CPUs binding description + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the ePAPR standard, available from: + +http://devicetree.org + +For the ARM architecture every CPU node must contain the following properties: + +- reg : property matching the CPU MPIDR[23:0] register bits +- compatible: must be set to "arm, <cpu-model>" + where <cpu-model> is the full processor name as used in the + processor Technical Reference Manual, eg: + - for a Cortex A9 processor + compatible = <arm, cortex-a9>; + - for a Cortex A15 processor + compatible = <arm, cortex-a15>; + +List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110>
Documentation/devicetree/bindings/arm/cpus.txt line 51
Quoted 10 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +10
-0+<arm, sa1100> +<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7> +<arm, cortex-a8> +<arm, cortex-a9> +<arm, cortex-a15> +<arm, arm1136> +<arm, arm11-mpcore>
Any views on how we make sure that this list gets maintained?
This binding feels like it probably is the right place to keep the exhaustive, "official" list of ARM CPU compatible strings, but I would not be surprised if it gets stale.
Also, do we worry about the "arm," namespace for compatible strings becoming overcrowded?
Currently we're shovelling a whole load of things in there, some of which are not ARM products.
Thiry-party implementations like mohawk, sa11*, xsc*, fa526 and feroceon are not ARM products, and should be in a different, appropriate vendor namespace.
Cheers
---Dave
Quoted 153 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +33
-0+ +Every cpu node is required to set its device_type to "cpu". + +Example: + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu at 0 { + device_type = "cpu"; + compatible = <arm, cortex-a15>; + reg = <0x0>; + }; + + CPU1: cpu at 1 { + device_type = "cpu"; + compatible = <arm, cortex-a15>; + reg = <0x1>; + }; + + CPU2: cpu at 100 { + device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x100>; + }; + + CPU3: cpu at 101 { + device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x101>; + }; + };arch/arm/include/asm/prom.h +2
-0@@ -15,6 +15,7 @@extern struct machine_desc *setup_machine_fdt (unsigned int dt_phys);extern void arm_dt_memblock_reserve (void ); +extern void __init arm_dt_init_cpu_maps (void );#else /* CONFIG_OF */ @@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys) }static inline void arm_dt_memblock_reserve (void ) { } +static inline void arm_dt_init_cpu_maps (void ) { }#endif /* CONFIG_OF */ #endif /* ASMARM_PROM_H */ arch/arm/kernel/devtree.c +76
-0@@ -19,8 +19,10 @@#include <linux/of_irq.h> #include <linux/of_platform.h> +#include <asm/cputype.h> #include <asm/setup.h> #include <asm/page.h> +#include <asm/smp_plat.h> #include <asm/mach/arch.h> #include <asm/mach-types.h> @@ -61,6 +63,80 @@ void __init arm_dt_memblock_reserve(void) } } +/* +* arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree +* and builds the cpu logical map array containing MPIDR values related to +* logical cpus +* +* Updates the cpu possible mask with the number of parsed cpu nodes +*/ +void __init arm_dt_init_cpu_maps (void ) +{ +struct device_node *cpu, *cpus; +u32 i, cpuidx =1 , mpidr =read_cpuid_mpidr () &0xffffff ; +u32 tmp_map[NR_CPUS ]; +bool bootcpu_valid = false; + + cpus =of_find_node_by_path ("/cpus" ); + +if (!cpus) +return ; + +memset (tmp_map,0 ,sizeof (tmp_map)); + +for_each_child_of_node (cpus, cpu) { +u32 hwid; + +pr_debug (" * %s...\n" , cpu->full_name); +/* +* A device tree containing CPU nodes with missing "reg" +* properties is considered invalid to build the +* cpu_logical_map. +*/ +if (of_property_read_u32 (cpu,"reg" , &hwid)) { +pr_debug (" * %s missing reg property\n" , + cpu->full_name); +return ; + } + +/* +* Build a stashed array of MPIDR values. Numbering scheme +* requires that if detected the boot CPU must be assigned +* logical id 0. Other CPUs get sequential indexes starting +* from 1. If a CPU node with a reg property matching the +* boot CPU MPIDR is detected, this is recorded so that the +* logical map built from DT is validated and can be used +* to override the map created in smp_setup_processor_id(). +*/ +if (hwid == mpidr) { + i =0 ; + bootcpu_valid = true; + }else { + i = cpuidx++; + } + + tmp_map[i] = hwid; + +if (cpuidx > nr_cpu_ids) +break ; + } + +if (WARN (!bootcpu_valid,"DT CPU bindings are not valid," +"fall back to default cpu_logical_map\n" )) +return ; + +/* +* Since the boot CPU node contains proper data, and all nodes have +* a reg property, the DT CPU list can be considered valid and the +* logical map created in smp_setup_processor_id() can be overridden +*/ +for (i =0 ; i < cpuidx; i++) { +set_cpu_possible (i, true); +cpu_logical_map (i) = tmp_map[i]; +pr_debug ("cpu logical map 0x%x\n" ,cpu_logical_map (i)); + } +} +/** * setup_machine_fdt - Machine setup when an dtb was passed to the kernel * @dt_phys: physical address of dt blob Signature · 1 line
1.7.12
PATCH v2 2/5 ARM: kernel: add device tree init map function
Quoted 95 lines · Dave Martin
Quoted 74 lines · Lorenzo Pieralisi
When booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txtSigned-off-by Lorenzo Pieralisi <[email protected]>--- Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++ arch/arm/include/asm/prom.h | 2 + arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++ 3 files changed, 162 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cpus.txtDocumentation/devicetree/bindings/arm/cpus.txt new file +41
-0@@ -0,0 +1,84 @@ +* ARM CPUs binding description + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the ePAPR standard, available from: + +http://devicetree.org + +For the ARM architecture every CPU node must contain the following properties: + +- reg : property matching the CPU MPIDR[23:0] register bits +- compatible: must be set to "arm, <cpu-model>" + where <cpu-model> is the full processor name as used in the + processor Technical Reference Manual, eg: + - for a Cortex A9 processor + compatible = <arm, cortex-a9>; + - for a Cortex A15 processor + compatible = <arm, cortex-a15>; + +List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110>Documentation/devicetree/bindings/arm/cpus.txt line 51
Quoted 10 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +10
-0+<arm, sa1100> +<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7> +<arm, cortex-a8> +<arm, cortex-a9> +<arm, cortex-a15> +<arm, arm1136> +<arm, arm11-mpcore>Any views on how we make sure that this list gets maintained?
This binding feels like it probably is the right place to keep the exhaustive, "official" list of ARM CPU compatible strings, but I would not be surprised if it gets stale.
Also, do we worry about the "arm," namespace for compatible strings becoming overcrowded?
Quoted 6 lines
Currently we're shovelling a whole load of things in there, some of which are not ARM products.
Thiry-party implementations like mohawk, sa11*, xsc*, fa526 and feroceon are not ARM products, and should be in a different, appropriate vendor namespace.
I have nothing to object, all valid points.
Any views/feedback on this please ? I share most of Dave's concerns here.
Thanks,
Lorenzo
PATCH v2 2/5 ARM: kernel: add device tree init map function
In reply to Lorenzo PieralisiQuoted 102 lines · Lorenzo Pieralisi
When booting through a device tree, the kernel cpu logical id map can be initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and retrieves the corresponding CPUs hardware identifiers (MPIDR). It sets the possible cpus and the cpu logical map values according to the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain a "reg" property and the DT defines a CPU node that matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txtSigned-off-by Lorenzo Pieralisi <[email protected]>--- Documentation/devicetree/bindings/arm/cpus.txt | 84 ++++++++++++++++++++++++++ arch/arm/include/asm/prom.h | 2 + arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++ 3 files changed, 162 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cpus.txtDocumentation/devicetree/bindings/arm/cpus.txt new file +69
-0@@ -0,0 +1,84 @@ +* ARM CPUs binding description + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the ePAPR standard, available from: + +http://devicetree.org + +For the ARM architecture every CPU node must contain the following properties: + +- reg : property matching the CPU MPIDR[23:0] register bits +- compatible: must be set to "arm, <cpu-model>" + where <cpu-model> is the full processor name as used in the + processor Technical Reference Manual, eg: + - for a Cortex A9 processor + compatible = <arm, cortex-a9>; + - for a Cortex A15 processor + compatible = <arm, cortex-a15>; + +List of possible "compatible" string ids: + +<arm, arm1020> +<arm, arm1020e> +<arm, arm1022> +<arm, arm1026> +<arm, arm720> +<arm, arm740> +<arm, arm7tdmi> +<arm, arm920> +<arm, arm922> +<arm, arm925> +<arm, arm926> +<arm, arm940> +<arm, arm946> +<arm, arm9tdmi> +<arm, fa526> +<arm, feroceon> +<arm, mohawk> +<arm, sa110> +<arm, sa1100> +<arm, xsc3> +<arm, xscale> +<arm, cortex-a5> +<arm, cortex-a7> +<arm, cortex-a8> +<arm, cortex-a9> +<arm, cortex-a15> +<arm, arm1136> +<arm, arm11-mpcore> + +Every cpu node is required to set its device_type to "cpu". + +Example: + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu at 0 { + device_type = "cpu"; + compatible = <arm, cortex-a15>; + reg = <0x0>; + }; + + CPU1: cpu at 1 { + device_type = "cpu"; + compatible = <arm, cortex-a15>;
Documentation/devicetree/bindings/arm/cpus.txt line 79
Quoted 10 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +10
-0+ reg = <0x1>; + }; + + CPU2: cpu at 100 { + device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x100>; + }; + + CPU3: cpu at 101 {
Should we document the unit address convention as part of the binding documentation?
Using the MPIDR value here is a bit cumbersome, but I'm not sure if there's a better alternative, unless we make a multi-element vector out of the MPIDR to use as the address -- sounds like overkill.
Quoted 41 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +5
-0+ device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x101>; + }; + };arch/arm/include/asm/prom.h +2
-0@@ -15,6 +15,7 @@extern struct machine_desc *setup_machine_fdt (unsigned int dt_phys);extern void arm_dt_memblock_reserve (void ); +extern void __init arm_dt_init_cpu_maps (void );#else /* CONFIG_OF */ @@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys) }static inline void arm_dt_memblock_reserve (void ) { } +static inline void arm_dt_init_cpu_maps (void ) { }#endif /* CONFIG_OF */ #endif /* ASMARM_PROM_H */ arch/arm/kernel/devtree.c +2
-0@@ -19,8 +19,10 @@#include <linux/of_irq.h> #include <linux/of_platform.h> +#include <asm/cputype.h> #include <asm/setup.h> #include <asm/page.h> +#include <asm/smp_plat.h> #include <asm/mach/arch.h> #include <asm/mach-types.h>
arch/arm/kernel/devtree.c void __init arm_dt_memblock_reserve(void) · line 72
Quoted 10 lines
arch/arm/kernel/devtree.c +7
-0@@ -61,6 +63,80 @@ void __init arm_dt_memblock_reserve(void) } } +/* +* arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree +* and builds the cpu logical map array containing MPIDR values related to +* logical cpus +* +* Updates the cpu possible mask with the number of parsed cpu nodes +*/
Can this function sanity-check that we do not assign the same MPIDR value for multiple logical CPUs?
It turns out to be surprisingly easy to write a DT with duplicate reg properties in the CPUs node due to careless cut-and-paste. (i.e., I did it, but have been getting away with it up to now).
arch/arm/kernel/devtree.c void __init arm_dt_memblock_reserve(void) · line 74
Quoted 2 lines
arch/arm/kernel/devtree.c +2
-0+void __init arm_dt_init_cpu_maps (void ) +{
[...]
Cheers
---Dave
PATCH v2 2/5 ARM: kernel: add device tree init map function
Quoted 1 line · Dave Martin
On Fri, Nov 09, 2012 at 02:34:11PM +0000, Lorenzo Pieralisi wrote:
[...]
Quoted 31 lines
Quoted 17 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +17
-0+Every cpu node is required to set its device_type to "cpu". + +Example: + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu at 0 { + device_type = "cpu"; + compatible = <arm, cortex-a15>; + reg = <0x0>; + }; + + CPU1: cpu at 1 { + device_type = "cpu"; + compatible = <arm, cortex-a15>;Documentation/devicetree/bindings/arm/cpus.txt line 79
Quoted 10 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +10
-0+ reg = <0x1>; + }; + + CPU2: cpu at 100 { + device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x100>; + }; + + CPU3: cpu at 101 {Should we document the unit address convention as part of the binding documentation?
Quoted 3 lines
Using the MPIDR value here is a bit cumbersome, but I'm not sure if there's a better alternative, unless we make a multi-element vector out of the MPIDR to use as the address -- sounds like overkill.
I just followed the booting-without-of.txt convention for /cpu nodes, where the unit-address is just the reg property stripped of its leading zeros. I think it is the default way of defining the unit-address I do not know if I need to add to this, I certainly can.
Quoted 55 lines
Quoted 41 lines
Documentation/devicetree/bindings/arm/cpus.txt new file +5
-0+ device_type = "cpu"; + compatible = <arm, cortex-a7>; + reg = <0x101>; + }; + };arch/arm/include/asm/prom.h +2
-0@@ -15,6 +15,7 @@extern struct machine_desc *setup_machine_fdt (unsigned int dt_phys);extern void arm_dt_memblock_reserve (void ); +extern void __init arm_dt_init_cpu_maps (void );#else /* CONFIG_OF */ @@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys) }static inline void arm_dt_memblock_reserve (void ) { } +static inline void arm_dt_init_cpu_maps (void ) { }#endif /* CONFIG_OF */ #endif /* ASMARM_PROM_H */ arch/arm/kernel/devtree.c +2
-0@@ -19,8 +19,10 @@#include <linux/of_irq.h> #include <linux/of_platform.h> +#include <asm/cputype.h> #include <asm/setup.h> #include <asm/page.h> +#include <asm/smp_plat.h> #include <asm/mach/arch.h> #include <asm/mach-types.h> arch/arm/kernel/devtree.c void __init arm_dt_memblock_reserve(void) · line 72
Quoted 10 lines
arch/arm/kernel/devtree.c +7
-0@@ -61,6 +63,80 @@ void __init arm_dt_memblock_reserve(void) } } +/* +* arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree +* and builds the cpu logical map array containing MPIDR values related to +* logical cpus +* +* Updates the cpu possible mask with the number of parsed cpu nodes +*/ Can this function sanity-check that we do not assign the same MPIDR value for multiple logical CPUs?
Quoted 3 lines
It turns out to be surprisingly easy to write a DT with duplicate reg properties in the CPUs node due to careless cut-and-paste. (i.e., I did it, but have been getting away with it up to now).
Check added. Waiting for some comments on the compatible list of ids to post v3.
Thanks a lot,
Lorenzo
PATCH v2 3/5 ARM: kernel: add cpu logical map DT init in setup_arch
In reply to Lorenzo PieralisiAs soon as the device tree is unflattened the cpu logical to physical mapping is carried out in setup_arch to build a proper array of MPIDR and corresponding logical indexes.
The mapping could have been carried out using the flattened DT blob and related primitives, but since the mapping is not needed by early boot code it can safely be executed when the device tree has been uncompressed to its tree data structure.
This patch adds the arm_dt_init_cpu maps() function call in setup_arch().
If the kernel is not compiled with DT support the function is empty and no logical mapping takes place through it; the mapping carried out in smp_setup_processor_id() is left unchanged.
If DT is supported the mapping created in smp_setup_processor_id() is overriden. The DT mapping also sets the possible cpus mask, hence platform code need not set it again in the respective smp_init_cpus() functions.
--- arch/arm/kernel/setup.c | 1 + 1 file changed, 1 insertion(+)
arch/arm/kernel/setup.c +1 -0
@@ -759,6 +759,7 @@ void __init setup_arch(char **cmdline_p)unflatten_device_tree (); +arm_dt_init_cpu_maps ();#ifdef CONFIG_SMP if (is_smp ()) {smp_set_ops (mdesc->smp);
Signature · 1 line
1.7.12
PATCH v2 4/5 ARM: kernel: add logical mappings look-up
In reply to Lorenzo PieralisiIn ARM SMP systems the MPIDR register ([23:0] bits) is used to uniquely identify CPUs.
In order to retrieve the logical CPU index corresponding to a given MPIDR value and guarantee a consistent translation throughout the kernel, this patch adds a look-up based on the MPIDR[23:0] so that kernel subsystems can use it whenever the logical cpu index corresponding to a given MPIDR value is needed.
--- arch/arm/include/asm/smp_plat.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
arch/arm/include/asm/smp_plat.h +17 -0
@@ -5,6 +5,9 @@#ifndef __ASMARM_SMP_PLAT_H#define __ASMARM_SMP_PLAT_H +#include <linux/cpumask.h> +#include <linux/err.h> +#include <asm/cputype.h> /*
@@ -48,5 +51,19 @@ static inline int cache_ops_need_broadcast(void)*/ extern int __cpu_logical_map[];#define cpu_logical_map (cpu) __cpu_logical_map[cpu] +/* +* Retrieve logical cpu index corresponding to a given MPIDR[23:0] +* - mpidr: MPIDR[23:0] to be used for the look-up +* +* Returns the cpu logical index or -EINVAL on look-up error +*/ +static inline int get_logical_index (u32 mpidr) +{ +int cpu; +for (cpu =0 ; cpu < nr_cpu_ids; cpu++) +if (cpu_logical_map (cpu) == mpidr) +return cpu; +return -EINVAL ; +}#endif
Signature · 1 line
1.7.12
PATCH v2 5/5 ARM: gic: use a private mapping for CPU target interfaces
In reply to Lorenzo PieralisiFrom: Nicolas Pitre <[email protected]>
The GIC interface numbering does not necessarily follow the logical CPU numbering, especially for complex topologies such as multi-cluster systems.
Fortunately we can easily probe the GIC to create a mapping as the Interrupt Processor Targets Registers for the first 32 interrupts are read-only, and each field returns a value that always corresponds to the processor reading the register.
Initially all mappings target all CPUs in case an IPI is required to boot secondary CPUs. It is refined as those CPUs discover what their actual mapping is.
--- arch/arm/common/gic.c | 45 ++++++++++++++++++++++++++++++++++++--------- 1 file changed, 36 insertions(+), 9 deletions(-)
arch/arm/common/gic.c +36 -9
@@ -70,6 +70,14 @@ struct gic_chip_data {static DEFINE_RAW_SPINLOCK (irq_controller_lock);/* +* The GIC mapping of CPU interfaces does not necessarily match +* the logical CPU numbering. Let's use a mapping as returned +* by the GIC itself. +*/ +#define NR_GIC_CPU_IF 8 +static u8 gic_cpu_map[NR_GIC_CPU_IF ]__read_mostly ; + +/* * Supported arch specific GIC irq extension. * Default make them NULL. */
@@ -238,11 +246,11 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,unsigned int cpu =cpumask_any_and (mask_val, cpu_online_mask);u32 val, mask, bit; -if (cpu >=8 || cpu >= nr_cpu_ids) +if (cpu >=NR_GIC_CPU_IF || cpu >= nr_cpu_ids)return -EINVAL ; mask =0xff << shift; - bit =1 << (cpu_logical_map (cpu) + shift); + bit = gic_cpu_map[cpu] << shift;raw_spin_lock (&irq_controller_lock); val =readl_relaxed (reg) & ~mask;
@@ -349,11 +357,6 @@ static void __init gic_dist_init(struct gic_chip_data *gic)u32 cpumask;unsigned int gic_irqs = gic->gic_irqs;void __iomem *base =gic_data_dist_base (gic); -u32 cpu =cpu_logical_map (smp_processor_id ()); - - cpumask =1 << cpu; - cpumask |= cpumask <<8 ; - cpumask |= cpumask <<16 ;writel_relaxed (0 , base +GIC_DIST_CTRL );
@@ -366,6 +369,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic)/* * Set all global interrupts to this CPU only. */ + cpumask =readl_relaxed (base +GIC_DIST_TARGET +0 );for (i =32 ; i < gic_irqs; i +=4 )writel_relaxed (cpumask, base +GIC_DIST_TARGET + i *4 /4 );
@@ -389,9 +393,25 @@ static void __cpuinit gic_cpu_init(struct gic_chip_data *gic) {void __iomem *dist_base =gic_data_dist_base (gic);void __iomem *base =gic_data_cpu_base (gic); +unsigned int cpu_mask, cpu =smp_processor_id ();int i;/* +* Get what the GIC says our CPU mask is. +*/ +BUG_ON (cpu >=NR_GIC_CPU_IF ); + cpu_mask =readl_relaxed (dist_base +GIC_DIST_TARGET +0 ); + gic_cpu_map[cpu] = cpu_mask; + +/* +* Clear our mask from the other map entries in case they're +* still undefined. +*/ +for (i =0 ; i <NR_GIC_CPU_IF ; i++) +if (i != cpu) + gic_cpu_map[i] &= ~cpu_mask; + +/* * Deal with the banked PPI and SGI interrupts - disable all * PPI interrupts, ensure all SGI interrupts are enabled. */
@@ -654,7 +674,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, {irq_hw_number_t hwirq_base;struct gic_chip_data *gic; -int gic_irqs, irq_base; +int gic_irqs, irq_base, i;BUG_ON (gic_nr >=MAX_GIC_NR );
@@ -692,6 +712,13 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, }/* +* Initialize the CPU interface map to all CPUs. +* It will be refined as each CPU probes its ID. +*/ +for (i =0 ; i <NR_GIC_CPU_IF ; i++) + gic_cpu_map[i] =0xff ; + +/* * For primary GICs, skip over SGIs. * For secondary GICs, skip over PPIs, too. */
@@ -746,7 +773,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)/* Convert our logical CPU mask into a physical one. */ for_each_cpu (cpu, mask) - map |=1 <<cpu_logical_map (cpu); + map |= gic_cpu_map[cpu];/* * Ensure that stores to Normal memory are visible to the
Signature · 1 line
1.7.12