Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Thierry Reding <thierry.reding@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 6001 bytes --]

On Fri, Mar 20, 2026 at 08:06:26AM -0500, Rob Herring wrote:
> On Fri, Mar 20, 2026 at 4:39 AM Thierry Reding
> <thierry.reding@kernel.org> wrote:
> >
> > On Thu, Mar 19, 2026 at 04:26:31PM -0500, Rob Herring wrote:
> > > On Thu, Mar 19, 2026 at 11:01 AM Thierry Reding
> > > <thierry.reding@kernel.org> wrote:
> > > >
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > The six PCIe controllers found on Tegra264 are of two types: one is used
> > > > for the internal GPU and therefore is not connected to a UPHY and the
> > > > remaining five controllers are typically routed to a PCI slot and have
> > > > additional controls for the physical link.
> > > >
> > > > While these controllers can be switched into endpoint mode, this binding
> > > > describes the root complex mode only.
> > > >
> > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > ---
> > > >  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
> > > >  1 file changed, 92 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > > new file mode 100644
> > > > index 000000000000..56d69de2788b
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > > @@ -0,0 +1,92 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: NVIDIA Tegra264 PCIe controller
> > > > +
> > > > +maintainers:
> > > > +  - Thierry Reding <thierry.reding@gmail.com>
> > > > +  - Jon Hunter <jonathanh@nvidia.com>
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: nvidia,tegra264-pcie
> > > > +
> > > > +  reg:
> > > > +    minItems: 4
> > > > +    maxItems: 5
> > > > +
> > > > +  reg-names:
> > > > +    minItems: 4
> > > > +    maxItems: 5
> > > > +
> > > > +  interrupts:
> > > > +    minItems: 1
> > > > +    maxItems: 4
> > > > +
> > > > +  dma-coherent: true
> > > > +
> > > > +  nvidia,bpmp:
> > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +    description: |
> > > > +      Must contain a pair of phandle (to the BPMP controller node) and
> > > > +      controller ID. The following are the controller IDs for each controller:
> > > > +
> > > > +      0: C0
> > > > +      1: C1
> > > > +      2: C2
> > > > +      3: C3
> > > > +      4: C4
> > > > +      5: C5
> > > > +    items:
> > > > +      - items:
> > > > +          - description: phandle to the BPMP controller node
> > > > +          - description: PCIe controller ID
> > > > +            maximum: 5
> > > > +
> > > > +unevaluatedProperties: false
> > > > +
> > > > +required:
> > > > +  - interrupt-map
> > > > +  - interrupt-map-mask
> > > > +  - iommu-map
> > > > +  - msi-map
> > > > +  - nvidia,bpmp
> > > > +
> > > > +allOf:
> > > > +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> > > > +  - oneOf:
> > > > +    - description: C0 controller (no UPHY)
> > > > +      properties:
> > > > +        reg:
> > > > +          items:
> > > > +            - description: application layer registers
> > > > +            - description: transaction layer registers
> > > > +            - description: privileged transaction layer registers
> > > > +            - description: ECAM-compatible configuration space
> > > > +
> > > > +        reg-names:
> > > > +          items:
> > > > +            - const: xal
> > > > +            - const: xtl
> > > > +            - const: xtl-pri
> > > > +            - const: ecam
> > > > +
> > > > +    - description: C1-C5 controllers (with UPHY)
> > > > +      properties:
> > > > +        reg:
> > > > +          items:
> > > > +            - description: application layer registers
> > > > +            - description: transaction layer registers
> > > > +            - description: privileged transaction layer registers
> > > > +            - description: data link/physical layer registers
> > > > +            - description: ECAM-compatible configuration space
> > > > +
> > > > +      items:
> > > > +        - const: xal
> > > > +        - const: xtl
> > > > +        - const: xtl-pri
> > > > +        - const: xpl
> > >
> > > Put this entry last since it is the optional one. Then you can move
> > > all of this to the top-level and get rid of the duplication.
> >
> > I understand this concern and was actually on the fence about this
> > myself. The reason why I ultimately went with this variant is for two
> > reasons:
> >
> >   1. XPL does not exist for controller 0, the variant above makes that
> >      very explicit. It explicitly documents that controller 0 is used
> >      for internal purposes and cannot be connected to an external port
> >      like the other five controllers.
> 
> That doesn't really matter to the schema because it can never check
> that unless you have 2 different compatibles (and you shouldn't).

I know that, the documentation would be more for developers/users rather
than the validation tools.

> >   2. The ECAM region is part of a memory region specifically reserved
> >      for configuration space, whereas all of the other regions are
> >      from the controller's MMIO region. I find the DT hard to read if
> >      the two are interleaved.
> 
> I was also going to suggest putting ECAM first just to align with the
> generic host binding. That would make it slightly easier to rewrite
> the node if you decided to make it a firmware initialized controller.

Huh... I hadn't considered that. I think that would be a compromise that
I can very well live with.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]