On Mon, Dec 30, 2013 at 08:14:15PM +0000, 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.pieralisi@xxxxxxx> > Cc: Mark Rutland <mark.rutland@xxxxxxx> > Cc: Kumar Gala <galak@xxxxxxxxxxxxxx> > Cc: <devicetree@xxxxxxxxxxxxxxx> > Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx> > --- > 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
