| Message ID | 1408778588-3215-3-git-send-email-lho@apm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Aug 23, 2014 at 2:23 AM, Loc Ho <lho@apm.com> wrote: > This patch adds documentation for the APM X-Gene SoC EDAC DTS binding. > > Signed-off-by: Feng Kan <fkan@apm.com> > Signed-off-by: Loc Ho <lho@apm.com> > --- > .../devicetree/bindings/edac/apm-xgene-edac.txt | 83 ++++++++++++++++++++ > 1 files changed, 83 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt > > diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt > new file mode 100644 > index 0000000..ce8c30e > --- /dev/null > +++ b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt > @@ -0,0 +1,83 @@ > +* APM X-Gene SoC EDAC nodes > + > +EDAC nodes are defined to describe on-chip error detection and correction. > +There are four types of EDAC: EDAC is somewhat a Linux term which makes me suspicious. Is this really how the h/w is defined (i.e. I would find "EDAC" blocks in the h/w reference manual?)? > + > + memory controller - Memory controller > + PMD (L1/L2) - Processor module unit (PMD) L1/L2 cache > + L3 - CPU L3 cache > + SoC - SoC IP such as SATA, Ethernet, and etc > + > +The following section describes the memory controller DT node binding. > + > +Required properties: > +- compatible : Shall be "apm,xgene-edac-mc". This is only EDAC registers or the entire memory controller? If they are truly separate and only for EDAC, then it is fine. Otherwise, you should define the actual h/w block in DT and if a block needs to hook up to multiple drivers, then that is a Linux problem in which you should use drivers/mfd or drivers/soc. Similar question for the rest. Rob
Hi Rob, >> This patch adds documentation for the APM X-Gene SoC EDAC DTS binding. >> >> Signed-off-by: Feng Kan <fkan@apm.com> >> Signed-off-by: Loc Ho <lho@apm.com> >> --- >> .../devicetree/bindings/edac/apm-xgene-edac.txt | 83 ++++++++++++++++++++ >> 1 files changed, 83 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt >> >> diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt >> new file mode 100644 >> index 0000000..ce8c30e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt >> @@ -0,0 +1,83 @@ >> +* APM X-Gene SoC EDAC nodes >> + >> +EDAC nodes are defined to describe on-chip error detection and correction. >> +There are four types of EDAC: > > EDAC is somewhat a Linux term which makes me suspicious. Is this > really how the h/w is defined (i.e. I would find "EDAC" blocks in the > h/w reference manual?)? For memory controller and logically, there is such HW block in the hardware. Physical, the designer just arrange them in sequential order with other memory controller registers. For example, from offset 0x0 to 0xdc for controller registers and from 0xe0 to 0x118 for error enable and status registers, and etc. From the memory controller register used by error detection and correction, it is 0x110, 0x114, 0x314, 0x318, 0x31c, 0x320, and 0x324. All the 0x3xx repeated by an stride for 8 ranks. For the CPU L1/L2, it has an dedicate region for error configuration and status. For the L3, it is similar to the memory controller. it is arranged in sequential order. For the SoC error, it has its own page (region). > >> + >> + memory controller - Memory controller >> + PMD (L1/L2) - Processor module unit (PMD) L1/L2 cache >> + L3 - CPU L3 cache >> + SoC - SoC IP such as SATA, Ethernet, and etc >> + >> +The following section describes the memory controller DT node binding. >> + >> +Required properties: >> +- compatible : Shall be "apm,xgene-edac-mc". > > This is only EDAC registers or the entire memory controller? I explained them above comment. It span two segments and interleave with some controller registers. > If they > are truly separate and only for EDAC, then it is fine. For CPU L1/L2, yes. For other, they are arranged sequentially span two segments. > Otherwise, you > should define the actual h/w block in DT and if a block needs to hook > up to multiple drivers, then that is a Linux problem in which you > should use drivers/mfd or drivers/soc. At this point, there is no other driver that accesses them. Memory controllers are only access by FW. L1/l2 controller has it own region. L3 is only configured by FW. And SoC has its own page. I hope this provide enough info for suggestion if this still need to be changed. -Loc
diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt new file mode 100644 index 0000000..ce8c30e --- /dev/null +++ b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt @@ -0,0 +1,83 @@ +* APM X-Gene SoC EDAC nodes + +EDAC nodes are defined to describe on-chip error detection and correction. +There are four types of EDAC: + + memory controller - Memory controller + PMD (L1/L2) - Processor module unit (PMD) L1/L2 cache + L3 - CPU L3 cache + SoC - SoC IP such as SATA, Ethernet, and etc + +The following section describes the memory controller DT node binding. + +Required properties: +- compatible : Shall be "apm,xgene-edac-mc". +- reg : First resource shall be the PCP resource. + Second resource shall be the CSW resource. + Third resource shall be the MCB-A resource. + Fourth resource shall be the MCB-B resource. + Fifth resource shall be the MCU resource. +- interrupts : Interrupt-specifier for MCU error IRQ(s). + +The following section describes the L1/L2 DT node binding. + +- compatible : Shall be "apm,xgene-edac-pmd". +- reg : First resource shall be the PCP resource. + Second resource shall be the PMD resource. + Third resource shall be the PMD efuse resource. +- interrupts : Interrupt-specifier for PMD error IRQ(s). + +The following section describes the L3 DT node binding. + +- compatible : Shall be "apm,xgene-edac-l3". +- reg : First resource shall be the PCP resource. + Second resource shall be the L3 resource. +- interrupts : Interrupt-specifier for L3 error IRQ(s). + +The following section describes the SoC DT node binding. + +- compatible : Shall be "apm,xgene-edac-soc"". +- reg : First resource shall be the PCP resource. + Second resource shall be the SoC resource. + Third resource shall be the register bus resource. +- interrupts : Interrupt-specifier for SoC error IRQ(s). + +Example: + edacmc0: edacmc0@7e800000 { + compatible = "apm,xgene-edac-mc"; + reg = <0x0 0x78800000 0x0 0x1000>, + <0x0 0x7e200000 0x0 0x1000>, + <0x0 0x7e700000 0x0 0x1000>, + <0x0 0x7e720000 0x0 0x1000>, + <0x0 0x7e800000 0x0 0x1000>; + interrupts = <0x0 0x20 0x4>, + <0x0 0x21 0x4>; + }; + + edacl3: edacl3@7e600000 { + compatible = "apm,xgene-edac-l3"; + reg = <0x0 0x78800000 0x0 0x1000>, + <0x0 0x7e600000 0x0 0x1000>; + interrupts = <0x0 0x20 0x4>, + <0x0 0x21 0x4>; + }; + + edacpmd0: edacpmd0@7c000000 { + compatible = "apm,xgene-edac-pmd"; + reg = <0x0 0x78800000 0x0 0x1000>, + <0x0 0x7c000000 0x0 0x200000>, + <0x0 0x1054a000 0x0 0x10>; + interrupts = <0x0 0x20 0x4>, + <0x0 0x21 0x4>; + }; + + edacsoc: edacsoc@7e930000 { + compatible = "apm,xgene-edac-soc"; + reg = <0x0 0x78800000 0x0 0x1000>, + <0x0 0x7e930000 0x0 0x1000>, + <0x0 0x7e000000 0x0 0x1000>; + interrupts = <0x0 0x20 0x4>, + <0x0 0x21 0x4>, + <0x0 0x27 0x4>; + }; +