From: Sumit Gupta <sumitg@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>, Rob Herring <robh@kernel.org>
Cc: linux-tegra <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
<devicetree@vger.kernel.org>, Jon Hunter <jonathanh@nvidia.com>,
<kbuild-all@lists.01.org>, <bbasu@nvidia.com>,
<vsethi@nvidia.com>, <jsequeira@nvidia.com>,
Thierry Reding <treding@nvidia.com>,
Sumit Gupta <sumitg@nvidia.com>
Subject: Re: [Patch v3 3/9] dt-bindings: arm: tegra: Add NVIDIA Tegra194 axi2apb binding
Date: Wed, 16 Mar 2022 13:15:35 +0530 [thread overview]
Message-ID: <e1d484b5-b755-e406-8711-62f3756759f3@nvidia.com> (raw)
In-Reply-To: <YhY1Hhgz/O724oYL@orome>
>>>>> 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@nvidia.com>
>>>>> Signed-off-by: Thierry Reding<treding@nvidia.com>
>>>>> ---
>>>>> .../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@nvidia.com>
>>>>> +
>>>>> +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
next prev parent reply other threads:[~2022-03-16 7:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 12:51 [Patch v3 0/9] CBB driver for Tegra194, Tegra234 & Tegra-Grace Sumit Gupta
2021-12-21 12:51 ` [Patch v3 1/9] soc: tegra: set ERD bit to mask inband errors Sumit Gupta
2021-12-21 12:51 ` [Patch v3 2/9] dt-bindings: arm: tegra: Add NVIDIA Tegra194 CBB1.0 binding Sumit Gupta
2021-12-21 12:51 ` [Patch v3 3/9] dt-bindings: arm: tegra: Add NVIDIA Tegra194 axi2apb binding Sumit Gupta
2021-12-22 18:35 ` Rob Herring
2021-12-23 8:24 ` Sumit Gupta
2021-12-27 15:41 ` Rob Herring
2022-02-23 13:22 ` Thierry Reding
2022-03-16 7:45 ` Sumit Gupta [this message]
2022-04-07 6:24 ` Sumit Gupta
2022-05-05 14:04 ` Rob Herring
2022-05-05 17:19 ` Sumit Gupta
2021-12-21 12:51 ` [Patch v3 4/9] arm64: tegra: Add node for CBB1.0 in Tegra194 SOC Sumit Gupta
2021-12-21 12:51 ` [Patch v3 5/9] soc: tegra: cbb: Add CBB1.0 driver for Tegra194 Sumit Gupta
2021-12-21 12:51 ` [Patch v3 6/9] dt-bindings: arm: tegra: Add NVIDIA Tegra234 CBB2.0 binding Sumit Gupta
2021-12-21 12:51 ` [Patch v3 7/9] arm64: tegra: Add node for CBB2.0 in Tegra234 SOC Sumit Gupta
2021-12-21 12:51 ` [Patch v3 8/9] soc: tegra: cbb: Add driver for Tegra234 CBB2.0 Sumit Gupta
2021-12-21 12:51 ` [Patch v3 9/9] soc: tegra: cbb: Add support for tegra-grace SOC Sumit Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1d484b5-b755-e406-8711-62f3756759f3@nvidia.com \
--to=sumitg@nvidia.com \
--cc=bbasu@nvidia.com \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=jsequeira@nvidia.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=treding@nvidia.com \
--cc=vsethi@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).