All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergio Paracuellos <sergio.paracuellos@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	linux-staging@lists.linux.dev,
	 Greg KH <gregkh@linuxfoundation.org>,
	NeilBrown <neil@brown.name>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dt-bindings: staging: mt7621-pci: PCIe binding documentation for MT76721 SoCs
Date: Thu, 6 May 2021 18:41:36 +0200	[thread overview]
Message-ID: <CAMhs-H_Ae4Erx06j2fGSiZXpGo9UWRAkSPPQhFGnZ1D8=NM8cg@mail.gmail.com> (raw)
In-Reply-To: <20210506151839.GA322729@robh.at.kernel.org>

Hi Rob,

Thanks for the review.

On Thu, May 6, 2021 at 5:18 PM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, May 01, 2021 at 03:36:46PM +0200, Sergio Paracuellos wrote:
> > Add device tree binding documentation for PCIe in MT7621 SoCs.
> >
> > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
> > ---
> >
> > Hi Rob,
> >
> > Some concerns here. I was not be able to found any case similar to
> > this binding where sub-nodes describing each pcie port interface
> > are needed. I added them to the 'examples' directly without saying
> > anything about properties in any other place since its properties
> > seems to be covered in 'pci-bus.yaml' schema definition. I don't
> > know if this is the way, I have checked against schema and I noticed
> > I am forced to add 'device_type' property in each subnode because
> > schema checker complains that this is mandatory. So I have added
> > it and schema is properly being validated:
> >
> > Before add the 'device_type' in each subnode:
> > /home/sergio/staging/Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.example.dt.yaml: pcie@0,0: 'device_type' is a required property
> > >From schema: /home/sergio/.local/lib/python3.9/site-packages/dtschema/schemas/pci/pci-bus.yaml
> > /home/sergio/staging/Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.example.dt.yaml: pcie@1,0: 'device_type' is a required property
> > >From schema: /home/sergio/.local/lib/python3.9/site-packages/dtschema/schemas/pci/pci-bus.yaml
> > /home/sergio/staging/Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.example.dt.yaml: pcie@2,0: 'device_type' is a required property
> > >From schema: /home/sergio/.local/lib/python3.9/site-packages/dtschema/schemas/pci/pci-bus.yaml
>
> Each port is a PCI bridge, right? If so, then 'pcie' for the node name
> and 'device_type = "pci";' are correct.

Yes it is, thanks for clarification.

>
> >
> > After adding it:
> > CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>
> Validates all the schema
>
> > SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>
> Preprocesses all the schema
>
> > DTEX    Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.example.dts
>
> Extracts the example to dts file
>
> > DTC     Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.example.dt.yaml
>
> Converts the example to yaml
>
> > CHECK   Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.example.dt.yaml
>
> Runs the checks.
>
> >
> > Looks a bit redundant and maybe I am doing something wrong...

I meant redundant the 'device_type=pci' in all of the child nodes, not
the messages I got when check against the schema but thanks also for
explanation :).

> >
> > Thanks in advance for clarification.
> >
> > Best regards,
> >     Sergio Paracuellos
> >
> >
> >  .../bindings/pci/mediatek,mt7621-pci.yaml     | 144 ++++++++++++++++++
> >  .../mt7621-pci/mediatek,mt7621-pci.txt        | 104 -------------
> >  2 files changed, 144 insertions(+), 104 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.yaml
> >  delete mode 100644 drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.yaml
> > new file mode 100644
> > index 000000000000..9c1d05d929a2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pci.yaml
> > @@ -0,0 +1,144 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pci/mediatek,mt7621-pci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek MT7621 PCIe controller
> > +
> > +maintainers:
> > +  - Sergio Paracuellos <sergio.paracuellos@gmail.com>
> > +
> > +description: |+
> > +  MediaTek MT7621 PCIe subsys supports single Root complex (RC)
> > +  with 3 Root Ports. Each Root Ports supports a Gen1 1-lane Link
> > +
> > +allOf:
> > +  - $ref: /schemas/pci/pci-bus.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    const: mediatek,mt7621-pci
> > +
> > +  reg:
> > +    items:
> > +      - description: host-pci bridge registers
> > +      - description: pcie port 0 RC control registers
> > +      - description: pcie port 1 RC control registers
> > +      - description: pcie port 2 RC control registers
>
> Are these config space registers or MT7621 specific?

All of them are MT7621 specific.

>
> > +
> > +  ranges:
> > +    maxItems: 2
> > +
> > +  interrupts:
> > +    maxItems: 3
>
> What are the 3 interrupts?

These are one interrupt per root port. In next version this will
change in favour of using interrupt-map and interrupt-map-mask instead
of use interrupts and a custom 'map_irq' callback in driver code.
Please see:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing&id=aed0b711cc791d075e716c397ff6b26bf50345a6
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing&id=3e278e3064511b1606d406db0e26b2fee593fb55

This is the way used in mt7623 already mainlined binding.

> > +
> > +  resets:
> > +    items:
> > +      - description: pcie port 0 reset.
> > +      - description: pcie port 1 reset.
> > +      - description: pcie port 2 reset.
>
> This and clocks should perhaps be in each child node.

I followed here style in mt7623 already mainlined bindings which are
in the main node. Is there a strong reason to be changed into child
nodes or can I maintain this as it is?

>
> > +
> > +  reset-names:
> > +    items:
> > +      - const: pcie0
> > +      - const: pcie1
> > +      - const: pcie2
> > +
> > +  clocks:
> > +    items:
> > +      - description: pcie port 0 clock.
> > +      - description: pcie port 1 clock.
> > +      - description: pcie port 2 clock.
> > +
> > +  clock-names:
> > +    items:
> > +      - const: pcie0
> > +      - const: pcie1
> > +      - const: pcie2
> > +
> > +  phys:
> > +    items:
> > +      - description: Dual-ported phy for pcie port 0 and 1.
> > +      - description: Phy for pcie port 2.
> > +
> > +  phy-names:
> > +    items:
> > +      - const: pcie-phy0
> > +      - const: pcie-phy2
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - ranges
> > +  - interrupts
> > +  - resets
> > +  - reset-names
> > +  - clocks
> > +  - clock-names
> > +  - phys
> > +  - phy-names
> > +  - reset-gpios
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/gpio/gpio.h>
> > +    #include <dt-bindings/interrupt-controller/mips-gic.h>
> > +
> > +    pcie: pcie@1e140000 {
> > +        compatible = "mediatek,mt7621-pci";
> > +        reg = <0x1e140000 0x100>,
> > +              <0x1e142000 0x100>,
> > +              <0x1e143000 0x100>,
> > +              <0x1e144000 0x100>;
> > +
> > +        #address-cells = <3>;
> > +        #size-cells = <2>;
> > +        pinctrl-names = "default";
> > +        pinctrl-0 = <&pcie_pins>;
> > +        device_type = "pci";
> > +        bus-range = <0 255>;
>
> That's the default, so not needed.

Ok, will drop this.

>
> > +        ranges = <0x02000000 0 0x00000000 0x60000000 0 0x10000000>,  /* pci memory */
> > +                 <0x01000000 0 0x00000000 0x1e160000 0 0x00010000>;  /* io space */
> > +        interrupt-parent = <&gic>;
> > +        interrupts = <GIC_SHARED 4 IRQ_TYPE_LEVEL_HIGH>,
> > +                     <GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>,
> > +                     <GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;
> > +        resets = <&rstctrl 24>, <&rstctrl 25>, <&rstctrl 26>;
> > +        reset-names = "pcie0", "pcie1", "pcie2";
> > +        clocks = <&clkctrl 24>, <&clkctrl 25>, <&clkctrl 26>;
> > +        clock-names = "pcie0", "pcie1", "pcie2";
> > +        phys = <&pcie0_phy 1>, <&pcie2_phy 0>;
> > +        phy-names = "pcie-phy0", "pcie-phy2";
> > +        reset-gpios = <&gpio 19 GPIO_ACTIVE_LOW>;
> > +
> > +        pcie@0,0 {
> > +            reg = <0x0000 0 0 0 0>;
> > +            #address-cells = <3>;
> > +            #size-cells = <2>;
> > +            device_type = "pci";
> > +            ranges;
> > +            bus-range = <0x00 0xff>;
>
> Besides being the default, I don't think this makes sense here as it
> belongs in the parent unless you had some subset of bus numbers allowed
> by the parent.

That's not the case so I will drop bus-ranges property from all the
child nodes also.
>
> > +        };
> > +
> > +        pcie@1,0 {
> > +            reg = <0x0800 0 0 0 0>;
> > +            #address-cells = <3>;
> > +            #size-cells = <2>;
> > +            device_type = "pci";
> > +            ranges;
> > +            bus-range = <0x00 0xff>;
> > +        };
> > +
> > +        pcie@2,0 {
> > +            reg = <0x1000 0 0 0 0>;
> > +            #address-cells = <3>;
> > +            #size-cells = <2>;
> > +            device_type = "pci";
> > +            ranges;
> > +            bus-range = <0x00 0xff>;
> > +        };
> > +    };
> > +...

Best regards,
    Sergio Paracuellos

  reply	other threads:[~2021-05-06 16:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-01 13:36 [PATCH] dt-bindings: staging: mt7621-pci: PCIe binding documentation for MT76721 SoCs Sergio Paracuellos
2021-05-06 15:18 ` Rob Herring
2021-05-06 16:41   ` Sergio Paracuellos [this message]
2021-05-06 16:41     ` Sergio Paracuellos
2021-05-07 20:38     ` Rob Herring
2021-05-07 20:38       ` Rob Herring
2021-05-08  5:46       ` Sergio Paracuellos
2021-05-08  5:46         ` Sergio Paracuellos

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='CAMhs-H_Ae4Erx06j2fGSiZXpGo9UWRAkSPPQhFGnZ1D8=NM8cg@mail.gmail.com' \
    --to=sergio.paracuellos@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=neil@brown.name \
    --cc=robh@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.