| Message ID | 20220628054338.1631516-2-appana.durga.rao@xilinx.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | drivers: misc: Add support for TMR Manager and Inject IPs | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: > This commit adds documentation for Triple Modular Redundancy(TMR) Manager > IP. The Triple Modular Redundancy(TMR) Manager is responsible for handling > the TMR subsystem state, including fault detection and error recovery > provides soft error detection, correction and recovery features. > > Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> > --- > .../bindings/misc/xlnx,tmr-manager.yaml | 48 +++++++++++++++++++ This is not a misc device. Find appropriate subsystem for it. It's not EDAC, right? > 1 file changed, 48 insertions(+) > create mode 100644 Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml > > diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml > new file mode 100644 > index 000000000000..f6cb4d235981 > --- /dev/null > +++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml > @@ -0,0 +1,48 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/misc/xlnx,tmr-manager.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Xilinx TMR Microblaze Device Tree Bindings s/Device Tree Bindings// > + > +maintainers: > + - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> > + > +description: | > + The Triple Modular Redundancy(TMR) Manager is responsible for handling the > + TMR subsystem state, including fault detection and error recovery. The core > + is triplicated in each of the sub-blocks in the TMR subsystem, and provides > + majority voting of its internal state. > + > +properties: > + compatible: > + enum: > + - xlnx,tmr-manager-1.0 > + > + reg: > + maxItems: 1 > + > + xlnx,magic1: > + minimum: 0 > + maximum: 255 > + description: > + Magic number 1, When writing to the control register the first write data > + byte (bits 7:0) must match this value in order to have any effect on the > + nominal recovery function. Register values are usually not in the scope of bindings. We describe here hardware, not programming model, although in case of soft cores maybe it's a bit different. Anyway you need to describe the actual feature, not OS behavior. > + $ref: /schemas/types.yaml#/definitions/uint32 > + > +required: > + - compatible > + - reg > + - xlnx,magic1 > + > +additionalProperties: false > + > +examples: > + - | > + tmr-manager@44a10000 { Depending on what is this, you should use appropriate generic node name. > + compatible = "xlnx,tmr-manager-1.0"; > + reg = <0x44a10000 0x10000>; > + xlnx,magic1 = <0x46>; > + }; Best regards, Krzysztof
On 6/29/22 12:07, Krzysztof Kozlowski wrote: > On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: >> This commit adds documentation for Triple Modular Redundancy(TMR) Manager >> IP. The Triple Modular Redundancy(TMR) Manager is responsible for handling >> the TMR subsystem state, including fault detection and error recovery >> provides soft error detection, correction and recovery features. >> >> Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> >> --- >> .../bindings/misc/xlnx,tmr-manager.yaml | 48 +++++++++++++++++++ > > This is not a misc device. Find appropriate subsystem for it. It's not > EDAC, right? We were thinking where to put it but it is not EDAC driver. If you have better suggestion for subsystem please let us know. > >> 1 file changed, 48 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >> >> diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >> new file mode 100644 >> index 000000000000..f6cb4d235981 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >> @@ -0,0 +1,48 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/misc/xlnx,tmr-manager.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Xilinx TMR Microblaze Device Tree Bindings > > s/Device Tree Bindings// > >> + >> +maintainers: >> + - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> >> + >> +description: | >> + The Triple Modular Redundancy(TMR) Manager is responsible for handling the >> + TMR subsystem state, including fault detection and error recovery. The core >> + is triplicated in each of the sub-blocks in the TMR subsystem, and provides >> + majority voting of its internal state. >> + >> +properties: >> + compatible: >> + enum: >> + - xlnx,tmr-manager-1.0 >> + >> + reg: >> + maxItems: 1 >> + >> + xlnx,magic1: >> + minimum: 0 >> + maximum: 255 >> + description: >> + Magic number 1, When writing to the control register the first write data >> + byte (bits 7:0) must match this value in order to have any effect on the >> + nominal recovery function. > > Register values are usually not in the scope of bindings. We describe > here hardware, not programming model, although in case of soft cores > maybe it's a bit different. you need to setup this value for every instance in design tools and it is directly present in HW. It means this value is really describing HW. Thanks, Michal
On 29/06/2022 13:23, Michal Simek wrote: > > > On 6/29/22 12:07, Krzysztof Kozlowski wrote: >> On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: >>> This commit adds documentation for Triple Modular Redundancy(TMR) Manager >>> IP. The Triple Modular Redundancy(TMR) Manager is responsible for handling >>> the TMR subsystem state, including fault detection and error recovery >>> provides soft error detection, correction and recovery features. >>> >>> Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> >>> --- >>> .../bindings/misc/xlnx,tmr-manager.yaml | 48 +++++++++++++++++++ >> >> This is not a misc device. Find appropriate subsystem for it. It's not >> EDAC, right? > > We were thinking where to put it but it is not EDAC driver. > If you have better suggestion for subsystem please let us know. I don't know what's the device about. The description does not help: "TMR Manager is responsible for TMR subsystem state..." > >> >>> 1 file changed, 48 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >>> new file mode 100644 >>> index 000000000000..f6cb4d235981 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >>> @@ -0,0 +1,48 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/misc/xlnx,tmr-manager.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Xilinx TMR Microblaze Device Tree Bindings >> >> s/Device Tree Bindings// >> >>> + >>> +maintainers: >>> + - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> >>> + >>> +description: | >>> + The Triple Modular Redundancy(TMR) Manager is responsible for handling the >>> + TMR subsystem state, including fault detection and error recovery. The core >>> + is triplicated in each of the sub-blocks in the TMR subsystem, and provides >>> + majority voting of its internal state. >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - xlnx,tmr-manager-1.0 >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + xlnx,magic1: >>> + minimum: 0 >>> + maximum: 255 >>> + description: >>> + Magic number 1, When writing to the control register the first write data >>> + byte (bits 7:0) must match this value in order to have any effect on the >>> + nominal recovery function. >> >> Register values are usually not in the scope of bindings. We describe >> here hardware, not programming model, although in case of soft cores >> maybe it's a bit different. > > you need to setup this value for every instance in design tools and it is > directly present in HW. It means this value is really describing HW. OK, thanks for clarification. Best regards, Krzysztof
On 6/29/22 13:45, Krzysztof Kozlowski wrote: > On 29/06/2022 13:23, Michal Simek wrote: >> >> >> On 6/29/22 12:07, Krzysztof Kozlowski wrote: >>> On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: >>>> This commit adds documentation for Triple Modular Redundancy(TMR) Manager >>>> IP. The Triple Modular Redundancy(TMR) Manager is responsible for handling >>>> the TMR subsystem state, including fault detection and error recovery >>>> provides soft error detection, correction and recovery features. >>>> >>>> Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> >>>> --- >>>> .../bindings/misc/xlnx,tmr-manager.yaml | 48 +++++++++++++++++++ >>> >>> This is not a misc device. Find appropriate subsystem for it. It's not >>> EDAC, right? >> >> We were thinking where to put it but it is not EDAC driver. >> If you have better suggestion for subsystem please let us know. > > I don't know what's the device about. The description does not help: > > "TMR Manager is responsible for TMR subsystem state..." ok. let's improve commit message in v2. TMR - triple module redundancy. You design the system with one CPU which is default microblaze configuration with interrupt controller, timer and other IPs. And then say I want to do it triple redundant with all that voting, etc. If you want to get all details you can take a look at this guide https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/tmr/v1_0/pg268-tmr.pdf In short TMR manager is servicing all that 3 cores and making sure that they are all running in sync. If not it has capability recover the system. It means cpu gets to break handler (it is the part of microblaze series) and it restarts all cpus. And TMR inject driver is module which is capable to inject error to internal memory to cause the exception to exercise that recovery code. Kedar: Feel free to correct me or add more details. Thanks, Michal
Hi Krzysztof, Thanks for the review, please find response inline. On 29/06/22 3:37 pm, Krzysztof Kozlowski wrote: > On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: >> This commit adds documentation for Triple Modular Redundancy(TMR) Manager >> IP. The Triple Modular Redundancy(TMR) Manager is responsible for handling >> the TMR subsystem state, including fault detection and error recovery >> provides soft error detection, correction and recovery features. >> >> Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> >> --- >> .../bindings/misc/xlnx,tmr-manager.yaml | 48 +++++++++++++++++++ > > This is not a misc device. Find appropriate subsystem for it. It's not > EDAC, right? > >> 1 file changed, 48 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >> >> diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >> new file mode 100644 >> index 000000000000..f6cb4d235981 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml >> @@ -0,0 +1,48 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/misc/xlnx,tmr-manager.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Xilinx TMR Microblaze Device Tree Bindings > > s/Device Tree Bindings// Sure will fix in v2. > >> + >> +maintainers: >> + - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> >> + >> +description: | >> + The Triple Modular Redundancy(TMR) Manager is responsible for handling the >> + TMR subsystem state, including fault detection and error recovery. The core >> + is triplicated in each of the sub-blocks in the TMR subsystem, and provides >> + majority voting of its internal state. >> + >> +properties: >> + compatible: >> + enum: >> + - xlnx,tmr-manager-1.0 >> + >> + reg: >> + maxItems: 1 >> + >> + xlnx,magic1: >> + minimum: 0 >> + maximum: 255 >> + description: >> + Magic number 1, When writing to the control register the first write data >> + byte (bits 7:0) must match this value in order to have any effect on the >> + nominal recovery function. > > Register values are usually not in the scope of bindings. We describe > here hardware, not programming model, although in case of soft cores > maybe it's a bit different. > > Anyway you need to describe the actual feature, not OS behavior. Like Michal said for every instance of the hardware this value can be configured at vivado tool level. > >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + >> +required: >> + - compatible >> + - reg >> + - xlnx,magic1 >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + tmr-manager@44a10000 { > > Depending on what is this, you should use appropriate generic node name. Sure will fix in v2... Regards, Kedar. > >> + compatible = "xlnx,tmr-manager-1.0"; >> + reg = <0x44a10000 0x10000>; >> + xlnx,magic1 = <0x46>; >> + }; > > > Best regards, > Krzysztof
Hi, On 29/06/22 5:29 pm, Michal Simek wrote: > > > On 6/29/22 13:45, Krzysztof Kozlowski wrote: >> On 29/06/2022 13:23, Michal Simek wrote: >>> >>> >>> On 6/29/22 12:07, Krzysztof Kozlowski wrote: >>>> On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: >>>>> This commit adds documentation for Triple Modular Redundancy(TMR) >>>>> Manager >>>>> IP. The Triple Modular Redundancy(TMR) Manager is responsible for >>>>> handling >>>>> the TMR subsystem state, including fault detection and error recovery >>>>> provides soft error detection, correction and recovery features. >>>>> >>>>> Signed-off-by: Appana Durga Kedareswara rao >>>>> <appana.durga.rao@xilinx.com> >>>>> --- >>>>> .../bindings/misc/xlnx,tmr-manager.yaml | 48 >>>>> +++++++++++++++++++ >>>> >>>> This is not a misc device. Find appropriate subsystem for it. It's not >>>> EDAC, right? >>> >>> We were thinking where to put it but it is not EDAC driver. >>> If you have better suggestion for subsystem please let us know. >> >> I don't know what's the device about. The description does not help: >> >> "TMR Manager is responsible for TMR subsystem state..." > > ok. let's improve commit message in v2. Sure will improve the commit message in v2. > > TMR - triple module redundancy. > > You design the system with one CPU which is default microblaze > configuration with interrupt controller, timer and other IPs. > > And then say I want to do it triple redundant with all that voting, etc. > If you want to get all details you can take a look at this guide > > https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/tmr/v1_0/pg268-tmr.pdf > > > In short TMR manager is servicing all that 3 cores and making sure that > they are all running in sync. If not it has capability recover the > system. It means cpu gets to break handler (it is the part of microblaze > series) and it restarts all cpus. > > And TMR inject driver is module which is capable to inject error to > internal memory to cause the exception to exercise that recovery code. > > Kedar: Feel free to correct me or add more details. Thanks Michal for the detailed explanation. The Triple Modular Redundancy(TMR) subsystem has three Microblaze processor instances, If any one of the Microblaze processors goes to an unknown state due to fault injection break handler will get called, which in turn calls the tmr manager driver API to perform recovery. like Michal said TMR inject driver is capable of inject error to internal memory to cause fault in one the Microblaze processor @Krzysztof : please let me know if more information required about this TMR subsystem will provide. Regards, Kedar. > > Thanks, > Michal
On 29/06/2022 14:37, Rao, Appana Durga Kedareswara wrote: > Hi, > > > On 29/06/22 5:29 pm, Michal Simek wrote: >> >> >> On 6/29/22 13:45, Krzysztof Kozlowski wrote: >>> On 29/06/2022 13:23, Michal Simek wrote: >>>> >>>> >>>> On 6/29/22 12:07, Krzysztof Kozlowski wrote: >>>>> On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: >>>>>> This commit adds documentation for Triple Modular Redundancy(TMR) >>>>>> Manager >>>>>> IP. The Triple Modular Redundancy(TMR) Manager is responsible for >>>>>> handling >>>>>> the TMR subsystem state, including fault detection and error recovery >>>>>> provides soft error detection, correction and recovery features. >>>>>> >>>>>> Signed-off-by: Appana Durga Kedareswara rao >>>>>> <appana.durga.rao@xilinx.com> >>>>>> --- >>>>>> .../bindings/misc/xlnx,tmr-manager.yaml | 48 >>>>>> +++++++++++++++++++ >>>>> >>>>> This is not a misc device. Find appropriate subsystem for it. It's not >>>>> EDAC, right? >>>> >>>> We were thinking where to put it but it is not EDAC driver. >>>> If you have better suggestion for subsystem please let us know. >>> >>> I don't know what's the device about. The description does not help: >>> >>> "TMR Manager is responsible for TMR subsystem state..." >> >> ok. let's improve commit message in v2. > > Sure will improve the commit message in v2. >> >> TMR - triple module redundancy. >> >> You design the system with one CPU which is default microblaze >> configuration with interrupt controller, timer and other IPs. >> >> And then say I want to do it triple redundant with all that voting, etc. >> If you want to get all details you can take a look at this guide >> >> https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/tmr/v1_0/pg268-tmr.pdf >> >> >> In short TMR manager is servicing all that 3 cores and making sure that >> they are all running in sync. If not it has capability recover the >> system. It means cpu gets to break handler (it is the part of microblaze >> series) and it restarts all cpus. >> >> And TMR inject driver is module which is capable to inject error to >> internal memory to cause the exception to exercise that recovery code. >> >> Kedar: Feel free to correct me or add more details. > > Thanks Michal for the detailed explanation. > > The Triple Modular Redundancy(TMR) subsystem has three Microblaze > processor instances, If any one of the Microblaze processors goes to an > unknown state due to fault injection break handler will get called, > which in turn calls the tmr manager driver API to perform recovery. > like Michal said TMR inject driver is capable of inject error to > internal memory to cause fault in one the Microblaze processor > > @Krzysztof : please let me know if more information required about > this TMR subsystem will provide. Some features sound like watchdog. If it was ARM, I would suggest to put it under "soc". Is a term System-on-Chip applicable to Microblaze? Other option is to store it under microblaze (although for ARM and RISC-V this is actually discouraged in favor of soc). Best regards, Krzysztof
On 6/30/22 12:07, Krzysztof Kozlowski wrote: > On 29/06/2022 14:37, Rao, Appana Durga Kedareswara wrote: >> Hi, >> >> >> On 29/06/22 5:29 pm, Michal Simek wrote: >>> >>> >>> On 6/29/22 13:45, Krzysztof Kozlowski wrote: >>>> On 29/06/2022 13:23, Michal Simek wrote: >>>>> >>>>> >>>>> On 6/29/22 12:07, Krzysztof Kozlowski wrote: >>>>>> On 28/06/2022 07:43, Appana Durga Kedareswara rao wrote: >>>>>>> This commit adds documentation for Triple Modular Redundancy(TMR) >>>>>>> Manager >>>>>>> IP. The Triple Modular Redundancy(TMR) Manager is responsible for >>>>>>> handling >>>>>>> the TMR subsystem state, including fault detection and error recovery >>>>>>> provides soft error detection, correction and recovery features. >>>>>>> >>>>>>> Signed-off-by: Appana Durga Kedareswara rao >>>>>>> <appana.durga.rao@xilinx.com> >>>>>>> --- >>>>>>> .../bindings/misc/xlnx,tmr-manager.yaml | 48 >>>>>>> +++++++++++++++++++ >>>>>> >>>>>> This is not a misc device. Find appropriate subsystem for it. It's not >>>>>> EDAC, right? >>>>> >>>>> We were thinking where to put it but it is not EDAC driver. >>>>> If you have better suggestion for subsystem please let us know. >>>> >>>> I don't know what's the device about. The description does not help: >>>> >>>> "TMR Manager is responsible for TMR subsystem state..." >>> >>> ok. let's improve commit message in v2. >> >> Sure will improve the commit message in v2. >>> >>> TMR - triple module redundancy. >>> >>> You design the system with one CPU which is default microblaze >>> configuration with interrupt controller, timer and other IPs. >>> >>> And then say I want to do it triple redundant with all that voting, etc. >>> If you want to get all details you can take a look at this guide >>> >>> https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/tmr/v1_0/pg268-tmr.pdf >>> >>> >>> In short TMR manager is servicing all that 3 cores and making sure that >>> they are all running in sync. If not it has capability recover the >>> system. It means cpu gets to break handler (it is the part of microblaze >>> series) and it restarts all cpus. >>> >>> And TMR inject driver is module which is capable to inject error to >>> internal memory to cause the exception to exercise that recovery code. >>> >>> Kedar: Feel free to correct me or add more details. >> >> Thanks Michal for the detailed explanation. >> >> The Triple Modular Redundancy(TMR) subsystem has three Microblaze >> processor instances, If any one of the Microblaze processors goes to an >> unknown state due to fault injection break handler will get called, >> which in turn calls the tmr manager driver API to perform recovery. >> like Michal said TMR inject driver is capable of inject error to >> internal memory to cause fault in one the Microblaze processor >> >> @Krzysztof : please let me know if more information required about >> this TMR subsystem will provide. > > Some features sound like watchdog. watchdog needs to be keep alive which is not the case here. These systems are designed for safety or space applications and I am quite sure that there are going to be couple or regular watchdogs wired too. > If it was ARM, I would suggest to put > it under "soc". Is a term System-on-Chip applicable to Microblaze? I have never seen microblaze in connection to SOC. You can make SOC based on microblaze cpu (using hard cores) but in most cases microblaze as soft cpu is loaded to fpga or to programmable logic. > Other > option is to store it under microblaze (although for ARM and RISC-V this > is actually discouraged in favor of soc). Exactly. That was my main concern too that adding to microblaze is likely not the best location that's why we wanted to add it to different location. Thanks, Michal
diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml new file mode 100644 index 000000000000..f6cb4d235981 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/xlnx,tmr-manager.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx TMR Microblaze Device Tree Bindings + +maintainers: + - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> + +description: | + The Triple Modular Redundancy(TMR) Manager is responsible for handling the + TMR subsystem state, including fault detection and error recovery. The core + is triplicated in each of the sub-blocks in the TMR subsystem, and provides + majority voting of its internal state. + +properties: + compatible: + enum: + - xlnx,tmr-manager-1.0 + + reg: + maxItems: 1 + + xlnx,magic1: + minimum: 0 + maximum: 255 + description: + Magic number 1, When writing to the control register the first write data + byte (bits 7:0) must match this value in order to have any effect on the + nominal recovery function. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - xlnx,magic1 + +additionalProperties: false + +examples: + - | + tmr-manager@44a10000 { + compatible = "xlnx,tmr-manager-1.0"; + reg = <0x44a10000 0x10000>; + xlnx,magic1 = <0x46>; + };
This commit adds documentation for Triple Modular Redundancy(TMR) Manager IP. The Triple Modular Redundancy(TMR) Manager is responsible for handling the TMR subsystem state, including fault detection and error recovery provides soft error detection, correction and recovery features. Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> --- .../bindings/misc/xlnx,tmr-manager.yaml | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml