cpufeatures compatibility for OPAL and Linux
Subsystems (3)
Nicholas Piggin
reviewerv2 cover cpufeatures compatibility for OPAL and Linux
Hi,
This is a bit more complete implementation that also works on POWER9. Any comments would be welcome.
Thanks,
Nick
Nicholas Piggin
reviewerPATCH 1/1 cpufeatures: add base and POWER8, POWER9 /cpus/features dt
With this patch and the Linux one, I can boot (in mambo) a POWER8 or POWER9 without looking up any cpu tables, and mainly looking at PVR for MCE and PMU.
Machine and ISA speicfic features that are not abstracted by firmware and not captured here will have to be handled on a case by case basis, using PVR if necessary. Major ones that remain are PMU and machine check.
Open question is where and how to develop and document these features? Not the dt representation created by skiboot, but the exact nature of each feature. What exact behaviour does a particular feature imply, etc.
Thanks,
Nick
--- core/device.c | 7 + core/init.c | 3 + hdata/cpu-common.c | 602 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/device.h | 1 + 4 files changed, 613 insertions(+)
core/device.c +7 -0
@@ -548,6 +548,13 @@ u32 dt_property_get_cell(const struct dt_property *prop, u32 index)return fdt32_to_cpu (((const u32 *)prop->prop)[index]); } +void dt_property_set_cell (struct dt_property *prop,u32 index,u32 val) +{ +assert (prop->len >= (index+1 )*sizeof (u32)); +/* Always aligned, so this works. */ + ((u32 *)prop->prop)[index] =cpu_to_fdt32 (val); +} +/* First child of this node. */ struct dt_node *dt_first (const struct dt_node *root) {
core/init.c +3 -0
@@ -703,6 +703,8 @@ static void per_thread_sanity_checks(void)/* Called from head.S, thus no prototype. */ void main_cpu_entry (const void *fdt); +extern void mambo_add_cpu_features (struct dt_node *root); + void __noreturn __nomcount main_cpu_entry(const void *fdt) {/*
@@ -774,6 +776,7 @@ void __noreturn __nomcount main_cpu_entry(const void *fdt)abort (); }else {dt_expand (fdt); +mambo_add_cpu_features (dt_root); }/* Now that we have a full devicetree, verify that we aren't on fire. */
hdata/cpu-common.c +602 -0
636 lines not on this page · raw message
include/device.h +1 -0
@@ -125,6 +125,7 @@ void dt_check_del_prop(struct dt_node *node, const char *name);/* Warning: moves *prop! */ void dt_resize_property (struct dt_property **prop,size_t len); +void dt_property_set_cell (struct dt_property *prop,u32 index,u32 val);u32 dt_property_get_cell (const struct dt_property *prop,u32 index);/* First child of this node. */
Signature · 1 line
2.11.0
Re: [Skiboot] [PATCH][OPAL] cpufeatures: add base and POWER8, POWER9 /cpus/features dt
Quoted 3 lines · Nicholas Piggin
With this patch and the Linux one, I can boot (in mambo) a POWER8 or POWER9 without looking up any cpu tables, and mainly looking at PVR for MCE and PMU.
That's pretty neat. I now await the day where somebody produces a chip with uneven feature sets between cores.
Quoted 4 lines
Machine and ISA speicfic features that are not abstracted by firmware and not captured here will have to be handled on a case by case basis, using PVR if necessary. Major ones that remain are PMU and machine check.
At least for machine check we could probably get something "good enough" without too much effort.
For PMU, I wonder if we could get something that's suitably common with the IMC work being done so that we could "just work" on new PMUs (albeit calling into OPAL for enable/disable)
Quoted 4 lines
Open question is where and how to develop and document these features? Not the dt representation created by skiboot, but the exact nature of each feature. What exact behaviour does a particular feature imply, etc.
Part of me seems to think this could be something for the Architecture, and then we just have a 1-to-1 mapping of the arch bits and we're all one big happy family....
Benh/Paulus can probably laugh at me suitably hard for suggesting such a thing being possible though :)
I see the kernel patch has docs for the DT bindings, I'd like to also keep a copy in the skiboot tree, if only to further my impossible quest to somewhat document the OPAL ABI.
Quoted 32 lines
core/device.c +7
-0@@ -548,6 +548,13 @@ u32 dt_property_get_cell(const struct dt_property *prop, u32 index)return fdt32_to_cpu (((const u32 *)prop->prop)[index]); } +void dt_property_set_cell (struct dt_property *prop,u32 index,u32 val) +{ +assert (prop->len >= (index+1 )*sizeof (u32)); +/* Always aligned, so this works. */ + ((u32 *)prop->prop)[index] =cpu_to_fdt32 (val); +} +/* First child of this node. */ struct dt_node *dt_first (const struct dt_node *root) {core/init.c +2
-0@@ -703,6 +703,8 @@ static void per_thread_sanity_checks(void)/* Called from head.S, thus no prototype. */ void main_cpu_entry (const void *fdt); +extern void mambo_add_cpu_features (struct dt_node *root); + void __noreturn __nomcount main_cpu_entry(const void *fdt) {/*
core/init.c void __noreturn __nomcount main_cpu_entry(const void *fdt) · line 780
Quoted 5 lines
core/init.c +1
-0@@ -774,6 +776,7 @@ void __noreturn __nomcount main_cpu_entry(const void *fdt)abort (); }else {dt_expand (fdt); +mambo_add_cpu_features (dt_root); }
(without checking closely, just going from memory), this would also the the case on P8 OpenPOWER hardware, as we get the device tree from Hostboot there too.
hdata/cpu-common.c line 151
Quoted 12 lines
core/init.c +0
-0/* Now that we have a full devicetree, verify that we aren't on fire. */ hdata/cpu-common.c +6
-0+ {"vector-crypto" , +CPU_ALL , +ISA_BASE ,USABLE_HV |USABLE_OS |USABLE_PR , +HV_SUPPORT_NONE ,OS_SUPPORT_NONE , +-1 ,-1 ,38 , + "vector", },
Did we want to break this down at all? Specifically maybe just the AES instructions?
AFAIK it's been the only set where there was some amount of discussion about somebody possibly not wanting to include.
Signature · 2 lines
Stewart Smith OPAL Architect, IBM.
Nicholas Piggin
reviewerRe: [Skiboot] [PATCH][OPAL] cpufeatures: add base and POWER8, POWER9 /cpus/features dt
Quoted 8 lines · On Tue, 21 Mar 2017 15:42:22 +1100 Stewart Smith <[email protected]>…
Quoted 3 lines · Nicholas Piggin
With this patch and the Linux one, I can boot (in mambo) a POWER8 or POWER9 without looking up any cpu tables, and mainly looking at PVR for MCE and PMU.
That's pretty neat. I now await the day where somebody produces a chip with uneven feature sets between cores.
Quoted 7 lines
Quoted 4 lines
Machine and ISA speicfic features that are not abstracted by firmware and not captured here will have to be handled on a case by case basis, using PVR if necessary. Major ones that remain are PMU and machine check.
At least for machine check we could probably get something "good enough" without too much effort.
Machine check I'd like to put it in opal with a special case entry from the hypervisor. At the moment it just has a lot of implementation specific decoding of bits, and we can't really call opal to do anything useful with normal call because it re-enters the stack.
Quoted 3 lines
For PMU, I wonder if we could get something that's suitably common with the IMC work being done so that we could "just work" on new PMUs (albeit calling into OPAL for enable/disable)
I don't know the PMU code, but if we could have some kind of firmware fallback like that it would be perfect.
For machine specific implementations that are faster or more capable, I guess looking at PVR is not taboo as such. Just that it shouldn't be needed to boot and get some reasonable baseline.
Quoted 11 lines
Quoted 4 lines
Open question is where and how to develop and document these features? Not the dt representation created by skiboot, but the exact nature of each feature. What exact behaviour does a particular feature imply, etc.
Part of me seems to think this could be something for the Architecture, and then we just have a 1-to-1 mapping of the arch bits and we're all one big happy family....
Benh/Paulus can probably laugh at me suitably hard for suggesting such a thing being possible though :)
I think to a degree we might be moving in that direction. Probably can't say much more in public at the moment, but at least this dt implementation must be flexible enough to cope with a range of approaches we might decide to take (fine/coarse grained, fscr bits or not, etc).
Quoted 3 lines
I see the kernel patch has docs for the DT bindings, I'd like to also keep a copy in the skiboot tree, if only to further my impossible quest to somewhat document the OPAL ABI.
That can be arranged.
Quoted 26 lines
Quoted 26 lines
core/device.c +7
-0@@ -548,6 +548,13 @@ u32 dt_property_get_cell(const struct dt_property *prop, u32 index)return fdt32_to_cpu (((const u32 *)prop->prop)[index]); } +void dt_property_set_cell (struct dt_property *prop,u32 index,u32 val) +{ +assert (prop->len >= (index+1 )*sizeof (u32)); +/* Always aligned, so this works. */ + ((u32 *)prop->prop)[index] =cpu_to_fdt32 (val); +} +/* First child of this node. */ struct dt_node *dt_first (const struct dt_node *root) {core/init.c +0
-0@@ -703,6 +703,8 @@ static void per_thread_sanity_checks(void)/* Called from head.S, thus no prototype. */ void main_cpu_entry (const void *fdt);
Quoted 15 lines
core/init.c void __noreturn __nomcount main_cpu_entry(const void *fdt) · line 780
Quoted 11 lines
core/init.c +3
-0+extern void mambo_add_cpu_features (struct dt_node *root); + void __noreturn __nomcount main_cpu_entry(const void *fdt) {/* @@ -774,6 +776,7 @@ void __noreturn __nomcount main_cpu_entry(const void *fdt)abort (); }else {dt_expand (fdt); +mambo_add_cpu_features (dt_root); }(without checking closely, just going from memory), this would also the the case on P8 OpenPOWER hardware, as we get the device tree from Hostboot there too.
Okay I'll look into it.
Quoted 16 lines
hdata/cpu-common.c line 151
Quoted 12 lines
core/init.c +0
-0/* Now that we have a full devicetree, verify that we aren't on fire. */ hdata/cpu-common.c +6
-0+ {"vector-crypto" , +CPU_ALL , +ISA_BASE ,USABLE_HV |USABLE_OS |USABLE_PR , +HV_SUPPORT_NONE ,OS_SUPPORT_NONE , +-1 ,-1 ,38 , + "vector", },Did we want to break this down at all? Specifically maybe just the AES instructions?
Quoted 2 lines
AFAIK it's been the only set where there was some amount of discussion about somebody possibly not wanting to include.
I don't have much opinion on it. Userspace has only the one feature bit there, so missing part of the instructions would have to disable the entire thing.
That's not to say we couldn't add another bit and start getting userspace to use it. So if there is some need or strong potential future need, we should consider it.
Thanks,
Nick
Re: [Skiboot] [PATCH][OPAL] cpufeatures: add base and POWER8, POWER9 /cpus/features dt
Quoted 16 lines · Nicholas Piggin
Quoted 13 lines · On Tue, 21 Mar 2017 15:42:22 +1100 Stewart Smith <[email protected]>…
Quoted 3 lines · Nicholas Piggin
With this patch and the Linux one, I can boot (in mambo) a POWER8 or POWER9 without looking up any cpu tables, and mainly looking at PVR for MCE and PMU.
That's pretty neat. I now await the day where somebody produces a chip with uneven feature sets between cores.
Quoted 4 lines
Machine and ISA speicfic features that are not abstracted by firmware and not captured here will have to be handled on a case by case basis, using PVR if necessary. Major ones that remain are PMU and machine check.
Quoted 7 lines
Quoted 2 lines
At least for machine check we could probably get something "good enough" without too much effort.
Machine check I'd like to put it in opal with a special case entry from the hypervisor. At the moment it just has a lot of implementation specific decoding of bits, and we can't really call opal to do anything useful with normal call because it re-enters the stack.
Ahh yep. Something along the lines of a machine check specific stack in OPAL could do it, and we queue up calls etc etc.
It turns out my "not too much effort" metric is possibly different from other people's :)
Quoted 10 lines
Quoted 3 lines
For PMU, I wonder if we could get something that's suitably common with the IMC work being done so that we could "just work" on new PMUs (albeit calling into OPAL for enable/disable)
I don't know the PMU code, but if we could have some kind of firmware fallback like that it would be perfect.
For machine specific implementations that are faster or more capable, I guess looking at PVR is not taboo as such. Just that it shouldn't be needed to boot and get some reasonable baseline.
Yeah, I'm not that familiar with it either. I need to go look over it all in my copious amount of free time.
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
Open question is where and how to develop and document these features? Not the dt representation created by skiboot, but the exact nature of each feature. What exact behaviour does a particular feature imply, etc.
Part of me seems to think this could be something for the Architecture, and then we just have a 1-to-1 mapping of the arch bits and we're all one big happy family....
Quoted 8 lines
Quoted 2 lines
Benh/Paulus can probably laugh at me suitably hard for suggesting such a thing being possible though :)
I think to a degree we might be moving in that direction. Probably can't say much more in public at the moment, but at least this dt implementation must be flexible enough to cope with a range of approaches we might decide to take (fine/coarse grained, fscr bits or not, etc).
Yeah, I think so too.
Quoted 16 lines
Quoted 13 lines
hdata/cpu-common.c line 151
Quoted 9 lines
hdata/cpu-common.c +6
-0+ {"vector-crypto" , +CPU_ALL , +ISA_BASE ,USABLE_HV |USABLE_OS |USABLE_PR , +HV_SUPPORT_NONE ,OS_SUPPORT_NONE , +-1 ,-1 ,38 , + "vector", },Did we want to break this down at all? Specifically maybe just the AES instructions?
Quoted 2 lines
AFAIK it's been the only set where there was some amount of discussion about somebody possibly not wanting to include.
Quoted 7 lines
I don't have much opinion on it. Userspace has only the one feature bit there, so missing part of the instructions would have to disable the entire thing.
That's not to say we couldn't add another bit and start getting userspace to use it. So if there is some need or strong potential future need, we should consider it.
Hopefully we're right on ISA3.00 for new instructions that random folk may say could be disabled if they fab'd their own chip :)
Signature · 2 lines
Stewart Smith OPAL Architect, IBM.
Nicholas Piggin
reviewerPATCH 1/1 powerpc/64s: cpufeatures: add initial implementation for cpufeatures
In reply to Nicholas PigginThe /cpus/features dt binding describes architected CPU features along with some compatibility, privilege, and enablement properties that allow flexibility with discovering and enabling capabilities.
Presence of this feature implies a base level of functionality, then additional feature nodes advertise the presence of new features.
A given feature and its setup procedure is defined once and used by all CPUs which are compatible by that feature. Features that follow a supported "prescription" can be enabled by a hypervisor or OS that does not understand them natively.
Using this, we can do CPU setup without matching CPU tables on PVR, and mambo can boot in POWER8 or POWER9 mode. Modulo allowances to support MCE and PMU.
I'm looking at cpu features and hfscr/fscr/lpcr/msr etc bits before and after the patch to make sure we're doing things properly. There are still a few small differences:
POWER8
- CPU_FTR_NODSISRALIGN is now clear. DSISR is set on alignment interrupts.
- HFSCR bit 54 and 57 are now clear. This appears to be a mambo issue.
POWER9
- VRMASD is clear from LPCR. This is not supported in ISA3 mode.
- Privileged Doorbell Exit Enable is set in LPCR.
Before asking to merge this patch I'll send patches to existing cputable code to change those and update this patch if they are rejected, so the differences are squashed before merging.
Thanks,
Nick
--- .../devicetree/bindings/powerpc/cpufeatures.txt | 263 ++++++++++ arch/powerpc/include/asm/cpu_has_feature.h | 4 +- arch/powerpc/include/asm/cpufeatures.h | 54 ++ arch/powerpc/include/asm/cputable.h | 1 + arch/powerpc/include/asm/reg.h | 1 + arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/cpufeatures.c | 565 +++++++++++++++++++++ arch/powerpc/kernel/cputable.c | 14 +- arch/powerpc/kernel/prom.c | 201 +++++++- arch/powerpc/kernel/setup-common.c | 2 +- arch/powerpc/kernel/setup_64.c | 21 +- drivers/of/fdt.c | 31 ++ include/linux/of_fdt.h | 5 + 13 files changed, 1144 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/cpufeatures.txt create mode 100644 arch/powerpc/include/asm/cpufeatures.h create mode 100644 arch/powerpc/kernel/cpufeatures.c
Documentation/devicetree/bindings/powerpc/cpufeatures.txt new file +263 -0
@@ -0,0 +1,263 @@ +powerpc cpu features binding +============================ + +The device tree describes supported CPU features as nodes containing +compatibility and enablement information as properties. + +The binding specifies features common to all CPUs in the system. +Heterogeneous CPU features are not supported at present (such could be added +by providing nodes with additional features and linking those to particular +CPUs). + +This binding is intended to provide fine grained control of CPU features at +all levels of the stack (firmware, hypervisor, OS, userspace), with the +ability for new CPU features to be used by some components without all +components being upgraded (e.g., a new floating point instruction could be +used by userspace math library without upgrading kernel and hypervisor). + +The binding is passed to the hypervisor by firmware. The hypervisor must +remove any features that require hypervisor enablement but that it does not +enable. It must remove any features that depend on removed features. It may +pass remaining features usable to the OS and PR to guests, depending on +configuration policy (not specified here). + +The modified binding is passed to the guest by hypervisor, with HV bit +cleared from the usable-mask and the hv-support and hfscr-bit properties +removed. The guest must similarly rmeove features that require OS enablement +that it does not enable. The OS may pass PR usable features to userspace via +ELF AUX vectors AT_HWCAP, AT_HWCAP2, AT_HWCAP3, etc., or use some other +method (outside the scope of this specification). + +The binding will specify a "base" level of features that will be present +when the cpu features binding exists. Additional features will be explicitly +specified. + +/cpus/features node binding +--------------------------- + +Node: features + +Description: Container of CPU feature nodes. + +The node name must be "features" and it must be a child of the node "/cpus". + +The node is optional but should be provided by new firmware. + +Each child node of cpufeatures represents an architected CPU feature (e.g., +a new set of vector instructions) or an important CPU performance +characteristic (e.g., fast unaligned memory operations). The specification +of each feature (instructions, registers, exceptions, etc.) will be +documented with device tree bindings. + +As a rough guide, features should be based on functional groups of changes, +those that share common enablement requirements, that share particular +registers or functionality. For example, "POWER9" would be too general, and +a new feature for every instruction would be too specific. The "summary of +changes" preface in Power ISA specification is a good guideline for the +architected features. + +Features should be "positive" where possible. For example the presence of a +feature node should indicate the presence of a new CPU feature (e.g., a +new instruction or register). An errata workaround for example would then +remove that feature from the device tree to disable it. "Negative" features +may be unavoidable in some cases. + +Properties: + +- device_type + Usage: required + Value type: string + Definition: "cpu-features" + +- isa + Usage: required + Value type: <u32> + Definition: + + isa that the CPU is currently running in. This provides instruction set + compatibility, less the individual feature nodes. For example, an ISA v3.0 + implementation that lacks the "transactional-memory" cpufeature node + should not use transactional memory facilities. + + Value corresponds to the "Power ISA Version" multiplied by 1000. + For example, <3000> corresponds to Version 3.0, <2070> to Version 2.07. + The minor digit is available for revisions. + +/cpus/features/feature node bindings +------------------------------------ + +Node: A string describing an architected CPU feature, e.g., "vsx". + +Description: An architected feature supported by the CPUs. + +The name of the node will follow a convention such that software will +match known features by a string comparison with the node name. Presence +of the node indicates the feature is available to use (XXX: could +advertise all supported by hardware, with disabled/enabled status +property). + +The name of the child node corresponds to the name of the feature. +Software will detect known features by string matching. + +Properties: + +- isa + Usage: required + Value type: <u32> + Definition: + + First level of the Power ISA that the feature appears in. + Software should filter out features when constraining the + environment to a particular ISA version. + + Value is defined similarly to /cpus/features/isa + +- usable-mask + Usage: required + Value type: <u32> bit mask + Definition: + bit 0 - PR (problem state / user mode) + bit 1 - OS (privileged state) + bit 2 - HV (hypervisor state) + All other bits reserved and should be zero. + + This property describes the privilege levels and/or software components + that can use the feature. + + If bit 0 is set, then the hwcap-bit-nr property will exist. + + Reserved bits must be treated as the feature being unsupported. + +- hv-support + Usage: optional + Value type: <u32> + Definition: + 1 - Custom + 2 - HFSCR + Other values reserved. + + This property describes the HV privilege state support required to + enable the feature. If the property does not exist then no support is + required. + + If the value of this property is 1, then the hypervisor must have + explicit support for this feature. + + If the value of this property is 2, then the hfscr-bit-nr property + will exist. + + Reserved values must be treated as the feature being unsupported. + +- os-support + Usage: optional + Value type: <u32> + Definition: + 1 - Custom + 2 - FSCR + Other values reserved. + + This property describes the OS privilege state support required to + enable the feature. If the property does not exist then no support is + required. + + If the value of this property is 1, then the operating system must + have explicit support for this feature. + + If the value of this property is 2, then the fscr-bit-nr property will + exist. + + Reserved values must be treated as the feature being unsupported. + +- hfscr-bit-nr + Usage: optional + Value type: <u32> + Definition: + + This property exists when the hv-support property value is 2. This + property describes the bit number in the HFSCR register that the + hypervisor must set in order to enable this feature. + +- fscr-bit-nr + Usage: optional + Value type: <u32> + Definition: + + This property exists when the os-support property value is 2. This + property describes the bit number in the FSCR register that the + operating system must set in order to enable this feature. + +- hwcap-bit-nr + Usage: optional + Value type: <u32> + Definition: + + This property may exist when the usable-mask property value has bit 0 + (PR) set. This property describes the bit number that should be set in + the ELF AUX hardware capability vectors in order to advertise this + feature to userspace. Bits 0-31 correspond to bits 0-31 in AT_HWCAP + vector. Bits 32-63 correspond to 0-31 in AT_HWCAP2 vector, and so on. + Missing AT_HWCAPx vectors implies that the feature is not enabled or + can not be advertised. Operating systems may provide a number of + unassigned hardware capability bits to allow for new features to be + advertised. + + Some properties representing features created before this binding are + advertised to userspace without a one-to-one hwcap bit number may not + specify this bit. Operating system will handle those bits specifically. + All new features usable by userspace will have a hwcap-bit-nr property. + +- dependencies + Usage: optional + Value type: <prop-encoded-array> + Definition: + + If this property exists then it is a list of phandles to cpu feature + nodes that must be enabled for this feature to be enabled. + + +Example +------- + + /cpus/features { + device_type = "cpu-features"; + + isa = <3020>; + + darn { + isa = <3000>; + usable-mask = <1 | 2 | 4>; + hwcap-bit-nr = <xx>; + }; + + scv { + isa = <3000>; + usable-mask = <1 | 2>; + os-support = <1>; + hwcap-bit-nr = <xx>; + }; + + stop { + isa = <3000>; + usable-mask = <2 | 4>; + hv-support = <1>; + os-support = <1>; + }; + + vsx2 (hypothetical) { + isa = <3010>; + usable-mask = <1 | 2 | 4>; + hv-support = <1>; + os-support = <1>; + hwcap-bit-nr = <xx>; + }; + + vsx2-newinsns { + isa = <3020>; + usable-mask = <1 | 2 | 4>; + os-support = <2>; + fscr-bit-nr = <xx>; + hwcap-bit-nr = <xx>; + dependencies = <&vsx2>; + }; + + };
arch/powerpc/include/asm/cpu_has_feature.h +2 -2
@@ -1,5 +1,5 @@ -#ifndef __ASM_POWERPC_CPUFEATURES_H -#define __ASM_POWERPC_CPUFEATURES_H +#ifndef __ASM_POWERPC_CPU_HAS_FEATURE_H +#define __ASM_POWERPC_CPU_HAS_FEATURE_H#ifndef __ASSEMBLY__
arch/powerpc/include/asm/cpufeatures.h new file +54 -0
54 lines not on this page · raw message
arch/powerpc/include/asm/cputable.h +1 -0
@@ -118,6 +118,7 @@ extern struct cpu_spec *cur_cpu_spec;extern unsigned int __start___ftr_fixup, __stop___ftr_fixup; +extern void set_cur_cpu_spec (struct cpu_spec *s);extern struct cpu_spec *identify_cpu (unsigned long offset,unsigned int pvr);extern void do_feature_fixups (unsigned long value,void *fixup_start,void *fixup_end);
arch/powerpc/include/asm/reg.h +1 -0
@@ -1223,6 +1223,7 @@#define PVR_POWER8E 0x004B#define PVR_POWER8NVL 0x004C#define PVR_POWER8 0x004D +#define PVR_POWER9 0x004E#define PVR_BE 0x0070#define PVR_PA6T 0x0090
arch/powerpc/kernel/Makefile +1 -0
@@ -44,6 +44,7 @@ obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \ obj-$(CONFIG_VDSO32) += vdso32/ obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o +obj-$(CONFIG_PPC_BOOK3S_64) += cpufeatures.o obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_power.o obj-$(CONFIG_PPC_BOOK3S_64) += mce.o mce_power.o obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o idle_book3e.o
arch/powerpc/kernel/cpufeatures.c new file +565 -0
565 lines not on this page · raw message
arch/powerpc/kernel/cputable.c +12 -2
@@ -23,7 +23,9 @@#include <asm/mmu.h> #include <asm/setup.h> -struct cpu_spec * cur_cpu_spec =NULL ; +static struct cpu_spec the_cpu_spec__read_mostly ; + +struct cpu_spec * cur_cpu_spec__read_mostly =NULL ;EXPORT_SYMBOL (cur_cpu_spec);/* The platform string corresponding to the real PVR */
@@ -2159,7 +2161,15 @@ static struct cpu_spec __initdata cpu_specs[] = {#endif /* CONFIG_E500 */ }; -static struct cpu_spec the_cpu_spec; +void __init set_cur_cpu_spec (struct cpu_spec *s) +{ +struct cpu_spec *t = &the_cpu_spec; + + t =PTRRELOC (t); + *t = *s; + + *PTRRELOC (&cur_cpu_spec) = &the_cpu_spec; +}static struct cpu_spec *__init setup_cpu_spec (unsigned long offset,struct cpu_spec *s)
arch/powerpc/kernel/prom.c +189 -12
241 lines not on this page · raw message
arch/powerpc/kernel/setup-common.c +1 -1
@@ -256,7 +256,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)seq_printf (m,"processor\t: %lu\n" , cpu_id);seq_printf (m,"cpu\t\t: " ); -if (cur_cpu_spec->pvr_mask) +if (cur_cpu_spec->pvr_mask && cur_cpu_spec->cpu_name)seq_printf (m,"%s" , cur_cpu_spec->cpu_name);else seq_printf (m,"unknown (%08x)" , pvr);
arch/powerpc/kernel/setup_64.c +19 -2
@@ -49,6 +49,7 @@#include <asm/paca.h> #include <asm/time.h> #include <asm/cputable.h> +#include <asm/cpufeatures.h> #include <asm/sections.h> #include <asm/btext.h> #include <asm/nvram.h>
@@ -264,11 +265,22 @@ static void cpu_ready_for_interrupts(void)void __init early_setup (unsigned long dt_ptr) {static __initdata struct paca_struct boot_paca; +int cpufeatures =0 ;/* -------- printk is _NOT_ safe to use here ! ------- */ -/* Identify CPU type */ -identify_cpu (0 ,mfspr (SPRN_PVR )); +#ifdef CONFIG_PPC_BOOK3S_64 +/* Setup flat device-tree pointer */ + initial_boot_params =__va (dt_ptr); +if (early_init_devtree_check_cpu_features_exists ()) { + cpufeatures =1 ; +cpufeatures_setup_cpu (); + } else +#endif + { +/* Legacy table-based approach when /cpus/features is missing */ +identify_cpu (0 ,mfspr (SPRN_PVR )); + }/* Assume we're on cpu 0 for now. Don't write to the paca yet! */ initialise_paca (&boot_paca,0 );
@@ -282,6 +294,8 @@ void __init early_setup(unsigned long dt_ptr)DBG (" -> early_setup(), dt_ptr: 0x%lx\n" , dt_ptr); +printk ("cpufeatures:%d\n" , cpufeatures); +/* * Do early initialization using the flattened device * tree, such as retrieving the physical memory map or
@@ -531,6 +545,9 @@ void __init initialize_cache_info(void) dcache_bsize = ppc64_caches.l1d.block_size; icache_bsize = ppc64_caches.l1i.block_size; + cur_cpu_spec->dcache_bsize = dcache_bsize; + cur_cpu_spec->icache_bsize = icache_bsize; +DBG (" <- initialize_cache_info()\n" ); }
drivers/of/fdt.c +31 -0
@@ -754,6 +754,37 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node, }/** +* of_scan_flat_dt_subnodes - scan sub-nodes of a node call callback on each. +* @it: callback function +* @data: context data pointer +* +* This function is used to scan sub-nodes of a node. +*/ +int __init of_scan_flat_dt_subnodes (unsigned long node, +int (*it)(unsigned long node, +const char *uname, +void *data), +void *data) +{ +const void *blob = initial_boot_params; +const char *pathp; +int offset, rc =0 ; + + offset = node; +for (offset =fdt_first_subnode (blob, offset); + offset >=0 && !rc; + offset =fdt_next_subnode (blob, offset)) { + + pathp =fdt_get_name (blob, offset,NULL ); +if (*pathp =='/' ) + pathp =kbasename (pathp); + rc =it (offset, pathp, data); + } +return rc; +} + + +/** * of_get_flat_dt_subnode_by_name - get the subnode by given name * * @node: the parent node
include/linux/of_fdt.h +5 -0
@@ -54,6 +54,11 @@ extern char __dtb_end[];extern int of_scan_flat_dt (int (*it)(unsigned long node,const char *uname,int depth,void *data),void *data); +extern int of_scan_flat_dt_subnodes (unsigned long node, +int (*it)(unsigned long node, +const char *uname, +void *data), +void *data);extern int of_get_flat_dt_subnode_by_name (unsigned long node,const char *uname); extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
Signature · 1 line
2.11.0