lkml.org 
[lkml]   [2021]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Patch Resend v1 5/8] dt-bindings: arm: tegra: Add NVIDIA Tegra234 CBB2.0 binding
From
Date
Hi Thierry,

> 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@nvidia.com>
>> ---
>> .../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@nvidia.com>
>> +
>> +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
The CBB 2.0 based fabric's error handling driver remains same across
different SOC's and their variants. Only these fields change.
e.g: "off-mask-erd" value is different for T23x SOC variants.
"err-notifier-base" also changed multiple times during simulator stage.
So, keeping them in DT to avoid changing the driver code for different
variants of an SOC and to change them during bring up stages with DT
change only.

>
> Thierry
>

\
 
 \ /
  Last update: 2021-12-16 16:07    [W:0.165 / U:1.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site