diff mbox series

[v2,2/4] dt-bindings: PCI: mediatek,mt7621: add missing child node reg

Message ID 20240410181521.269431-2-krzysztof.kozlowski@linaro.org (mailing list archive)
State Superseded
Delegated to: Geert Uytterhoeven
Headers show
Series [v2,1/4] dt-bindings: PCI: cdns,cdns-pcie-host: drop redundant msi-parent and pci-bus.yaml | expand

Commit Message

Krzysztof Kozlowski April 10, 2024, 6:15 p.m. UTC 
MT7621 PCI host bridge has children which apparently are also PCI host
bridges, at least that's what the binding suggest.  The children have
"reg" property, but do not explicitly define it.  Instead they rely on
pci-bus.yaml schema, but that one has "reg" without any constraints.

Define the "reg" for the children, so the binding will be more specific
and later will allow dropping reference to deprecated pci-bus.yaml
schema.

Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

Changes in v2:
1. Add tags.
---
 .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml          | 3 +++
 1 file changed, 3 insertions(+)

Comments

Bjorn Helgaas April 10, 2024, 9:26 p.m. UTC | #1 
On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> MT7621 PCI host bridge has children which apparently are also PCI host
> bridges, at least that's what the binding suggest.

What does it even mean for a PCI host bridge to have a child that is
also a PCI host bridge?

Does this mean a driver binds to the "parent" host bridge, enumerates
the PCI devices below it, and finds a "child" host bridge?

> The children have
> "reg" property, but do not explicitly define it.  Instead they rely on
> pci-bus.yaml schema, but that one has "reg" without any constraints.
> 
> Define the "reg" for the children, so the binding will be more specific
> and later will allow dropping reference to deprecated pci-bus.yaml
> schema.
> 
> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> ---
> 
> Changes in v2:
> 1. Add tags.
> ---
>  .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml          | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> index e63e6458cea8..61d027239910 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> @@ -36,6 +36,9 @@ patternProperties:
>      $ref: /schemas/pci/pci-bus.yaml#
>  
>      properties:
> +      reg:
> +        maxItems: 1
> +
>        resets:
>          maxItems: 1
>  
> -- 
> 2.34.1
>
Krzysztof Kozlowski April 11, 2024, 6:01 a.m. UTC | #2 
On 10/04/2024 23:26, Bjorn Helgaas wrote:
> On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
>> MT7621 PCI host bridge has children which apparently are also PCI host
>> bridges, at least that's what the binding suggest.
> 
> What does it even mean for a PCI host bridge to have a child that is
> also a PCI host bridge?
> 
> Does this mean a driver binds to the "parent" host bridge, enumerates
> the PCI devices below it, and finds a "child" host bridge?

I think the question should be towards Mediatek folks. I don't know what
this hardware is exactly, just looks like pci-pci-bridge. The driver
calls the children host bridges as "ports".

Best regards,
Krzysztof
Sergio Paracuellos April 11, 2024, 6:13 a.m. UTC | #3 
Hi,

On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 10/04/2024 23:26, Bjorn Helgaas wrote:
> > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> >> MT7621 PCI host bridge has children which apparently are also PCI host
> >> bridges, at least that's what the binding suggest.
> >
> > What does it even mean for a PCI host bridge to have a child that is
> > also a PCI host bridge?
> >
> > Does this mean a driver binds to the "parent" host bridge, enumerates
> > the PCI devices below it, and finds a "child" host bridge?

Yes, that is exactly what you can see on enumeration.

The following is a typical boot trace where all bridges has a device also below:

[   20.927280] mt7621-pci 1e140000.pcie: host bridge /pcie@1e140000 ranges:
[   20.940675] mt7621-pci 1e140000.pcie:   No bus range found for
/pcie@1e140000, using [bus 00-ff]
[   20.958228] mt7621-pci 1e140000.pcie:      MEM
0x0060000000..0x006fffffff -> 0x0060000000
[   20.974566] mt7621-pci 1e140000.pcie:       IO
0x001e160000..0x001e16ffff -> 0x0000000000
[   21.369711] mt7621-pci 1e140000.pcie: PCIE0 enabled
[   21.379316] mt7621-pci 1e140000.pcie: PCIE1 enabled
[   21.389140] mt7621-pci 1e140000.pcie: PCIE2 enabled
[   21.399014] PCI coherence region base: 0x60000000, mask/settings: 0xf0000002
[   21.413343] mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
[   21.425952] pci_bus 0000:00: root bus resource [bus 00-ff]
[   21.437023] pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff]
[   21.450657] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[   21.462960] pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400
[   21.474832] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x7fffffff]
[   21.487255] pci 0000:00:00.0: reg 0x14: [mem 0x00000000-0x0000ffff]
[   21.499807] pci 0000:00:00.0: supports D1
[   21.507625] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[   21.519923] pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400
[   21.531827] pci 0000:00:01.0: reg 0x10: [mem 0x00000000-0x7fffffff]
[   21.544225] pci 0000:00:01.0: reg 0x14: [mem 0x00000000-0x0000ffff]
[   21.556773] pci 0000:00:01.0: supports D1
[   21.564621] pci 0000:00:01.0: PME# supported from D0 D1 D3hot
[   21.576823] pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400
[   21.588726] pci 0000:00:02.0: reg 0x10: [mem 0x00000000-0x7fffffff]
[   21.601128] pci 0000:00:02.0: reg 0x14: [mem 0x00000000-0x0000ffff]
[   21.613668] pci 0000:00:02.0: supports D1
[   21.621520] pci 0000:00:02.0: PME# supported from D0 D1 D3hot
[   21.634850] pci 0000:00:00.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[   21.650699] pci 0000:00:01.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[   21.666571] pci 0000:00:02.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[   21.682825] pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185
[   21.694707] pci 0000:01:00.0: reg 0x10: [io  0x0000-0x0007]
[   21.705725] pci 0000:01:00.0: reg 0x14: [io  0x0000-0x0003]
[   21.716789] pci 0000:01:00.0: reg 0x18: [io  0x0000-0x0007]
[   21.727843] pci 0000:01:00.0: reg 0x1c: [io  0x0000-0x0003]
[   21.738907] pci 0000:01:00.0: reg 0x20: [io  0x0000-0x000f]
[   21.749979] pci 0000:01:00.0: reg 0x24: [mem 0x00000000-0x000001ff]
[   21.762568] pci 0000:01:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at 0000:00:00.0 (capable of 4.000
Gb/s with 5.0 GT/s PCIe x1 link)
[   21.819657] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[   21.829966] pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
[   21.842054] pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
[   21.855532] pci 0000:00:00.0:   bridge window [mem
0x00000000-0x000fffff pref]
[   21.869874] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[   21.883352] pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185
[   21.895230] pci 0000:02:00.0: reg 0x10: [io  0x0000-0x0007]
[   21.906256] pci 0000:02:00.0: reg 0x14: [io  0x0000-0x0003]
[   21.917309] pci 0000:02:00.0: reg 0x18: [io  0x0000-0x0007]
[   21.928373] pci 0000:02:00.0: reg 0x1c: [io  0x0000-0x0003]
[   21.939428] pci 0000:02:00.0: reg 0x20: [io  0x0000-0x000f]
[   21.950500] pci 0000:02:00.0: reg 0x24: [mem 0x00000000-0x000001ff]
[   21.963094] pci 0000:02:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at 0000:00:01.0 (capable of 4.000
Gb/s with 5.0 GT/s PCIe x1 link)
[   22.029662] pci 0000:00:01.0: PCI bridge to [bus 02-ff]
[   22.039993] pci 0000:00:01.0:   bridge window [io  0x0000-0x0fff]
[   22.052063] pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff]
[   22.065538] pci 0000:00:01.0:   bridge window [mem
0x00000000-0x000fffff pref]
[   22.079886] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
[   22.093352] pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185
[   22.105233] pci 0000:03:00.0: reg 0x10: [io  0x0000-0x0007]
[   22.116249] pci 0000:03:00.0: reg 0x14: [io  0x0000-0x0003]
[   22.127313] pci 0000:03:00.0: reg 0x18: [io  0x0000-0x0007]
[   22.138367] pci 0000:03:00.0: reg 0x1c: [io  0x0000-0x0003]
[   22.149451] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x000f]
[   22.160503] pci 0000:03:00.0: reg 0x24: [mem 0x00000000-0x000001ff]
[   22.173091] pci 0000:03:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at 0000:00:02.0 (capable of 4.000
Gb/s with 5.0 GT/s PCIe x1 link)
[   22.239653] pci 0000:00:02.0: PCI bridge to [bus 03-ff]
[   22.249973] pci 0000:00:02.0:   bridge window [io  0x0000-0x0fff]
[   22.262045] pci 0000:00:02.0:   bridge window [mem 0x00000000-0x000fffff]
[   22.275524] pci 0000:00:02.0:   bridge window [mem
0x00000000-0x000fffff pref]
[   22.289870] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[   22.303080] pci 0000:00:00.0: BAR 0: no space for [mem size 0x80000000]
[   22.316129] pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x80000000]
[   22.329956] pci 0000:00:01.0: BAR 0: no space for [mem size 0x80000000]
[   22.343081] pci 0000:00:01.0: BAR 0: failed to assign [mem size 0x80000000]
[   22.356912] pci 0000:00:02.0: BAR 0: no space for [mem size 0x80000000]
[   22.370053] pci 0000:00:02.0: BAR 0: failed to assign [mem size 0x80000000]
[   22.383870] pci 0000:00:00.0: BAR 8: assigned [mem 0x60000000-0x600fffff]
[   22.397349] pci 0000:00:00.0: BAR 9: assigned [mem
0x60100000-0x601fffff pref]
[   22.411692] pci 0000:00:01.0: BAR 8: assigned [mem 0x60200000-0x602fffff]
[   22.425165] pci 0000:00:01.0: BAR 9: assigned [mem
0x60300000-0x603fffff pref]
[   22.439522] pci 0000:00:02.0: BAR 8: assigned [mem 0x60400000-0x604fffff]
[   22.452991] pci 0000:00:02.0: BAR 9: assigned [mem
0x60500000-0x605fffff pref]
[   22.467328] pci 0000:00:00.0: BAR 1: assigned [mem 0x60600000-0x6060ffff]
[   22.480814] pci 0000:00:01.0: BAR 1: assigned [mem 0x60610000-0x6061ffff]
[   22.494303] pci 0000:00:02.0: BAR 1: assigned [mem 0x60620000-0x6062ffff]
[   22.507766] pci 0000:00:00.0: BAR 7: assigned [io  0x0000-0x0fff]
[   22.519861] pci 0000:00:01.0: BAR 7: assigned [io  0x1000-0x1fff]
[   22.531960] pci 0000:00:02.0: BAR 7: assigned [io  0x2000-0x2fff]
[   22.544068] pci 0000:01:00.0: BAR 5: assigned [mem 0x60000000-0x600001ff]
[   22.557548] pci 0000:01:00.0: BAR 4: assigned [io  0x0000-0x000f]
[   22.569635] pci 0000:01:00.0: BAR 0: assigned [io  0x0010-0x0017]
[   22.581726] pci 0000:01:00.0: BAR 2: assigned [io  0x0018-0x001f]
[   22.593827] pci 0000:01:00.0: BAR 1: assigned [io  0x0020-0x0023]
[   22.605917] pci 0000:01:00.0: BAR 3: assigned [io  0x0024-0x0027]
[   22.618030] pci 0000:00:00.0: PCI bridge to [bus 01]
[   22.627859] pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
[   22.639956] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
[   22.653437] pci 0000:00:00.0:   bridge window [mem
0x60100000-0x601fffff pref]
[   22.667785] pci 0000:02:00.0: BAR 5: assigned [mem 0x60200000-0x602001ff]
[   22.681268] pci 0000:02:00.0: BAR 4: assigned [io  0x1000-0x100f]
[   22.693359] pci 0000:02:00.0: BAR 0: assigned [io  0x1010-0x1017]
[   22.705450] pci 0000:02:00.0: BAR 2: assigned [io  0x1018-0x101f]
[   22.717552] pci 0000:02:00.0: BAR 1: assigned [io  0x1020-0x1023]
[   22.729654] pci 0000:02:00.0: BAR 3: assigned [io  0x1024-0x1027]
[   22.741746] pci 0000:00:01.0: PCI bridge to [bus 02]
[   22.751587] pci 0000:00:01.0:   bridge window [io  0x1000-0x1fff]
[   22.763678] pci 0000:00:01.0:   bridge window [mem 0x60200000-0x602fffff]
[   22.777161] pci 0000:00:01.0:   bridge window [mem
0x60300000-0x603fffff pref]
[   22.791515] pci 0000:03:00.0: BAR 5: assigned [mem 0x60400000-0x604001ff]
[   22.804991] pci 0000:03:00.0: BAR 4: assigned [io  0x2000-0x200f]
[   22.817084] pci 0000:03:00.0: BAR 0: assigned [io  0x2010-0x2017]
[   22.829175] pci 0000:03:00.0: BAR 2: assigned [io  0x2018-0x201f]
[   22.841274] pci 0000:03:00.0: BAR 1: assigned [io  0x2020-0x2023]
[   22.853379] pci 0000:03:00.0: BAR 3: assigned [io  0x2024-0x2027]
[   22.865472] pci 0000:00:02.0: PCI bridge to [bus 03]
[   22.875312] pci 0000:00:02.0:   bridge window [io  0x2000-0x2fff]
[   22.887403] pci 0000:00:02.0:   bridge window [mem 0x60400000-0x604fffff]

>
> I think the question should be towards Mediatek folks. I don't know what
> this hardware is exactly, just looks like pci-pci-bridge. The driver
> calls the children host bridges as "ports".

You can see the topology here in my first driver submit cover letter
message [0].

Thanks,
    Sergio Paracuellos

 [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@mail.gmail.com/t/

>
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski April 11, 2024, 6:20 a.m. UTC | #4 
On 11/04/2024 08:13, Sergio Paracuellos wrote:
> 
>>
>> I think the question should be towards Mediatek folks. I don't know what
>> this hardware is exactly, just looks like pci-pci-bridge. The driver
>> calls the children host bridges as "ports".
> 
> You can see the topology here in my first driver submit cover letter
> message [0].
> 

Useful diagram, thanks. It would be great if you could add it to the
binding description.

Best regards,
Krzysztof
Sergio Paracuellos April 11, 2024, 6:37 a.m. UTC | #5 
On Thu, Apr 11, 2024 at 8:20 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 11/04/2024 08:13, Sergio Paracuellos wrote:
> >
> >>
> >> I think the question should be towards Mediatek folks. I don't know what
> >> this hardware is exactly, just looks like pci-pci-bridge. The driver
> >> calls the children host bridges as "ports".
> >
> > You can see the topology here in my first driver submit cover letter
> > message [0].
> >
>
> Useful diagram, thanks. It would be great if you could add it to the
> binding description.

Sure, I will do it depending on time hopefully sooner than later :-).

Best regards,
    Sergio Paracuellos

>
> Best regards,
> Krzysztof
>
Bjorn Helgaas April 11, 2024, 12:39 p.m. UTC | #6 
On Thu, Apr 11, 2024 at 08:13:18AM +0200, Sergio Paracuellos wrote:
> On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> > On 10/04/2024 23:26, Bjorn Helgaas wrote:
> > > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> > >> MT7621 PCI host bridge has children which apparently are also PCI host
> > >> bridges, at least that's what the binding suggest.
> > >
> > > What does it even mean for a PCI host bridge to have a child that is
> > > also a PCI host bridge?
> > >
> > > Does this mean a driver binds to the "parent" host bridge, enumerates
> > > the PCI devices below it, and finds a "child" host bridge?
> 
> Yes, that is exactly what you can see on enumeration.
> 
> The following is a typical boot trace where all bridges has a device also below:
> 
> mt7621-pci 1e140000.pcie: host bridge /pcie@1e140000 ranges:
> mt7621-pci 1e140000.pcie:   No bus range found for /pcie@1e140000, using [bus 00-ff]
> mt7621-pci 1e140000.pcie:      MEM 0x0060000000..0x006fffffff -> 0x0060000000
> mt7621-pci 1e140000.pcie:       IO 0x001e160000..0x001e16ffff -> 0x0000000000
> mt7621-pci 1e140000.pcie: PCIE0 enabled
> mt7621-pci 1e140000.pcie: PCIE1 enabled
> mt7621-pci 1e140000.pcie: PCIE2 enabled
> mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00

1e140000.pcie is a host bridge.  It has some CPU-specific bus on the
upstream side, standard PCI (domain 0000, buses 00-ff) on the
downstream side.

> pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400
> pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400
> pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400

> pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185

> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
> pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff pref]

00:00.0 looks like a PCIe Root Port to bus 01.  This is not a host
bridge; it's just a standard PCI-to-PCI bridge with PCI on both the
upstream and downstream sides.

> pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185

> pci 0000:00:01.0: PCI bridge to [bus 02-ff]
> pci 0000:00:01.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff]
> pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff pref]

00:01.0 is another Root Port to bus 02.

> pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185

> pci 0000:00:02.0: PCI bridge to [bus 03-ff]
> pci 0000:00:02.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:02.0:   bridge window [mem 0x00000000-0x000fffff]
> pci 0000:00:02.0:   bridge window [mem 0x00000000-0x000fffff pref]
> pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03

And 00:02.0 is a third Root Port to bus 03.

> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> pci 0000:00:00.0:   bridge window [mem 0x60100000-0x601fffff pref]
> pci 0000:00:01.0: PCI bridge to [bus 02]
> pci 0000:00:01.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:01.0:   bridge window [mem 0x60200000-0x602fffff]
> pci 0000:00:01.0:   bridge window [mem 0x60300000-0x603fffff pref]
> pci 0000:00:02.0: PCI bridge to [bus 03]
> pci 0000:00:02.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:02.0:   bridge window [mem 0x60400000-0x604fffff]
> 
> > I think the question should be towards Mediatek folks. I don't know what
> > this hardware is exactly, just looks like pci-pci-bridge. The driver
> > calls the children host bridges as "ports".
> 
> You can see the topology here in my first driver submit cover letter
> message [0].
> 
>  [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@mail.gmail.com/t/

Nothing unusual here, this looks like the standard PCIe topology.

What *might* be unusual is describing the Root Ports in DT.  Since
they are standard PCI devices, they shouldn't need DT description
unless there's some unusual power/clock/reset control or something
that is not discoverable via PCI enumeration.

Bjorn
Sergio Paracuellos April 11, 2024, 1:33 p.m. UTC | #7 
On Thu, Apr 11, 2024 at 2:39 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Thu, Apr 11, 2024 at 08:13:18AM +0200, Sergio Paracuellos wrote:
> > On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> > > On 10/04/2024 23:26, Bjorn Helgaas wrote:
> > > > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> > > >> MT7621 PCI host bridge has children which apparently are also PCI host
> > > >> bridges, at least that's what the binding suggest.
> > > >
> > > > What does it even mean for a PCI host bridge to have a child that is
> > > > also a PCI host bridge?
> > > >
> > > > Does this mean a driver binds to the "parent" host bridge, enumerates
> > > > the PCI devices below it, and finds a "child" host bridge?
> >
> > Yes, that is exactly what you can see on enumeration.
> >
> > The following is a typical boot trace where all bridges has a device also below:
> >
> > mt7621-pci 1e140000.pcie: host bridge /pcie@1e140000 ranges:
> > mt7621-pci 1e140000.pcie:   No bus range found for /pcie@1e140000, using [bus 00-ff]
> > mt7621-pci 1e140000.pcie:      MEM 0x0060000000..0x006fffffff -> 0x0060000000
> > mt7621-pci 1e140000.pcie:       IO 0x001e160000..0x001e16ffff -> 0x0000000000
> > mt7621-pci 1e140000.pcie: PCIE0 enabled
> > mt7621-pci 1e140000.pcie: PCIE1 enabled
> > mt7621-pci 1e140000.pcie: PCIE2 enabled
> > mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
>
> 1e140000.pcie is a host bridge.  It has some CPU-specific bus on the
> upstream side, standard PCI (domain 0000, buses 00-ff) on the
> downstream side.
>
> > pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400
> > pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400
> > pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400
>
> > pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185
>
> > pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
> > pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff pref]
>
> 00:00.0 looks like a PCIe Root Port to bus 01.  This is not a host
> bridge; it's just a standard PCI-to-PCI bridge with PCI on both the
> upstream and downstream sides.
>
> > pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185
>
> > pci 0000:00:01.0: PCI bridge to [bus 02-ff]
> > pci 0000:00:01.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff]
> > pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff pref]
>
> 00:01.0 is another Root Port to bus 02.
>
> > pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185
>
> > pci 0000:00:02.0: PCI bridge to [bus 03-ff]
> > pci 0000:00:02.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:02.0:   bridge window [mem 0x00000000-0x000fffff]
> > pci 0000:00:02.0:   bridge window [mem 0x00000000-0x000fffff pref]
> > pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
>
> And 00:02.0 is a third Root Port to bus 03.
>
> > pci 0000:00:00.0: PCI bridge to [bus 01]
> > pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> > pci 0000:00:00.0:   bridge window [mem 0x60100000-0x601fffff pref]
> > pci 0000:00:01.0: PCI bridge to [bus 02]
> > pci 0000:00:01.0:   bridge window [io  0x1000-0x1fff]
> > pci 0000:00:01.0:   bridge window [mem 0x60200000-0x602fffff]
> > pci 0000:00:01.0:   bridge window [mem 0x60300000-0x603fffff pref]
> > pci 0000:00:02.0: PCI bridge to [bus 03]
> > pci 0000:00:02.0:   bridge window [io  0x2000-0x2fff]
> > pci 0000:00:02.0:   bridge window [mem 0x60400000-0x604fffff]
> >
> > > I think the question should be towards Mediatek folks. I don't know what
> > > this hardware is exactly, just looks like pci-pci-bridge. The driver
> > > calls the children host bridges as "ports".
> >
> > You can see the topology here in my first driver submit cover letter
> > message [0].
> >
> >  [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@mail.gmail.com/t/
>
> Nothing unusual here, this looks like the standard PCIe topology.
>
> What *might* be unusual is describing the Root Ports in DT.  Since
> they are standard PCI devices, they shouldn't need DT description
> unless there's some unusual power/clock/reset control or something
> that is not discoverable via PCI enumeration.

It looks like it is necessary since every port has its own
configuration registers, phy, clock, reset and interrupt.

Thanks,
    Sergio Paracuellos

> Bjorn
Rob Herring (Arm) April 11, 2024, 2:21 p.m. UTC | #8 
On Thu, Apr 11, 2024 at 07:39:17AM -0500, Bjorn Helgaas wrote:
> On Thu, Apr 11, 2024 at 08:13:18AM +0200, Sergio Paracuellos wrote:
> > On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> > > On 10/04/2024 23:26, Bjorn Helgaas wrote:
> > > > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> > > >> MT7621 PCI host bridge has children which apparently are also PCI host
> > > >> bridges, at least that's what the binding suggest.
> > > >
> > > > What does it even mean for a PCI host bridge to have a child that is
> > > > also a PCI host bridge?

It should say 'root port' instead as the binding description correctly 
says.

> > > >
> > > > Does this mean a driver binds to the "parent" host bridge, enumerates
> > > > the PCI devices below it, and finds a "child" host bridge?
> > 
> > Yes, that is exactly what you can see on enumeration.
> > 
> > The following is a typical boot trace where all bridges has a device also below:
> > 
> > mt7621-pci 1e140000.pcie: host bridge /pcie@1e140000 ranges:
> > mt7621-pci 1e140000.pcie:   No bus range found for /pcie@1e140000, using [bus 00-ff]
> > mt7621-pci 1e140000.pcie:      MEM 0x0060000000..0x006fffffff -> 0x0060000000
> > mt7621-pci 1e140000.pcie:       IO 0x001e160000..0x001e16ffff -> 0x0000000000
> > mt7621-pci 1e140000.pcie: PCIE0 enabled
> > mt7621-pci 1e140000.pcie: PCIE1 enabled
> > mt7621-pci 1e140000.pcie: PCIE2 enabled
> > mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
> 
> 1e140000.pcie is a host bridge.  It has some CPU-specific bus on the
> upstream side, standard PCI (domain 0000, buses 00-ff) on the
> downstream side.
> 
> > pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400
> > pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400
> > pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400
> 
> > pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185
> 
> > pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
> > pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff pref]
> 
> 00:00.0 looks like a PCIe Root Port to bus 01.  This is not a host
> bridge; it's just a standard PCI-to-PCI bridge with PCI on both the
> upstream and downstream sides.
> 
> > pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185
> 
> > pci 0000:00:01.0: PCI bridge to [bus 02-ff]
> > pci 0000:00:01.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff]
> > pci 0000:00:01.0:   bridge window [mem 0x00000000-0x000fffff pref]
> 
> 00:01.0 is another Root Port to bus 02.
> 
> > pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185
> 
> > pci 0000:00:02.0: PCI bridge to [bus 03-ff]
> > pci 0000:00:02.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:02.0:   bridge window [mem 0x00000000-0x000fffff]
> > pci 0000:00:02.0:   bridge window [mem 0x00000000-0x000fffff pref]
> > pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
> 
> And 00:02.0 is a third Root Port to bus 03.
> 
> > pci 0000:00:00.0: PCI bridge to [bus 01]
> > pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> > pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> > pci 0000:00:00.0:   bridge window [mem 0x60100000-0x601fffff pref]
> > pci 0000:00:01.0: PCI bridge to [bus 02]
> > pci 0000:00:01.0:   bridge window [io  0x1000-0x1fff]
> > pci 0000:00:01.0:   bridge window [mem 0x60200000-0x602fffff]
> > pci 0000:00:01.0:   bridge window [mem 0x60300000-0x603fffff pref]
> > pci 0000:00:02.0: PCI bridge to [bus 03]
> > pci 0000:00:02.0:   bridge window [io  0x2000-0x2fff]
> > pci 0000:00:02.0:   bridge window [mem 0x60400000-0x604fffff]
> > 
> > > I think the question should be towards Mediatek folks. I don't know what
> > > this hardware is exactly, just looks like pci-pci-bridge. The driver
> > > calls the children host bridges as "ports".
> > 
> > You can see the topology here in my first driver submit cover letter
> > message [0].
> > 
> >  [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@mail.gmail.com/t/
> 
> Nothing unusual here, this looks like the standard PCIe topology.
> 
> What *might* be unusual is describing the Root Ports in DT.  Since
> they are standard PCI devices, they shouldn't need DT description
> unless there's some unusual power/clock/reset control or something
> that is not discoverable via PCI enumeration.

It's only unusual because typically there's only 1 RP per host bridge 
and properties which really apply to the RP get stuck in the host bridge 
node because we don't have a RP node. An example is perst-gpios. That's 
not a property of the RP either, but the RP is the upstream side of a 
slot and we often don't have a node for the device either.

Rob
Bjorn Helgaas April 11, 2024, 4:11 p.m. UTC | #9 
On Thu, Apr 11, 2024 at 09:21:07AM -0500, Rob Herring wrote:
> On Thu, Apr 11, 2024 at 07:39:17AM -0500, Bjorn Helgaas wrote:
> > On Thu, Apr 11, 2024 at 08:13:18AM +0200, Sergio Paracuellos wrote:
> > > On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski
> > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > On 10/04/2024 23:26, Bjorn Helgaas wrote:
> > > > > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> > > > >> MT7621 PCI host bridge has children which apparently are also PCI host
> > > > >> bridges, at least that's what the binding suggest.
> > > > >
> > > > > What does it even mean for a PCI host bridge to have a child that is
> > > > > also a PCI host bridge?
> 
> It should say 'root port' instead as the binding description correctly 
> says.

OK, that makes a lot more sense, and we should fix the commit log.

> > > > I think the question should be towards Mediatek folks. I don't know what
> > > > this hardware is exactly, just looks like pci-pci-bridge. The driver
> > > > calls the children host bridges as "ports".
> > > 
> > > You can see the topology here in my first driver submit cover letter
> > > message [0].
> > > 
> > >  [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@mail.gmail.com/t/
> > 
> > Nothing unusual here, this looks like the standard PCIe topology.
> > 
> > What *might* be unusual is describing the Root Ports in DT.  Since
> > they are standard PCI devices, they shouldn't need DT description
> > unless there's some unusual power/clock/reset control or something
> > that is not discoverable via PCI enumeration.
> 
> It's only unusual because typically there's only 1 RP per host bridge 
> and properties which really apply to the RP get stuck in the host bridge 
> node because we don't have a RP node. An example is perst-gpios. That's 
> not a property of the RP either, but the RP is the upstream side of a 
> slot and we often don't have a node for the device either.

Makes sense.

I'm still confused about one thing, maybe just because I don't really
know how to read these bindings.  The binding now looks like this:

  properties:
    compatible:
      const: mediatek,mt7621-pci

    reg:
      items:
        - description: host-pci bridge registers
        - description: pcie port 0 RC control registers       # A
        - description: pcie port 1 RC control registers       # A
        - description: pcie port 2 RC control registers       # A

  patternProperties:
    '^pcie@[0-2],0$':
      type: object
      $ref: /schemas/pci/pci-pci-bridge.yaml#

      properties:
        reg:                                                  # B
          maxItems: 1

It looks like the "A" items are separate things from the "B" items?

But I think the relevant code is here:

  mt7621_pcie_probe
    mt7621_pcie_parse_dt
      pcie->base = devm_platform_ioremap_resource(pdev, 0)             # 1
      for_each_available_child_of_node(node, child)
        mt7621_pcie_parse_port
          port->base = devm_platform_ioremap_resource(pdev, slot + 1)  # 2

where it looks like both "1" and "2" use the items in the "A" list,
i.e., resources 0, 1, 2, 3, all from the same platform device.  Is
there code that uses the "B" item that this patch adds?

Bjorn
Rob Herring (Arm) April 11, 2024, 5:41 p.m. UTC | #10 
On Thu, Apr 11, 2024 at 11:11 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Thu, Apr 11, 2024 at 09:21:07AM -0500, Rob Herring wrote:
> > On Thu, Apr 11, 2024 at 07:39:17AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Apr 11, 2024 at 08:13:18AM +0200, Sergio Paracuellos wrote:
> > > > On Thu, Apr 11, 2024 at 8:01 AM Krzysztof Kozlowski
> > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > > On 10/04/2024 23:26, Bjorn Helgaas wrote:
> > > > > > On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> > > > > >> MT7621 PCI host bridge has children which apparently are also PCI host
> > > > > >> bridges, at least that's what the binding suggest.
> > > > > >
> > > > > > What does it even mean for a PCI host bridge to have a child that is
> > > > > > also a PCI host bridge?
> >
> > It should say 'root port' instead as the binding description correctly
> > says.
>
> OK, that makes a lot more sense, and we should fix the commit log.
>
> > > > > I think the question should be towards Mediatek folks. I don't know what
> > > > > this hardware is exactly, just looks like pci-pci-bridge. The driver
> > > > > calls the children host bridges as "ports".
> > > >
> > > > You can see the topology here in my first driver submit cover letter
> > > > message [0].
> > > >
> > > >  [0]: https://lore.kernel.org/all/CAMhs-H-BA+KzEwuDPzcmrDPdgJBFA2XdYTBvT4R4MEOUB=WQ1g@mail.gmail.com/t/
> > >
> > > Nothing unusual here, this looks like the standard PCIe topology.
> > >
> > > What *might* be unusual is describing the Root Ports in DT.  Since
> > > they are standard PCI devices, they shouldn't need DT description
> > > unless there's some unusual power/clock/reset control or something
> > > that is not discoverable via PCI enumeration.
> >
> > It's only unusual because typically there's only 1 RP per host bridge
> > and properties which really apply to the RP get stuck in the host bridge
> > node because we don't have a RP node. An example is perst-gpios. That's
> > not a property of the RP either, but the RP is the upstream side of a
> > slot and we often don't have a node for the device either.
>
> Makes sense.
>
> I'm still confused about one thing, maybe just because I don't really
> know how to read these bindings.  The binding now looks like this:
>
>   properties:
>     compatible:
>       const: mediatek,mt7621-pci
>
>     reg:
>       items:
>         - description: host-pci bridge registers
>         - description: pcie port 0 RC control registers       # A
>         - description: pcie port 1 RC control registers       # A
>         - description: pcie port 2 RC control registers       # A
>
>   patternProperties:
>     '^pcie@[0-2],0$':
>       type: object
>       $ref: /schemas/pci/pci-pci-bridge.yaml#
>
>       properties:
>         reg:                                                  # B
>           maxItems: 1
>
> It looks like the "A" items are separate things from the "B" items?
>
> But I think the relevant code is here:
>
>   mt7621_pcie_probe
>     mt7621_pcie_parse_dt
>       pcie->base = devm_platform_ioremap_resource(pdev, 0)             # 1
>       for_each_available_child_of_node(node, child)
>         mt7621_pcie_parse_port
>           port->base = devm_platform_ioremap_resource(pdev, slot + 1)  # 2
>
> where it looks like both "1" and "2" use the items in the "A" list,
> i.e., resources 0, 1, 2, 3, all from the same platform device.  Is
> there code that uses the "B" item that this patch adds?

The A items are in the host address space. The B item is a PCI
address. Specifically, for PCI devices, the first entry is config
space with just the device and function (devfn). The format is defined
in the OpenFirmware PCI bus supplement.

Rob
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
index e63e6458cea8..61d027239910 100644
--- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
@@ -36,6 +36,9 @@  patternProperties:
     $ref: /schemas/pci/pci-bus.yaml#
 
     properties:
+      reg:
+        maxItems: 1
+
       resets:
         maxItems: 1