Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On Thu, Jan 09, 2014 at 08:52:21PM +, Stephen Boyd wrote: > On 01/08/14 02:05, Lorenzo Pieralisi wrote: > > On Tue, Jan 07, 2014 at 08:12:39PM +, Stephen Boyd wrote: > >> On 01/07, Lorenzo Pieralisi wrote: > >> > >>> I have a problem with the cache level definition, and in > >>> particular the numbering, ie what the level number represents. If we > >>> mean the cache level seen through the CLIDR and co., it is hard to use > >>> it for shared caches since the level seen by different CPUs can actually > >>> be different, or put it differently the level number might not be unique > >>> for > >>> a shared cache. I need to think about a proper way to sort this out. > >>> > >> Ok. I don't even use this property in my driver. All I really > >> need is the phandle from cpus pointing to the L2 and the > >> interrupts property in the L2 node. > >> > >> How do you want to proceed here? If your cache binding goes > >> through I would just need to add the interrupts part. Or you > >> could even add that part in the same patch, you could have my > >> signed-off-by for that. > > Ok, I will try to update the bindings with the interrupt part and copy > > you in, even though the level definition worries me a bit, it is an > > important property for power management and I need to find a proper > > solution before bindings can get accepted (basically the problem is: > > if different CPUs can see a cache at different levels as defined in the > > CLIDR we cannot describe a cache with a single cache level or put it > > differently, level can not represent the value in the CLIDR hence we > > need to describe it differently). > > Ok. I've dropped the cache part from this patch. I left the example as > is minus the cache-level attribute. > > Understanding how the cache-level value would be used might help. I > wonder if the cache-level can just be a number that describes the > largest value that the cache could be assigned. Then if you have > different CPUs seeing different levels of cache they can traverse from > their CPU node to the cache and count how many phandles they went through. Yes, that's one of the solutions I envisaged, and likely to be the one that I will put forward since it requires almost no changes. If we go that way cache-level becomes pretty useless though (which might be a good thing) and I do not like the implicit cache level obtained by counting phandles. Another option would be making cache-level a list and add a property "cache-level-affinity" as 1:1 map list of phandles to cpu-map node to define for each CPU the level at which that cache is mapped, somthing like the bindings described here for IRQ affinity: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162466.html I would say I tend to prefer the latter option, since I do not like relying on unwritten rules (implicit level numbering implied by phandle traversal) but I am open to suggestions. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On Thu, Jan 09, 2014 at 08:52:21PM +, Stephen Boyd wrote: On 01/08/14 02:05, Lorenzo Pieralisi wrote: On Tue, Jan 07, 2014 at 08:12:39PM +, Stephen Boyd wrote: On 01/07, Lorenzo Pieralisi wrote: I have a problem with the cache level definition, and in particular the numbering, ie what the level number represents. If we mean the cache level seen through the CLIDR and co., it is hard to use it for shared caches since the level seen by different CPUs can actually be different, or put it differently the level number might not be unique for a shared cache. I need to think about a proper way to sort this out. Ok. I don't even use this property in my driver. All I really need is the phandle from cpus pointing to the L2 and the interrupts property in the L2 node. How do you want to proceed here? If your cache binding goes through I would just need to add the interrupts part. Or you could even add that part in the same patch, you could have my signed-off-by for that. Ok, I will try to update the bindings with the interrupt part and copy you in, even though the level definition worries me a bit, it is an important property for power management and I need to find a proper solution before bindings can get accepted (basically the problem is: if different CPUs can see a cache at different levels as defined in the CLIDR we cannot describe a cache with a single cache level or put it differently, level can not represent the value in the CLIDR hence we need to describe it differently). Ok. I've dropped the cache part from this patch. I left the example as is minus the cache-level attribute. Understanding how the cache-level value would be used might help. I wonder if the cache-level can just be a number that describes the largest value that the cache could be assigned. Then if you have different CPUs seeing different levels of cache they can traverse from their CPU node to the cache and count how many phandles they went through. Yes, that's one of the solutions I envisaged, and likely to be the one that I will put forward since it requires almost no changes. If we go that way cache-level becomes pretty useless though (which might be a good thing) and I do not like the implicit cache level obtained by counting phandles. Another option would be making cache-level a list and add a property cache-level-affinity as 1:1 map list of phandles to cpu-map node to define for each CPU the level at which that cache is mapped, somthing like the bindings described here for IRQ affinity: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162466.html I would say I tend to prefer the latter option, since I do not like relying on unwritten rules (implicit level numbering implied by phandle traversal) but I am open to suggestions. Thanks, Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On 01/08/14 02:05, Lorenzo Pieralisi wrote: > On Tue, Jan 07, 2014 at 08:12:39PM +, Stephen Boyd wrote: >> On 01/07, Lorenzo Pieralisi wrote: >> >>> I have a problem with the cache level definition, and in >>> particular the numbering, ie what the level number represents. If we >>> mean the cache level seen through the CLIDR and co., it is hard to use >>> it for shared caches since the level seen by different CPUs can actually >>> be different, or put it differently the level number might not be unique for >>> a shared cache. I need to think about a proper way to sort this out. >>> >> Ok. I don't even use this property in my driver. All I really >> need is the phandle from cpus pointing to the L2 and the >> interrupts property in the L2 node. >> >> How do you want to proceed here? If your cache binding goes >> through I would just need to add the interrupts part. Or you >> could even add that part in the same patch, you could have my >> signed-off-by for that. > Ok, I will try to update the bindings with the interrupt part and copy > you in, even though the level definition worries me a bit, it is an > important property for power management and I need to find a proper > solution before bindings can get accepted (basically the problem is: > if different CPUs can see a cache at different levels as defined in the > CLIDR we cannot describe a cache with a single cache level or put it > differently, level can not represent the value in the CLIDR hence we > need to describe it differently). Ok. I've dropped the cache part from this patch. I left the example as is minus the cache-level attribute. Understanding how the cache-level value would be used might help. I wonder if the cache-level can just be a number that describes the largest value that the cache could be assigned. Then if you have different CPUs seeing different levels of cache they can traverse from their CPU node to the cache and count how many phandles they went through. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On 01/08/14 02:05, Lorenzo Pieralisi wrote: On Tue, Jan 07, 2014 at 08:12:39PM +, Stephen Boyd wrote: On 01/07, Lorenzo Pieralisi wrote: I have a problem with the cache level definition, and in particular the numbering, ie what the level number represents. If we mean the cache level seen through the CLIDR and co., it is hard to use it for shared caches since the level seen by different CPUs can actually be different, or put it differently the level number might not be unique for a shared cache. I need to think about a proper way to sort this out. Ok. I don't even use this property in my driver. All I really need is the phandle from cpus pointing to the L2 and the interrupts property in the L2 node. How do you want to proceed here? If your cache binding goes through I would just need to add the interrupts part. Or you could even add that part in the same patch, you could have my signed-off-by for that. Ok, I will try to update the bindings with the interrupt part and copy you in, even though the level definition worries me a bit, it is an important property for power management and I need to find a proper solution before bindings can get accepted (basically the problem is: if different CPUs can see a cache at different levels as defined in the CLIDR we cannot describe a cache with a single cache level or put it differently, level can not represent the value in the CLIDR hence we need to describe it differently). Ok. I've dropped the cache part from this patch. I left the example as is minus the cache-level attribute. Understanding how the cache-level value would be used might help. I wonder if the cache-level can just be a number that describes the largest value that the cache could be assigned. Then if you have different CPUs seeing different levels of cache they can traverse from their CPU node to the cache and count how many phandles they went through. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On Tue, Jan 07, 2014 at 08:12:39PM +, Stephen Boyd wrote: > On 01/07, Lorenzo Pieralisi wrote: > > > > Not sure this binding (cache node) belongs in cpus.txt > > > > I am working on defining cache bindings for ARM within the C-state > > standardization effort: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html > > Thanks I'll take a look. > > > > > > + > > > + Description: Describes a cache in an ARM based system > > > + > > > + - compatible > > > + Usage: required > > > + Value type: > > > + Definition: shall contain at least "cache" > > > > It is a bit vague, can't we just follow the ePAPR compatible definition ? > > See posting above. > > Hm.. I thought this did follow the ePAPR spec. I see 'compatible, > required, string, A standard property. The value shall include > the string "cache".' Looks the same? Sorry, my bad, you are right. > And I see 'cache-level, required, u32, Specifies the level in the > cache hierarchy. For example, a level 2 cache has a value of > <2>.' We need to define it properly for ARM, I am not sure we can use level as defined in CLIDR, I need to think more about this. > > > > > + > > > + - cache-level > > > + Usage: required > > > + Value type: > > > + Definition: level in the cache heirachy > > > > "hierarchy". > > Thanks. > > > I have a problem with the cache level definition, and in > > particular the numbering, ie what the level number represents. If we > > mean the cache level seen through the CLIDR and co., it is hard to use > > it for shared caches since the level seen by different CPUs can actually > > be different, or put it differently the level number might not be unique for > > a shared cache. I need to think about a proper way to sort this out. > > > > Ok. I don't even use this property in my driver. All I really > need is the phandle from cpus pointing to the L2 and the > interrupts property in the L2 node. > > How do you want to proceed here? If your cache binding goes > through I would just need to add the interrupts part. Or you > could even add that part in the same patch, you could have my > signed-off-by for that. Ok, I will try to update the bindings with the interrupt part and copy you in, even though the level definition worries me a bit, it is an important property for power management and I need to find a proper solution before bindings can get accepted (basically the problem is: if different CPUs can see a cache at different levels as defined in the CLIDR we cannot describe a cache with a single cache level or put it differently, level can not represent the value in the CLIDR hence we need to describe it differently). Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On Tue, Jan 07, 2014 at 08:12:39PM +, Stephen Boyd wrote: On 01/07, Lorenzo Pieralisi wrote: Not sure this binding (cache node) belongs in cpus.txt I am working on defining cache bindings for ARM within the C-state standardization effort: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html Thanks I'll take a look. + + Description: Describes a cache in an ARM based system + + - compatible + Usage: required + Value type: string + Definition: shall contain at least cache It is a bit vague, can't we just follow the ePAPR compatible definition ? See posting above. Hm.. I thought this did follow the ePAPR spec. I see 'compatible, required, string, A standard property. The value shall include the string cache.' Looks the same? Sorry, my bad, you are right. And I see 'cache-level, required, u32, Specifies the level in the cache hierarchy. For example, a level 2 cache has a value of 2.' We need to define it properly for ARM, I am not sure we can use level as defined in CLIDR, I need to think more about this. + + - cache-level + Usage: required + Value type: u32 + Definition: level in the cache heirachy hierarchy. Thanks. I have a problem with the cache level definition, and in particular the numbering, ie what the level number represents. If we mean the cache level seen through the CLIDR and co., it is hard to use it for shared caches since the level seen by different CPUs can actually be different, or put it differently the level number might not be unique for a shared cache. I need to think about a proper way to sort this out. Ok. I don't even use this property in my driver. All I really need is the phandle from cpus pointing to the L2 and the interrupts property in the L2 node. How do you want to proceed here? If your cache binding goes through I would just need to add the interrupts part. Or you could even add that part in the same patch, you could have my signed-off-by for that. Ok, I will try to update the bindings with the interrupt part and copy you in, even though the level definition worries me a bit, it is an important property for power management and I need to find a proper solution before bindings can get accepted (basically the problem is: if different CPUs can see a cache at different levels as defined in the CLIDR we cannot describe a cache with a single cache level or put it differently, level can not represent the value in the CLIDR hence we need to describe it differently). Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On 01/07, Lorenzo Pieralisi wrote: > > Not sure this binding (cache node) belongs in cpus.txt > > I am working on defining cache bindings for ARM within the C-state > standardization effort: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html Thanks I'll take a look. > > > + > > + Description: Describes a cache in an ARM based system > > + > > + - compatible > > + Usage: required > > + Value type: > > + Definition: shall contain at least "cache" > > It is a bit vague, can't we just follow the ePAPR compatible definition ? > See posting above. Hm.. I thought this did follow the ePAPR spec. I see 'compatible, required, string, A standard property. The value shall include the string "cache".' Looks the same? And I see 'cache-level, required, u32, Specifies the level in the cache hierarchy. For example, a level 2 cache has a value of <2>.' > > > + > > + - cache-level > > + Usage: required > > + Value type: > > + Definition: level in the cache heirachy > > "hierarchy". Thanks. > I have a problem with the cache level definition, and in > particular the numbering, ie what the level number represents. If we > mean the cache level seen through the CLIDR and co., it is hard to use > it for shared caches since the level seen by different CPUs can actually > be different, or put it differently the level number might not be unique for > a shared cache. I need to think about a proper way to sort this out. > Ok. I don't even use this property in my driver. All I really need is the phandle from cpus pointing to the L2 and the interrupts property in the L2 node. How do you want to proceed here? If your cache binding goes through I would just need to add the interrupts part. Or you could even add that part in the same patch, you could have my signed-off-by for that. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On Mon, Dec 30, 2013 at 08:14:15PM +, Stephen Boyd wrote: > The Krait L1/L2 error reporting device is made up of two > interrupts, one per-CPU interrupt for the L1 caches and one > interrupt for the L2 cache. > > Cc: Lorenzo Pieralisi > Cc: Mark Rutland > Cc: Kumar Gala > Cc: > Signed-off-by: Stephen Boyd > --- > Documentation/devicetree/bindings/arm/cpus.txt | 72 > ++ > 1 file changed, 72 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt > b/Documentation/devicetree/bindings/arm/cpus.txt > index 9130435..54de94b 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.txt > +++ b/Documentation/devicetree/bindings/arm/cpus.txt > @@ -191,6 +191,35 @@ nodes to be present and contain the properties described > below. > property identifying a 64-bit zero-initialised > memory location. > > + - interrupts > + Usage: required for cpus with compatible string "qcom,krait". > + Value type: > + Definition: L1/CPU error interrupt > + > + - next-level-cache > + Usage: optional > + Value type: > + Definition: phandle pointing to the next level cache > + > +- cache node Not sure this binding (cache node) belongs in cpus.txt I am working on defining cache bindings for ARM within the C-state standardization effort: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html > + > + Description: Describes a cache in an ARM based system > + > + - compatible > + Usage: required > + Value type: > + Definition: shall contain at least "cache" It is a bit vague, can't we just follow the ePAPR compatible definition ? See posting above. > + > + - cache-level > + Usage: required > + Value type: > + Definition: level in the cache heirachy "hierarchy". I have a problem with the cache level definition, and in particular the numbering, ie what the level number represents. If we mean the cache level seen through the CLIDR and co., it is hard to use it for shared caches since the level seen by different CPUs can actually be different, or put it differently the level number might not be unique for a shared cache. I need to think about a proper way to sort this out. Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On Mon, Dec 30, 2013 at 08:14:15PM +, Stephen Boyd wrote: The Krait L1/L2 error reporting device is made up of two interrupts, one per-CPU interrupt for the L1 caches and one interrupt for the L2 cache. Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org Signed-off-by: Stephen Boyd sb...@codeaurora.org --- Documentation/devicetree/bindings/arm/cpus.txt | 72 ++ 1 file changed, 72 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 9130435..54de94b 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -191,6 +191,35 @@ nodes to be present and contain the properties described below. property identifying a 64-bit zero-initialised memory location. + - interrupts + Usage: required for cpus with compatible string qcom,krait. + Value type: prop-encoded-array + Definition: L1/CPU error interrupt + + - next-level-cache + Usage: optional + Value type: phandle + Definition: phandle pointing to the next level cache + +- cache node Not sure this binding (cache node) belongs in cpus.txt I am working on defining cache bindings for ARM within the C-state standardization effort: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html + + Description: Describes a cache in an ARM based system + + - compatible + Usage: required + Value type: string + Definition: shall contain at least cache It is a bit vague, can't we just follow the ePAPR compatible definition ? See posting above. + + - cache-level + Usage: required + Value type: u32 + Definition: level in the cache heirachy hierarchy. I have a problem with the cache level definition, and in particular the numbering, ie what the level number represents. If we mean the cache level seen through the CLIDR and co., it is hard to use it for shared caches since the level seen by different CPUs can actually be different, or put it differently the level number might not be unique for a shared cache. I need to think about a proper way to sort this out. Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
On 01/07, Lorenzo Pieralisi wrote: Not sure this binding (cache node) belongs in cpus.txt I am working on defining cache bindings for ARM within the C-state standardization effort: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html Thanks I'll take a look. + + Description: Describes a cache in an ARM based system + + - compatible + Usage: required + Value type: string + Definition: shall contain at least cache It is a bit vague, can't we just follow the ePAPR compatible definition ? See posting above. Hm.. I thought this did follow the ePAPR spec. I see 'compatible, required, string, A standard property. The value shall include the string cache.' Looks the same? And I see 'cache-level, required, u32, Specifies the level in the cache hierarchy. For example, a level 2 cache has a value of 2.' + + - cache-level + Usage: required + Value type: u32 + Definition: level in the cache heirachy hierarchy. Thanks. I have a problem with the cache level definition, and in particular the numbering, ie what the level number represents. If we mean the cache level seen through the CLIDR and co., it is hard to use it for shared caches since the level seen by different CPUs can actually be different, or put it differently the level number might not be unique for a shared cache. I need to think about a proper way to sort this out. Ok. I don't even use this property in my driver. All I really need is the phandle from cpus pointing to the L2 and the interrupts property in the L2 node. How do you want to proceed here? If your cache binding goes through I would just need to add the interrupts part. Or you could even add that part in the same patch, you could have my signed-off-by for that. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
The Krait L1/L2 error reporting device is made up of two
interrupts, one per-CPU interrupt for the L1 caches and one
interrupt for the L2 cache.
Cc: Lorenzo Pieralisi
Cc: Mark Rutland
Cc: Kumar Gala
Cc:
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/arm/cpus.txt | 72 ++
1 file changed, 72 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 9130435..54de94b 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -191,6 +191,35 @@ nodes to be present and contain the properties described
below.
property identifying a 64-bit zero-initialised
memory location.
+ - interrupts
+ Usage: required for cpus with compatible string "qcom,krait".
+ Value type:
+ Definition: L1/CPU error interrupt
+
+ - next-level-cache
+ Usage: optional
+ Value type:
+ Definition: phandle pointing to the next level cache
+
+- cache node
+
+ Description: Describes a cache in an ARM based system
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: shall contain at least "cache"
+
+ - cache-level
+ Usage: required
+ Value type:
+ Definition: level in the cache heirachy
+
+ - interrupts
+ Usage: required for cpus with compatible string "qcom,krait"
+ Value type:
+ Definition: the L2 error interrupt
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
@@ -382,3 +411,46 @@ cpus {
cpu-release-addr = <0 0x2000>;
};
};
+
+
+Example 5 (Krait 32-bit system):
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <1 9 0xf04>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,krait";
+ reg = <0>;
+ next-level-cache = <>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "qcom,krait";
+ reg = <1>;
+ next-level-cache = <>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "qcom,krait";
+ reg = <2>;
+ next-level-cache = <>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "qcom,krait";
+ reg = <3>;
+ next-level-cache = <>;
+ };
+
+ L2: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ interrupts = <0 2 0x4>;
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
The Krait L1/L2 error reporting device is made up of two
interrupts, one per-CPU interrupt for the L1 caches and one
interrupt for the L2 cache.
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
Documentation/devicetree/bindings/arm/cpus.txt | 72 ++
1 file changed, 72 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 9130435..54de94b 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -191,6 +191,35 @@ nodes to be present and contain the properties described
below.
property identifying a 64-bit zero-initialised
memory location.
+ - interrupts
+ Usage: required for cpus with compatible string qcom,krait.
+ Value type: prop-encoded-array
+ Definition: L1/CPU error interrupt
+
+ - next-level-cache
+ Usage: optional
+ Value type: phandle
+ Definition: phandle pointing to the next level cache
+
+- cache node
+
+ Description: Describes a cache in an ARM based system
+
+ - compatible
+ Usage: required
+ Value type: string
+ Definition: shall contain at least cache
+
+ - cache-level
+ Usage: required
+ Value type: u32
+ Definition: level in the cache heirachy
+
+ - interrupts
+ Usage: required for cpus with compatible string qcom,krait
+ Value type: prop-encoded-array
+ Definition: the L2 error interrupt
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
@@ -382,3 +411,46 @@ cpus {
cpu-release-addr = 0 0x2000;
};
};
+
+
+Example 5 (Krait 32-bit system):
+
+cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts = 1 9 0xf04;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = qcom,krait;
+ reg = 0;
+ next-level-cache = L2;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = qcom,krait;
+ reg = 1;
+ next-level-cache = L2;
+ };
+
+ cpu@2 {
+ device_type = cpu;
+ compatible = qcom,krait;
+ reg = 2;
+ next-level-cache = L2;
+ };
+
+ cpu@3 {
+ device_type = cpu;
+ compatible = qcom,krait;
+ reg = 3;
+ next-level-cache = L2;
+ };
+
+ L2: l2-cache {
+ compatible = cache;
+ cache-level = 2;
+ interrupts = 0 2 0x4;
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
