On 05/05/22 19:34, Rob Herring wrote:
External email: Use caution opening links or attachments
On Thu, Apr 07, 2022 at 11:54:16AM +0530, Sumit Gupta wrote:
Add device-tree binding documentation to represent
the axi2apb bridges
used by Control Backbone (CBB) 1.0 in Tegra194 SOC.
All errors for APB
slaves are reported as slave error because APB bas
single bit to report
error. So, CBB driver needs to further check error
status registers of
all the axi2apb bridges to find error type.
Signed-off-by: Sumit Gupta<sumitg@xxxxxxxxxx>
Signed-off-by: Thierry Reding<treding@xxxxxxxxxx>
---
.../arm/tegra/nvidia,tegra194-axi2apb.yaml |
40 +++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml
new file mode 100644
index 000000000000..788a13f8aa93
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:"http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#";
+$schema:"http://devicetree.org/meta-schemas/core.yaml#";
+
+title: NVIDIA Tegra194 AXI2APB bridge
+
+maintainers:
+ - Sumit Gupta<sumitg@xxxxxxxxxx>
+
+properties:
+ $nodename:
+ pattern: "^axi2apb@([0-9a-f]+)$"
+
+ compatible:
+ enum:
+ - nvidia,tegra194-axi2apb
+
+ reg:
+ maxItems: 6
+ description: Physical base address and length
of registers for all bridges
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ axi2apb: axi2apb@2390000 {
As axi2apb appears to be a bus, then all the child nodes (APB devices)
should be under this node.
axi2apb is a bridge which coverts an AXI to APB interface
and not a bus.
A bus and bridge node are pretty much one and the same in DT
representation. A PCI host bridge has a PCI bus beneath it for
example.
Sorry for taking so long to reply, this fell through the cracks.
These aren't really bridges as such. CBB (which we call /bus@0 in DT) is
a sort of large container for all IP. Within that there are various shim
layers that connect these "legacy" interfaces to CBB. I suppose you
could call them bridges, but it's a bit of a stretch. From a software
point of view there is no observable translation happening. The only
reason why we need this is for improved error reporting.
The TRM also doesn't make a distinction between the various bridges. The
devices are all just mapped into a single address space via the CBB.
My understanding is that this is also gone in newer chips, so matters
become a bit simpler there.
Reorganizing /bus@0 into multiple bridges and busses would be a lot of
churn and likely confuse people that want to correlate what's in the TRM
to what's in DT, so I don't think it's worth it.
For newer chips we may want to keep this in mind so we structure the DT
more accurately from the beginning, though as I said, things have been
simplified a bit, so this may not be an issue anymore.
Thierry
Hi Thierry,
Thank you for answering the concern.
Hi Rob,
Can you please ACK to help queue the patch series for next.
Regards,
Sumit
Ping.
No one is going to apply a 4 month old patch. For starters, the DT
meta-schema evolves and this could now have errors. Please resend.
Sent v4 with rebased patches on linux-next.
Regards,
Sumit
