| Message ID | 20211221125117.6545-4-sumitg@nvidia.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | CBB driver for Tegra194, Tegra234 & Tegra-Grace | expand |
On Tue, Dec 21, 2021 at 06:21:11PM +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@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. Is NVidia still putting all the devices at the root level rather than under a bus node which is preferred? > + compatible = "nvidia,tegra194-axi2apb"; > + reg = <0x02390000 0x1000>, > + <0x023a0000 0x1000>, > + <0x023b0000 0x1000>, > + <0x023c0000 0x1000>, > + <0x023d0000 0x1000>, > + <0x023e0000 0x1000>; > + }; > -- > 2.17.1 > >
> On Tue, Dec 21, 2021 at 06:21:11PM +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@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. CBB stretches to the various partitions using different bridges like axi2apb, axip2p etc connected either as single or in chain. The bridge reports if error and that gets logged in NOC's error logger. For APB slaves, all errors are logged as slave errors as there is a single error bit. So, we need to read the error status register of the bridges to further triage the reason of the error. > > Is NVidia still putting all the devices at the root level rather than > under a bus node which is preferred? All the cbb noc nodes in T194 and fabric nodes in T234 are under "bus@0" node. > >> + compatible = "nvidia,tegra194-axi2apb"; >> + reg = <0x02390000 0x1000>, >> + <0x023a0000 0x1000>, >> + <0x023b0000 0x1000>, >> + <0x023c0000 0x1000>, >> + <0x023d0000 0x1000>, >> + <0x023e0000 0x1000>; >> + }; >> -- >> 2.17.1 >> >>
On Thu, Dec 23, 2021 at 4:24 AM Sumit Gupta <sumitg@nvidia.com> wrote: > > On Tue, Dec 21, 2021 at 06:21:11PM +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@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. Rob
On Mon, Dec 27, 2021 at 11:41:10AM -0400, Rob Herring wrote: > On Thu, Dec 23, 2021 at 4:24 AM Sumit Gupta <sumitg@nvidia.com> wrote: > > > On Tue, Dec 21, 2021 at 06:21:11PM +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@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
>>>>> 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
> >>>>>> 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 Ping. Regards, Sumit
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@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 > > 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. Rob
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@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 >> >> 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
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 { + compatible = "nvidia,tegra194-axi2apb"; + reg = <0x02390000 0x1000>, + <0x023a0000 0x1000>, + <0x023b0000 0x1000>, + <0x023c0000 0x1000>, + <0x023d0000 0x1000>, + <0x023e0000 0x1000>; + };