On Thu, Dec 09, 2021 at 10:52:03PM +0530, Sumit Gupta wrote: > Add device-tree binding documentation to represent CBB2.0 (Control > Backbone) error handling driver. The driver prints debug information > about failed transaction on receiving interrupt from CBB2.0. > > Signed-off-by: Sumit Gupta <sumitg@xxxxxxxxxx> > --- > .../arm/tegra/nvidia,tegra234-cbb.yaml | 80 +++++++++++++++++++ > 1 file changed, 80 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml > > diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml > new file mode 100644 > index 000000000000..ad8177255e6c > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml > @@ -0,0 +1,80 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > + > +$id: "http://devicetree.org/schemas/arm/tegra/tegra23_cbb.yaml#"; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > + > +title: NVIDIA Tegra CBB2.0 Error handling driver device tree bindings > + > +maintainers: > + - Sumit Gupta <sumitg@xxxxxxxxxx> > + > +description: |+ > + Control Backbone (CBB) comprises of the physical path from an > + initiator to a target's register configuration space. > + CBB2.0 consists of multiple sub-blocks connected to each other > + to create a topology. > + Tegra234 SOC has different fabrics based on CBB2.0 architecture > + which include cluster fabrics BPMP, AON, PSC, SCE, RCE, DCE, FSI > + and "CBB central fabric". > + > + In CBB2.0, each initiator which can issue transactions connects to > + a Root Master Node (MN) before it connects to any other element of > + the fabric. Each Root MN contains a Error Monitor (EM) which detects > + and logs error. Interrupts from various EM blocks are collated by > + Error Notifier (EN) which is per fabric and presents a single > + interrupt from fabric to the SOC interrupt controller. > + > + The driver handles errors from CBB due to illegal register accesses > + and prints debug information about failed transaction on receiving > + the interrupt from EN. Debug information includes Error Code, Error > + Description, MasterID, Fabric, SlaveID, Address, Cache, Protection, > + Security Group etc on receiving error notification. > + > + If the Error Response Disable (ERD) is set/enabled for an initiator, > + then SError or Data abort exception error response is masked and an > + interrupt is used for reporting errors due to illegal accesses from > + that initiator. The value returned on read failures is '0xFFFFFFFF' > + for compatibility with PCIE. > + > +properties: > + $nodename: > + pattern: "^[a-f]+-en@[0-9a-f]+$" > + > + compatible: > + enum: > + - nvidia,tegra234-aon-fabric > + - nvidia,tegra234-bpmp-fabric > + - nvidia,tegra234-cbb-fabric > + - nvidia,tegra234-dce-fabric > + - nvidia,tegra234-rce-fabric > + - nvidia,tegra234-sce-fabric > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + items: > + - description: secure interrupt from error notifier. > + > + nvidia,err-notifier-base: > + description: address of error notifier inside a fabric. > + > + nvidia,off-mask-erd: > + description: offset of register having ERD bit. I was wondering about these two properties. Do we really need them? I see that they are set on a per-SoC basic and they only differ between the various fabrics. If they don't need to be configured on a per-board basis, then I don't think we need to specify these explicitly. Instead I think we could derive them from the compatible string. Thierry
Attachment:
signature.asc
Description: PGP signature
