latest cpufeatures patch series
Subsystems (3)
Nicholas Piggin
reviewercover latest cpufeatures patch series
Hi,
This is the latest cpufeatures series for Linux. It should be close to merge now I hope, but another round of review would be good.
If we can merge the first minor patches and get those out of the way it would be helpful.
Thanks,
Nick
A message that is not in the archive (sent off-list or not yet received): 20170405123706.6081-1-npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
PATCH 2/3 of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Introduce primitives for FDT parsing. These will be used for powerpc cpufeatures node scanning, which has quite complex structure but should be processed early.
--- drivers/of/fdt.c | 39 +++++++++++++++++++++++++++++++++++++++ include/linux/of_fdt.h | 6 ++++++ 2 files changed, 45 insertions(+)
drivers/of/fdt.c +39 -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
@@ -812,6 +843,14 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)return of_fdt_match (initial_boot_params, node, compat); } +/** +* of_get_flat_dt_prop - Given a node in the flat blob, return the phandle +*/ +uint32_t __init of_get_flat_dt_phandle (unsigned long node) +{ +return fdt_get_phandle (initial_boot_params, node); +} +struct fdt_scan_status {const char *name;int namelen;
include/linux/of_fdt.h +6 -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,
@@ -62,6 +67,7 @@ extern int of_flat_dt_is_compatible(unsigned long node, const char *name);extern int of_flat_dt_match (unsigned long node,const char *const *matches);extern unsigned long of_get_flat_dt_root (void );extern int of_get_flat_dt_size (void ); +extern uint32_t of_get_flat_dt_phandle (unsigned long node);extern int early_init_dt_scan_chosen (unsigned long node,const char *uname,int depth,void *data);
Signature · 6 lines
2.11.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAL_JsqK4zbACwWVb-rsrvBb4hjBCexrqKRKrzSiZrZH5w=bKqQ@mail.gmail.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20170406003251.533e2845-a5aMA/[email protected]
Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Quoted 11 lines · Nicholas Piggin
Quoted 6 lines · On Wed, 5 Apr 2017 08:35:06 -0500 Rob Herring…
Quoted 3 lines · Nicholas Piggin
Introduce primitives for FDT parsing. These will be used for powerpc cpufeatures node scanning, which has quite complex structure but should be processed early.
Have you looked at unflattening the FDT earlier?
Hi, thanks for taking a look. Did you mean to trim the cc list?
Ugg, no. I've added everyone back.
Quoted 3 lines
It may be possible but I'd like to avoid it if we can. There might turn out to be some errata or feature that requires early setup. And the current cpu feature parsing code does it with flat dt.
Well, I'd like to avoid expanding usage of flat DT parsing in the kernel. But you could just put this function into arch/powerpc and I'd never see it, but I like that even less. Mainly, I just wanted to raise the point.
Your argument works until you need that setup in assembly code, then you are in the situation that you need to either handle the setup in bootloader/firmware or have an simple way to determine that condition.
Rob
Quoted 54 lines
Quoted 29 lines
Quoted 29 lines
Signed-off-by Nicholas Piggin <[email protected]>--- drivers/of/fdt.c | 39 +++++++++++++++++++++++++++++++++++++++ include/linux/of_fdt.h | 6 ++++++ 2 files changed, 45 insertions(+)drivers/of/fdt.c +14
-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;Quoted 8 lines
drivers/of/fdt.c int __init of_scan_flat_dt(int (*it)(unsigned long node, · line 776
Quoted 6 lines
drivers/of/fdt.c +6
-0+int offset, rc =0 ; + + offset = node; +for (offset =fdt_first_subnode (blob, offset); + offset >=0 && !rc; + offset =fdt_next_subnode (blob, offset)) {
fdt_for_each_subnode()Got it.
Quoted 10 lines
drivers/of/fdt.c int __init of_scan_flat_dt(int (*it)(unsigned long node, · line 780
Quoted 5 lines
drivers/of/fdt.c +4
-0+ + pathp =fdt_get_name (blob, offset,NULL ); +if (*pathp =='/' ) + pathp =kbasename (pathp);Seems a bit odd that you parse the name in this function. Perhaps the caller should do that, or if you want subnodes matching a certain name, then do the matching here. But you didn't copy me on the rest of the series, so I don't know how you are using this.
Hmm, it was a while since writing that part. I guess I just copied
of_scan_flat_dtinterface.
Quoted 8 lines
Caller is in this patch:
https://patchwork.ozlabs.org/patch/747262/
I'll include you in subsequent post if you prefer.
Thanks,
Nick
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAL_JsqLEvjb8S-+-JEa4ALHeCWHiR1A_4ur9kd3pBRJaFYWVKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Quoted 8 lines · Rob Herring
Well, I'd like to avoid expanding usage of flat DT parsing in the kernel. But you could just put this function into
arch/powerpcand I'd never see it, but I like that even less. Mainly, I just wanted to raise the point.Your argument works until you need that setup in assembly code, then you are in the situation that you need to either handle the setup in bootloader/firmware or have an simple way to determine that condition.
The main issue is that changing that is a very very invasive change in an extremely fragile and rather nasty area of code shared by 32 and 64- bit for which we don't even have easy access to all the machines to test with anymore :)
It's probably not impossible, but it would delay the new cpu feature stuff that Nick is making by a lot, probably monthes, making it nearly impossible to get back into distros etc...
So while it might be something to consider, I would definitely keep that as a separate unit of work to do later.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 1491425881.4166.90.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org
Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Quoted 15 lines · On Thu, 06 Apr 2017 06:58:01 +1000 Benjamin Herrenschmidt…
Quoted 8 lines · Rob Herring
Well, I'd like to avoid expanding usage of flat DT parsing in the kernel. But you could just put this function into
arch/powerpcand I'd never see it, but I like that even less. Mainly, I just wanted to raise the point.Your argument works until you need that setup in assembly code, then you are in the situation that you need to either handle the setup in bootloader/firmware or have an simple way to determine that condition.
The main issue is that changing that is a very very invasive change in an extremely fragile and rather nasty area of code shared by 32 and 64- bit for which we don't even have easy access to all the machines to test with anymore :)
Quoted 6 lines
It's probably not impossible, but it would delay the new cpu feature stuff that Nick is making by a lot, probably monthes, making it nearly impossible to get back into distros etc...
So while it might be something to consider, I would definitely keep that as a separate unit of work to do later.
Yeah, it's no longer a "drop in" replacement for existing features testing if we do this, which makes it hard to backport too (we will need this for compatibility with future firmware, so it will have to go into distro kernels.)
Given that it's quite a small addition to of/fdt code, hopefully that gives you a reasonable justification to accept it.
If you prefer not to, that's okay, but I think we would have to carry it in arch/powerpc at least for a time, because of the schedule we're working to for POWER9 enablement. As a longer term item I agree with you and Ben, it would be worth considering unflattening earlier.
Thanks,
Nick
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170406103829.67d462e1-a5aMA/[email protected]
Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Quoted 30 lines · Nicholas Piggin
Quoted 15 lines · On Thu, 06 Apr 2017 06:58:01 +1000 Benjamin Herrenschmidt…
Quoted 8 lines · Rob Herring
Well, I'd like to avoid expanding usage of flat DT parsing in the kernel. But you could just put this function into
arch/powerpcand I'd never see it, but I like that even less. Mainly, I just wanted to raise the point.Your argument works until you need that setup in assembly code, then you are in the situation that you need to either handle the setup in bootloader/firmware or have an simple way to determine that condition.
The main issue is that changing that is a very very invasive change in an extremely fragile and rather nasty area of code shared by 32 and 64- bit for which we don't even have easy access to all the machines to test with anymore :)
Quoted 6 lines
It's probably not impossible, but it would delay the new cpu feature stuff that Nick is making by a lot, probably monthes, making it nearly impossible to get back into distros etc...
So while it might be something to consider, I would definitely keep that as a separate unit of work to do later.
Yeah, it's no longer a "drop in" replacement for existing features testing if we do this, which makes it hard to backport too (we will need this for compatibility with future firmware, so it will have to go into distro kernels.)
Quoted 7 lines
Given that it's quite a small addition to of/fdt code, hopefully that gives you a reasonable justification to accept it.
If you prefer not to, that's okay, but I think we would have to carry it in
arch/powerpcat least for a time, because of the schedule we're working to for POWER9 enablement. As a longer term item I agree with you and Ben, it would be worth considering unflattening earlier.
As I mentioned, keeping it in arch/powerpc I like even less. So this is fine.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAL_JsqKuomE41grhAvjFxkFbS4A3-M_TK8gP8FU=HdDpQ3TTkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Quoted 10 lines · On Thu, 6 Apr 2017 09:09:41 -0500 Rob Herring…
Quoted 7 lines · Nicholas Piggin
Given that it's quite a small addition to of/fdt code, hopefully that gives you a reasonable justification to accept it.
If you prefer not to, that's okay, but I think we would have to carry it in
arch/powerpcat least for a time, because of the schedule we're working to for POWER9 enablement. As a longer term item I agree with you and Ben, it would be worth considering unflattening earlier.As I mentioned, keeping it in
arch/powerpcI like even less. So this is fine.
Here is the patch with the change you suggested. Can I add your ack and send it via the powerpc tree with the change that uses these interfaces?
Thanks,
Nick
--- drivers/of/fdt.c | 38 ++++++++++++++++++++++++++++++++++++++ include/linux/of_fdt.h | 6 ++++++ 2 files changed, 44 insertions(+)
drivers/of/fdt.c +38 -0
@@ -754,6 +754,36 @@ 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 parent, +int (*it)(unsigned long node, +const char *uname, +void *data), +void *data) +{ +const void *blob = initial_boot_params; +int node; + +fdt_for_each_subnode (node, blob, parent) { +const char *pathp; +int rc; + + pathp =fdt_get_name (blob, node,NULL ); +if (*pathp =='/' ) + pathp =kbasename (pathp); + rc =it (node, pathp, data); +if (rc) +return rc; + } +return 0 ; +} + +/** * of_get_flat_dt_subnode_by_name - get the subnode by given name * * @node: the parent node
@@ -812,6 +842,14 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)return of_fdt_match (initial_boot_params, node, compat); } +/** +* of_get_flat_dt_prop - Given a node in the flat blob, return the phandle +*/ +uint32_t __init of_get_flat_dt_phandle (unsigned long node) +{ +return fdt_get_phandle (initial_boot_params, node); +} +struct fdt_scan_status {const char *name;int namelen;
include/linux/of_fdt.h +6 -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,
@@ -62,6 +67,7 @@ extern int of_flat_dt_is_compatible(unsigned long node, const char *name);extern int of_flat_dt_match (unsigned long node,const char *const *matches);extern unsigned long of_get_flat_dt_root (void );extern int of_get_flat_dt_size (void ); +extern uint32_t of_get_flat_dt_phandle (unsigned long node);extern int early_init_dt_scan_chosen (unsigned long node,const char *uname,int depth,void *data);
Signature · 6 lines
2.11.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170410154348.051e7a34-a5aMA/[email protected]
Rob Herring
Acked-byRe: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Quoted 12 lines · Nicholas Piggin
Quoted 9 lines · On Thu, 6 Apr 2017 09:09:41 -0500 Rob Herring…
Quoted 7 lines · Nicholas Piggin
Given that it's quite a small addition to of/fdt code, hopefully that gives you a reasonable justification to accept it.
If you prefer not to, that's okay, but I think we would have to carry it in
arch/powerpcat least for a time, because of the schedule we're working to for POWER9 enablement. As a longer term item I agree with you and Ben, it would be worth considering unflattening earlier.
Quoted 5 lines
Quoted 1 line
As I mentioned, keeping it in
arch/powerpcI like even less. So this is fine.Here is the patch with the change you suggested. Can I add your ack and send it via the powerpc tree with the change that uses these interfaces?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
In reply to a message not in the archiveQuoted 19 lines · Rob Herring
Quoted 11 lines · Nicholas Piggin
Quoted 6 lines · On Wed, 5 Apr 2017 08:35:06 -0500 Rob Herring…
Quoted 3 lines · Nicholas Piggin
Introduce primitives for FDT parsing. These will be used for powerpc cpufeatures node scanning, which has quite complex structure but should be processed early.
Have you looked at unflattening the FDT earlier?
Hi, thanks for taking a look. Did you mean to trim the cc list?
Ugg, no. I've added everyone back.
Quoted 3 lines
It may be possible but I'd like to avoid it if we can. There might turn out to be some errata or feature that requires early setup. And the current cpu feature parsing code does it with flat dt.
Quoted 8 lines
Well, I'd like to avoid expanding usage of flat DT parsing in the kernel. But you could just put this function into
arch/powerpcand I'd never see it, but I like that even less. Mainly, I just wanted to raise the point.Your argument works until you need that setup in assembly code, then you are in the situation that you need to either handle the setup in bootloader/firmware or have an simple way to determine that condition.
Where Nick does this FDT parsing is literally the first C code that runs in the kernel. The MMU is off, we don't even know how much memory we have, or where it is.
So it's basically impossible to do the unflattening earlier. What we could do is move the CPU feature setup *later*.
As Ben & Nick said that would be a pretty intrusive change, and definitely not something we want to do now.
What we could probably do is split some of the flat tree parsing, so that we discover memory, even just some of it, then unflatten, and then do more setup using the unflattened tree.
But that will require a lot of delicate work. So we'd definitely like to do that separately from this series.
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Nicholas Piggin
reviewerPATCH 1/3 powerpc/64s: POWER9 no LPCR VRMASD bits
In reply to Nicholas PigginPOWER9/ISAv3 has no VRMASD field in LPCR. Don't set reserved bits.
--- arch/powerpc/kernel/cpu_setup_power.S | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-)
arch/powerpc/kernel/cpu_setup_power.S +12 -9
@@ -29,7 +29,7 @@ _GLOBAL(__setup_cpu_power7) li r0,0 mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_tlb_power7 mtlr r11 blr
@@ -42,7 +42,7 @@ _GLOBAL(__restore_cpu_power7) li r0,0 mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_tlb_power7 mtlr r11 blr
@@ -59,7 +59,7 @@ _GLOBAL(__setup_cpu_power8) mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR ori r3, r3, LPCR_PECEDH - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_HFSCR bl __init_tlb_power8 bl __init_PMU_HV
@@ -80,7 +80,7 @@ _GLOBAL(__restore_cpu_power8) mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR ori r3, r3, LPCR_PECEDH - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_HFSCR bl __init_tlb_power8 bl __init_PMU_HV
@@ -103,7 +103,7 @@ _GLOBAL(__setup_cpu_power9) or r3, r3, r4 LOAD_REG_IMMEDIATE(r4, LPCR_UPRT | LPCR_HR) andc r3, r3, r4 - bl __init_LPCR + bl __init_LPCR_ISA300 bl __init_HFSCR bl __init_tlb_power9 bl __init_PMU_HV
@@ -126,7 +126,7 @@ _GLOBAL(__restore_cpu_power9) or r3, r3, r4 LOAD_REG_IMMEDIATE(r4, LPCR_UPRT | LPCR_HR) andc r3, r3, r4 - bl __init_LPCR + bl __init_LPCR_ISA300 bl __init_HFSCR bl __init_tlb_power9 bl __init_PMU_HV
@@ -144,7 +144,7 @@ __init_hvmode_206: std r5,CPU_SPEC_FEATURES(r4) blr -__init_LPCR: +__init_LPCR_ISA206: /* Setup a sane LPCR: * Called with initial LPCR in R3 *
@@ -157,6 +157,11 @@ __init_LPCR: * * Other bits untouched for now */ + li r5,0x10 + rldimi r3,r5, LPCR_VRMASD_SH, 64-LPCR_VRMASD_SH-5 + + /* POWER9 has no VRMASD */ +__init_LPCR_ISA300: li r5,1 rldimi r3,r5, LPCR_LPES_SH, 64-LPCR_LPES_SH-2 ori r3,r3,(LPCR_PECE0|LPCR_PECE1|LPCR_PECE2)
@@ -165,8 +170,6 @@ __init_LPCR: clrrdi r3,r3,1 /* clear HDICE */ li r5,4 rldimi r3,r5, LPCR_VC_SH, 0 - li r5,0x10 - rldimi r3,r5, LPCR_VRMASD_SH, 64-LPCR_VRMASD_SH-5 mtspr SPRN_LPCR,r3 isync blr
Signature · 1 line
2.11.0
Nicholas Piggin
reviewerPATCH 3/3 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.
---
Since last post:
- Update to v3.0B ISA.
- Removed PVR tests for MCE and PMU, and add specific features for those.
- Fixed CPU state restore.
- Changed dt bit number specification for hfscr/fscr/aux to LSB0.
- Broke the of/fdt changes into another patch.
- Added a proper dependency checker.
- Resolved most of the register/feature bits differences, made a patch for VRMASD.
- Didn't think of a better name.
Before/after this patch differences:
- PPC_FEATURE2_EBB is set independent of PMU init. EBB facility is theoretically more general than PMU, I don't think this should be a problem?
POWER8 (all mambo issues):
- HFSCR bit 54 and 57 are now clear (mambo sets at init)
- PMAO_BUG is set. This is due to mambo setting architected POWER8 mode and POWER8E PVR. Current kernels lose PMAO_BUG bit.
- CI_LARGE_PAGE is now set (mambo boot does not set).
POWER9
- Privileged Doorbell Exit Enable is set in LPCR.
--- .../devicetree/bindings/powerpc/cpufeatures.txt | 264 +++++++++ arch/powerpc/include/asm/cpu_has_feature.h | 4 +- arch/powerpc/include/asm/cpufeatures.h | 58 ++ arch/powerpc/include/asm/cputable.h | 1 + arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/cpufeatures.c | 618 +++++++++++++++++++++ arch/powerpc/kernel/cputable.c | 14 +- arch/powerpc/kernel/prom.c | 297 +++++++++- arch/powerpc/kernel/setup-common.c | 2 +- arch/powerpc/kernel/setup_64.c | 21 +- 10 files changed, 1261 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 +264 -0
@@ -0,0 +1,264 @@ +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 numbers are LSB0 + 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: HFSCR bit position (LSB0) + + 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: FSCR bit position (LSB0) + + 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: AUX vector bit position (LSB0) + + 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 +58 -0
58 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/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 +618 -0
618 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 */
@@ -2179,7 +2181,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 +285 -12
337 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>
@@ -262,11 +263,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 );
@@ -280,6 +292,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
@@ -532,6 +546,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" ); }
Signature · 1 line
2.11.0
kbuild test robot
build botRe: [PATCH 3/3] powerpc/64s: cpufeatures: add initial implementation for cpufeatures
reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross…
Hi Nicholas,
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/latest-cpufeatures-patch-series/20170406-140710 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: powerpc-allnoconfig (attached as .config) compiler: powerpc-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/kernel/prom.c: In function 'early_init_dt_scan_cpufeatures':
>> arch/powerpc/kernel/prom.c:508:2: error: 'has_cpufeatures_node' undeclared (first use in this function)
has_cpufeatures_node = 1;
^~~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/prom.c:508:2: note: each undeclared identifier is reported only once for each function it appears in
arch/powerpc/kernel/prom.c: In function 'early_init_dt_scan_cpus':
arch/powerpc/kernel/prom.c:631:7: error: 'has_cpufeatures_node' undeclared (first use in this function)
if (!has_cpufeatures_node) {
^~~~~~~~~~~~~~~~~~~~vim +/has_cpufeatures_node +508 arch/powerpc/kernel/prom.c
502 printk("cpu-features node has missing property \"isa\"\n");
503 return 0;
504 }
505
506 isa = be32_to_cpup(prop);
507
> 508 has_cpufeatures_node = 1;
509
510 /* Count and allocate space for cpu features */
511 of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Nicholas Piggin
reviewerRe: [PATCH 3/3] powerpc/64s: cpufeatures: add initial implementation for cpufeatures
In reply to Nicholas PigginQuoted 12 lines · On Wed, 5 Apr 2017 22:37:06 +1000 Nicholas Piggin <[email protected]> wrote:
The /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.
Quoted 11 lines
---
Since last post:
- Update to v3.0B ISA.
- Removed PVR tests for MCE and PMU, and add specific features for those.
- Fixed CPU state restore.
- Changed dt bit number specification for hfscr/fscr/aux to LSB0.
- Broke the of/fdt changes into another patch.
- Added a proper dependency checker.
- Resolved most of the register/feature bits differences, made a patch for VRMASD.
- Didn't think of a better name.
Here's the latest version, which has some build and config cleanups and updated with some more optional features.
Since last post:
- Fixed 32-bit build
- Made configurable on Book3s (for now)
- Updated base set of features
--- .../devicetree/bindings/powerpc/cpufeatures.txt | 264 +++++++++ arch/powerpc/Kconfig | 16 + arch/powerpc/include/asm/cpu_has_feature.h | 4 +- arch/powerpc/include/asm/cpufeatures.h | 57 ++ arch/powerpc/include/asm/cputable.h | 1 + arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/cpufeatures.c | 625 +++++++++++++++++++++ arch/powerpc/kernel/cputable.c | 14 +- arch/powerpc/kernel/prom.c | 307 +++++++++- arch/powerpc/kernel/setup-common.c | 2 +- arch/powerpc/kernel/setup_64.c | 15 +- 11 files changed, 1288 insertions(+), 18 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 +264 -0
@@ -0,0 +1,264 @@ +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 numbers are LSB0 + 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: HFSCR bit position (LSB0) + + 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: FSCR bit position (LSB0) + + 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: AUX vector bit position (LSB0) + + 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/Kconfig +16 -0
@@ -330,6 +330,22 @@ source "arch/powerpc/platforms/Kconfig" menu "Kernel options" +config PPC_CPUFEATURES_DT + bool "cpufeatures cpu setup and device tree support (UNSTABLE)" + depends on PPC_BOOK3S_64 + default n + ---help--- + cpufeatures is a proposed new device tree binding for describing + CPU compatibility and features. Saying y here will attempt to use + cpufeatures binding if the firmware provides it. This binding is + not stable, so a kernel built with this option may not function + properly with future firmware. + +config PPC_CPUFEATURES_ENABLE_UNKNOWN + bool "cpufeatures pass through unknown features to guest/userspace" + depends on PPC_CPUFEATURES_DT + default y + config HIGHMEM bool "High memory support" depends on PPC32
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 +57 -0
57 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/kernel/Makefile +1 -0
@@ -58,6 +58,7 @@ obj-$(CONFIG_PPC_RTAS) += rtas.o rtas-rtc.o $(rtaspci-y-y) obj-$(CONFIG_PPC_RTAS_DAEMON) += rtasd.o obj-$(CONFIG_RTAS_FLASH) += rtas_flash.o obj-$(CONFIG_RTAS_PROC) += rtas-proc.o +obj-$(CONFIG_PPC_CPUFEATURES_DT) += cpufeatures.o obj-$(CONFIG_EEH) += eeh.o eeh_pe.o eeh_dev.o eeh_cache.o \ eeh_driver.o eeh_event.o eeh_sysfs.o obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
arch/powerpc/kernel/cpufeatures.c new file +625 -0
625 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 */
@@ -2179,7 +2181,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 +295 -12
341 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 +14 -1
@@ -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>
@@ -274,8 +275,17 @@ void __init early_setup(unsigned long dt_ptr)/* -------- printk is _NOT_ safe to use here ! ------- */ -/* Identify CPU type */ +#ifdef CONFIG_PPC_CPUFEATURES_DT +/* Setup flat device-tree pointer */ + initial_boot_params =__va (dt_ptr); +if (early_init_devtree_check_cpu_features_exists ()) +cpufeatures_setup_cpu (); +else +/* Legacy table-based approach when /cpus/features is missing */ +identify_cpu (0 ,mfspr (SPRN_PVR )); +#else identify_cpu (0 ,mfspr (SPRN_PVR )); +#endif /* Assume we're on cpu 0 for now. Don't write to the paca yet! */ initialise_paca (&boot_paca,0 );
@@ -541,6 +551,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" ); }
Signature · 1 line
2.11.0