Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1638490 > unrolled thread

[PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe Ryder Lee <ryder.lee@mediatek.com> - 2017-05-10 04:10 +0200
    Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe Arnd Bergmann <arnd@arndb.de> - 2017-05-10 10:10 +0200
      Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for  Mediatek PCIe Ryder Lee <ryder.lee@mediatek.com> - 2017-05-10 11:40 +0200
        Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe Arnd Bergmann <arnd@arndb.de> - 2017-05-10 12:10 +0200
          Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for  Mediatek PCIe Ryder Lee <ryder.lee@mediatek.com> - 2017-05-11 04:50 +0200
            Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe Arnd Bergmann <arnd@arndb.de> - 2017-05-11 09:20 +0200
              Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for  Mediatek PCIe Ryder Lee <ryder.lee@mediatek.com> - 2017-05-11 11:10 +0200
                Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for  Mediatek PCIe Ryder Lee <ryder.lee@mediatek.com> - 2017-05-11 14:20 +0200
    Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek  PCIe Matthias Brugger <matthias.bgg@gmail.com> - 2017-05-10 10:10 +0200
      Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for  Mediatek PCIe Ryder Lee <ryder.lee@mediatek.com> - 2017-05-10 11:40 +0200

#1638490 — [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

Add documentation for PCIe host driver available in MT7623
series SoCs.

Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/pci/mediatek,mt7623-pcie.txt          | 149 +++++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
new file mode 100644
index 0000000..a9393ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
@@ -0,0 +1,149 @@
+Mediatek Gen2 PCIe controller which is available on MT7623 series SoCs
+
+PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root
+ports supports a Gen2 1-lane Link and has PIPE interface to PHY.
+
+Required properties:
+- compatible: Should contain "mediatek,mt7623-pcie".
+- device_type: Must be "pci"
+- reg: Base addresses and lengths of the PCIe controller.
+- #address-cells: Address representation for root ports (must be 3)
+- #size-cells: Size representation for root ports (must be 2)
+- #interrupt-cells: Size representation for interrupts (must be 1)
+- interrupts: Three interrupt outputs of the controller. Must contain an
+  entry for each entry in the interrupt-names property.
+- interrupt-names: Must include the following names
+  - "pcie-int0"
+  - "pcie-int1"
+  - "pcie-int2"
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - free_ck :for reference clock of PCIe subsys
+  - sys_ck0 :for clock of Port0
+  - sys_ck1 :for clock of Port1
+  - sys_ck2 :for clock of Port2
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - pcie-rst0 :port0 reset
+  - pcie-rst1 :port1 reset
+  - pcie-rst2 :port2 reset
+- phys: list of PHY specifiers (used by generic PHY framework).
+- phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
+  number of PHYs as specified in *phys* property.
+- power-domains: A phandle and power domain specifier pair to the power domain
+  which is responsible for collapsing and restoring power to the peripheral.
+- bus-range: Range of bus numbers associated with this controller.
+- ranges:
+  - The first three entries are expected to translate the addresses for the root
+    port registers, which are referenced by the assigned-addresses property of
+    the root port nodes (see below).
+  - The remaining entries setup the mapping for the standard I/O and memory
+	regions.
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+
+In addition, the device tree node must have sub-nodes describing each
+PCIe port interface, having the following mandatory properties:
+
+Required properties:
+- device_type: Must be "pci"
+- assigned-addresses: Address and size of the port configuration registers
+- reg: Only the first four bytes are used to refer to the correct bus number
+  and device number.
+- #address-cells: Must be 3
+- #size-cells: Must be 2
+- #interrupt-cells: Must be 1
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- ranges: Sub-ranges distributed from the PCIe controller node. An empty
+  property is sufficient.
+- num-lanes: Number of lanes to use for this port.
+
+Examples:
+
+	hifsys: syscon@1a000000 {
+		compatible = "mediatek,mt7623-hifsys", "syscon";
+		reg = <0 0x1a000000 0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	pcie: pcie-controller@1a140000 {
+		compatible = "mediatek,mt7623-pcie";
+		device_type = "pci";
+		reg = <0 0x1a140000 0 0x1000>; /* PCIe shared registers */
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-names = "pcie-int0", "pcie-int1", "pcie-int2";
+		interrupt-map-mask = <0xf800 0 0 0>;
+		interrupt-map = <0x0000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
+				<0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
+				<0x1000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;
+		clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
+			 <&hifsys CLK_HIFSYS_PCIE0>,
+			 <&hifsys CLK_HIFSYS_PCIE1>,
+			 <&hifsys CLK_HIFSYS_PCIE2>;
+		clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
+		resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>,
+			 <&hifsys MT2701_HIFSYS_PCIE1_RST>,
+			 <&hifsys MT2701_HIFSYS_PCIE2_RST>;
+		reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
+		phys = <&pcie0_phy>, <&pcie1_phy>, <&pcie2_phy>;
+		phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+		power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>;
+		bus-range = <0x00 0xff>;
+		ranges = <0x82000000 0 0x1a142000 0 0x1a142000 0 0x1000 /* Port0 registers */
+			  0x82000000 0 0x1a143000 0 0x1a143000 0 0x1000 /* Port1 registers */
+			  0x82000000 0 0x1a144000 0 0x1a144000 0 0x1000 /* Port2 registers */
+			  0x81000000 0 0x1a160000 0 0x1a160000 0 0x00010000 /* I/O space */
+			  0x83000000 0 0x60000000 0 0x60000000 0 0x10000000>;	/* memory space */
+
+		pcie@0,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82000000 0 0x1a142000 0 0x1000>;
+			reg = <0x0000 0 0 0 0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0>;
+			interrupt-map = <0 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>;
+			ranges;
+			num-lanes = <1>;
+		};
+
+		pcie@1,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82000800 0 0x1a143000 0 0x1000>;
+			reg = <0x0800 0 0 0 0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0>;
+			interrupt-map = <0 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>;
+			ranges;
+			num-lanes = <1>;
+		};
+
+		pcie@2,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82001000 0 0x1a144000 0 0x1000>;
+			reg = <0x1000 0 0 0 0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0>;
+			interrupt-map = <0 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;
+			ranges;
+			num-lanes = <1>;
+		};
+	};
-- 
1.9.1

[toc] | [next] | [standalone]

#1638633

On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:

> +- ranges:
> +  - The first three entries are expected to translate the addresses for the root
> +    port registers, which are referenced by the assigned-addresses property of
> +    the root port nodes (see below).

I don't understand this part. Why do you need a static translation for these?
Shouldn't they just be listed in the 'reg' property of the parent node now that
you have the clk/reset/phy properties in the parent as well?

> +Required properties:
> +- device_type: Must be "pci"
> +- assigned-addresses: Address and size of the port configuration registers
> +- reg: Only the first four bytes are used to refer to the correct bus number
> +  and device number.
> +- #address-cells: Must be 3
> +- #size-cells: Must be 2
> +- #interrupt-cells: Must be 1
> +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> +  Please refer to the standard PCI bus binding document for a more detailed
> +  explanation.

Child nodes do not normally have interrupt-map properties. Isn't this
already covered by the interrupt-map in the parent?

      Arnd

[toc] | [prev] | [next] | [standalone]

#1638714 — Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> 
> > +- ranges:
> > +  - The first three entries are expected to translate the addresses for the root
> > +    port registers, which are referenced by the assigned-addresses property of
> > +    the root port nodes (see below).
> 
> I don't understand this part. Why do you need a static translation for these?
> Shouldn't they just be listed in the 'reg' property of the parent node now that
> you have the clk/reset/phy properties in the parent as well?

At first, I did like that. But I noticed that someone suggest it's
better to use 'assigned-addresses' to handle per-port registers, the
same path as tegra and marvell did, in other platform discussion thread.
So I just put shared register in root node. It could be rolled back if
you feel this is inappropriate.

> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > +  and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- #interrupt-cells: Must be 1
> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> 
> Child nodes do not normally have interrupt-map properties. Isn't this
> already covered by the interrupt-map in the parent?
> 

I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
(0000:00:02), probe message looks good to me.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 224
pci 0000:01:00.0: assigning IRQ 224
pci 0000:01:00.1: fixup irq: got 224
pci 0000:01:00.1: assigning IRQ 224
pci 0000:01:00.2: fixup irq: got 224
pci 0000:01:00.2: assigning IRQ 224
pci 0000:01:00.3: fixup irq: got 224
pci 0000:01:00.3: assigning IRQ 224

pci 0000:02:00.0: fixup irq: got 225
pci 0000:02:00.0: assigning IRQ 225


But child nodes without interrupt-map properties:
It seems incorrect.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 223
pci 0000:01:00.0: assigning IRQ 223
pci 0000:01:00.1: fixup irq: got 223
pci 0000:01:00.1: assigning IRQ 223
pci 0000:01:00.2: fixup irq: got 223
pci 0000:01:00.2: assigning IRQ 223
pci 0000:01:00.3: fixup irq: got 223
pci 0000:01:00.3: assigning IRQ 223

pci 0000:02:00.0: fixup irq: got 223
pci 0000:02:00.0: assigning IRQ 223

[toc] | [prev] | [next] | [standalone]

#1638724

On Wed, May 10, 2017 at 11:31 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
>> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>>
>> > +- ranges:
>> > +  - The first three entries are expected to translate the addresses for the root
>> > +    port registers, which are referenced by the assigned-addresses property of
>> > +    the root port nodes (see below).
>>
>> I don't understand this part. Why do you need a static translation for these?
>> Shouldn't they just be listed in the 'reg' property of the parent node now that
>> you have the clk/reset/phy properties in the parent as well?
>
> At first, I did like that. But I noticed that someone suggest it's
> better to use 'assigned-addresses' to handle per-port registers, the
> same path as tegra and marvell did, in other platform discussion thread.
> So I just put shared register in root node. It could be rolled back if
> you feel this is inappropriate.

The marvell case is not a good example for your case: their top-level
device is made up by the OS to help with the shared resource allocation,
while in your case the bus bridge actually exists in hardware.

I'm not too familiar with the Tegra case, and haven't looked at that here,
but it could be an artifact of how for a while we used to list the config
space access in the top-level "ranges" instead of the "reg" property.

I'd vote for moving it back, for consistency with the other port specific
properties that are now in the root node. Once you do that, the port
nodes can be removed completely, which is what I was aiming for with
the comments on the previous version.

>> > +Required properties:
>> > +- device_type: Must be "pci"
>> > +- assigned-addresses: Address and size of the port configuration registers
>> > +- reg: Only the first four bytes are used to refer to the correct bus number
>> > +  and device number.
>> > +- #address-cells: Must be 3
>> > +- #size-cells: Must be 2
>> > +- #interrupt-cells: Must be 1
>> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
>> > +  Please refer to the standard PCI bus binding document for a more detailed
>> > +  explanation.
>>
>> Child nodes do not normally have interrupt-map properties. Isn't this
>> already covered by the interrupt-map in the parent?
>>
>
> I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
> (0000:00:02), probe message looks good to me.
>
> pci 0000:00:01.0: fixup irq: got 224
> pci 0000:00:01.0: assigning IRQ 224
> pci 0000:00:02.0: fixup irq: got 225
> pci 0000:00:02.0: assigning IRQ 225
>
> pci 0000:01:00.0: fixup irq: got 224
> pci 0000:01:00.0: assigning IRQ 224
> pci 0000:01:00.1: fixup irq: got 224
> pci 0000:01:00.1: assigning IRQ 224
> pci 0000:01:00.2: fixup irq: got 224
> pci 0000:01:00.2: assigning IRQ 224
> pci 0000:01:00.3: fixup irq: got 224
> pci 0000:01:00.3: assigning IRQ 224
>
> pci 0000:02:00.0: fixup irq: got 225
> pci 0000:02:00.0: assigning IRQ 225
>
>
> But child nodes without interrupt-map properties:
> It seems incorrect.
>
> pci 0000:00:01.0: fixup irq: got 224
> pci 0000:00:01.0: assigning IRQ 224
> pci 0000:00:02.0: fixup irq: got 225
> pci 0000:00:02.0: assigning IRQ 225
>
> pci 0000:01:00.0: fixup irq: got 223
> pci 0000:01:00.0: assigning IRQ 223

Not entirely sure what happens here, but I guess the problem
is that the 'reg' portion of the parent interrupt-map refers to
the port devices, not the devices attached the devices behind
them.

On a related note, I see that you still list

> +- interrupts: Three interrupt outputs of the controller. Must contain an
> +  entry for each entry in the interrupt-names property.
> +- interrupt-names: Must include the following names
> +  - "pcie-int0"
> +  - "pcie-int1"
> +  - "pcie-int2"

This seems to be an artifact from the older version and should be
removed as the driver correctly ignores the properties now.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1639164 — Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Wed, 2017-05-10 at 12:01 +0200, Arnd Bergmann wrote:
> On Wed, May 10, 2017 at 11:31 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> > On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> >> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> >>
> >> > +- ranges:
> >> > +  - The first three entries are expected to translate the addresses for the root
> >> > +    port registers, which are referenced by the assigned-addresses property of
> >> > +    the root port nodes (see below).
> >>
> >> I don't understand this part. Why do you need a static translation for these?
> >> Shouldn't they just be listed in the 'reg' property of the parent node now that
> >> you have the clk/reset/phy properties in the parent as well?
> >
> > At first, I did like that. But I noticed that someone suggest it's
> > better to use 'assigned-addresses' to handle per-port registers, the
> > same path as tegra and marvell did, in other platform discussion thread.
> > So I just put shared register in root node. It could be rolled back if
> > you feel this is inappropriate.
> 
> The marvell case is not a good example for your case: their top-level
> device is made up by the OS to help with the shared resource allocation,
> while in your case the bus bridge actually exists in hardware.
> 
> I'm not too familiar with the Tegra case, and haven't looked at that here,
> but it could be an artifact of how for a while we used to list the config
> space access in the top-level "ranges" instead of the "reg" property.
> 
> I'd vote for moving it back, for consistency with the other port specific
> properties that are now in the root node. Once you do that, the port
> nodes can be removed completely, which is what I was aiming for with
> the comments on the previous version.
 
I'll move it back.

> >> > +Required properties:
> >> > +- device_type: Must be "pci"
> >> > +- assigned-addresses: Address and size of the port configuration registers
> >> > +- reg: Only the first four bytes are used to refer to the correct bus number
> >> > +  and device number.
> >> > +- #address-cells: Must be 3
> >> > +- #size-cells: Must be 2
> >> > +- #interrupt-cells: Must be 1
> >> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> >> > +  Please refer to the standard PCI bus binding document for a more detailed
> >> > +  explanation.
> >>
> >> Child nodes do not normally have interrupt-map properties. Isn't this
> >> already covered by the interrupt-map in the parent?
> >>
> >
> > I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
> > (0000:00:02), probe message looks good to me.
> >
> > pci 0000:00:01.0: fixup irq: got 224
> > pci 0000:00:01.0: assigning IRQ 224
> > pci 0000:00:02.0: fixup irq: got 225
> > pci 0000:00:02.0: assigning IRQ 225
> >
> > pci 0000:01:00.0: fixup irq: got 224
> > pci 0000:01:00.0: assigning IRQ 224
> > pci 0000:01:00.1: fixup irq: got 224
> > pci 0000:01:00.1: assigning IRQ 224
> > pci 0000:01:00.2: fixup irq: got 224
> > pci 0000:01:00.2: assigning IRQ 224
> > pci 0000:01:00.3: fixup irq: got 224
> > pci 0000:01:00.3: assigning IRQ 224
> >
> > pci 0000:02:00.0: fixup irq: got 225
> > pci 0000:02:00.0: assigning IRQ 225
> >
> >
> > But child nodes without interrupt-map properties:
> > It seems incorrect.
> >
> > pci 0000:00:01.0: fixup irq: got 224
> > pci 0000:00:01.0: assigning IRQ 224
> > pci 0000:00:02.0: fixup irq: got 225
> > pci 0000:00:02.0: assigning IRQ 225
> >
> > pci 0000:01:00.0: fixup irq: got 223
> > pci 0000:01:00.0: assigning IRQ 223
> 
> Not entirely sure what happens here, but I guess the problem
> is that the 'reg' portion of the parent interrupt-map refers to
> the port devices, not the devices attached the devices behind
> them.

I agree with you. That's why I need additional interrupt-map properties
to resolve IRQ correctly for the devices behind root ports.

Not sure whether other platforms have similar case like me here.

> On a related note, I see that you still list
> 
> > +- interrupts: Three interrupt outputs of the controller. Must contain an
> > +  entry for each entry in the interrupt-names property.
> > +- interrupt-names: Must include the following names
> > +  - "pcie-int0"
> > +  - "pcie-int1"
> > +  - "pcie-int2"
> 
> This seems to be an artifact from the older version and should be
> removed as the driver correctly ignores the properties now.

Actually, everything works fine without these properties however when it
loads we see a few weird error message:

pcieport 0000:00:01.0: Signaling PME with IRQ 232
pcieport 0000:00:02.0: enabling device (0140 -> 0142)
pcieport 0000:00:02.0: enabling bus mastering
irq 232: nobody cared (try booting with the "irqpoll" option)
...
[<c03f6be4>] (pcie_pme_probe) from [<c03f47b8>] (pcie_port_probe_service
+0x44/0x6c)
(pcie_port_probe_service) from [<c0454cf8>] (driver_probe_device
+0x280/0x470)
...
(pcie_port_device_register) from [<c03f51a0>] (pcie_portdrv_probe
+0x3c/0xb4)
(pcie_portdrv_probe) from [<c03e7acc>] (pci_device_probe+0x98/0xfc)
(pci_device_probe) from [<c0454cf8>] (driver_probe_device+0x280/0x470)
handlers:
[<c03f68b0>] pcie_pme_irq
Disabling IRQ #233

I haven't dig it out yet, but just keep them here to solve that.

[toc] | [prev] | [next] | [standalone]

#1639212

On Thu, May 11, 2017 at 4:44 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> On Wed, 2017-05-10 at 12:01 +0200, Arnd Bergmann wrote:
>> On Wed, May 10, 2017 at 11:31 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:

>> >> > +Required properties:
>> >> > +- device_type: Must be "pci"
>> >> > +- assigned-addresses: Address and size of the port configuration registers
>> >> > +- reg: Only the first four bytes are used to refer to the correct bus number
>> >> > +  and device number.
>> >> > +- #address-cells: Must be 3
>> >> > +- #size-cells: Must be 2
>> >> > +- #interrupt-cells: Must be 1
>> >> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
>> >> > +  Please refer to the standard PCI bus binding document for a more detailed
>> >> > +  explanation.
>> >>
>> >> Child nodes do not normally have interrupt-map properties. Isn't this
>> >> already covered by the interrupt-map in the parent?
>> >>
>> >
>> > I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
>> > (0000:00:02), probe message looks good to me.
>> >
>> > pci 0000:00:01.0: fixup irq: got 224
>> > pci 0000:00:01.0: assigning IRQ 224
>> > pci 0000:00:02.0: fixup irq: got 225
>> > pci 0000:00:02.0: assigning IRQ 225
>> >
>> > pci 0000:01:00.0: fixup irq: got 224
>> > pci 0000:01:00.0: assigning IRQ 224
>> > pci 0000:01:00.1: fixup irq: got 224
>> > pci 0000:01:00.1: assigning IRQ 224
>> > pci 0000:01:00.2: fixup irq: got 224
>> > pci 0000:01:00.2: assigning IRQ 224
>> > pci 0000:01:00.3: fixup irq: got 224
>> > pci 0000:01:00.3: assigning IRQ 224
>> >
>> > pci 0000:02:00.0: fixup irq: got 225
>> > pci 0000:02:00.0: assigning IRQ 225
>> >
>> >
>> > But child nodes without interrupt-map properties:
>> > It seems incorrect.
>> >
>> > pci 0000:00:01.0: fixup irq: got 224
>> > pci 0000:00:01.0: assigning IRQ 224
>> > pci 0000:00:02.0: fixup irq: got 225
>> > pci 0000:00:02.0: assigning IRQ 225
>> >
>> > pci 0000:01:00.0: fixup irq: got 223
>> > pci 0000:01:00.0: assigning IRQ 223
>>
>> Not entirely sure what happens here, but I guess the problem
>> is that the 'reg' portion of the parent interrupt-map refers to
>> the port devices, not the devices attached the devices behind
>> them.
>
> I agree with you. That's why I need additional interrupt-map properties
> to resolve IRQ correctly for the devices behind root ports.
>
> Not sure whether other platforms have similar case like me here.

I think it's just a bug in this specific chip where the HW designers
wired the IRQs in a nonstandard way.

However, you really should not need the interrupt-map properties
in the child nodes, just change the address part in the parent
interrupt-map. Specifically, the 'bus' portion of the device address
in the interrupt-map would have to be nonzero to refer to
child devices.

>> On a related note, I see that you still list
>>
>> > +- interrupts: Three interrupt outputs of the controller. Must contain an
>> > +  entry for each entry in the interrupt-names property.
>> > +- interrupt-names: Must include the following names
>> > +  - "pcie-int0"
>> > +  - "pcie-int1"
>> > +  - "pcie-int2"
>>
>> This seems to be an artifact from the older version and should be
>> removed as the driver correctly ignores the properties now.
>
> Actually, everything works fine without these properties however when it
> loads we see a few weird error message:
>
> pcieport 0000:00:01.0: Signaling PME with IRQ 232
> pcieport 0000:00:02.0: enabling device (0140 -> 0142)
> pcieport 0000:00:02.0: enabling bus mastering
> irq 232: nobody cared (try booting with the "irqpoll" option)
> ...
> [<c03f6be4>] (pcie_pme_probe) from [<c03f47b8>] (pcie_port_probe_service
> +0x44/0x6c)
> (pcie_port_probe_service) from [<c0454cf8>] (driver_probe_device
> +0x280/0x470)
> ...
> (pcie_port_device_register) from [<c03f51a0>] (pcie_portdrv_probe
> +0x3c/0xb4)
> (pcie_portdrv_probe) from [<c03e7acc>] (pci_device_probe+0x98/0xfc)
> (pci_device_probe) from [<c0454cf8>] (driver_probe_device+0x280/0x470)
> handlers:
> [<c03f68b0>] pcie_pme_irq
> Disabling IRQ #233
>
> I haven't dig it out yet, but just keep them here to solve that.

Something is going very wrong if adding the properties helps. I can't
think of what that is, but we have to find out before the binding can
be merged.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1639264 — Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Thu, 2017-05-11 at 09:17 +0200, Arnd Bergmann wrote:
> On Thu, May 11, 2017 at 4:44 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> > On Wed, 2017-05-10 at 12:01 +0200, Arnd Bergmann wrote:
> >> On Wed, May 10, 2017 at 11:31 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> >> > On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> 
> >> >> > +Required properties:
> >> >> > +- device_type: Must be "pci"
> >> >> > +- assigned-addresses: Address and size of the port configuration registers
> >> >> > +- reg: Only the first four bytes are used to refer to the correct bus number
> >> >> > +  and device number.
> >> >> > +- #address-cells: Must be 3
> >> >> > +- #size-cells: Must be 2
> >> >> > +- #interrupt-cells: Must be 1
> >> >> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> >> >> > +  Please refer to the standard PCI bus binding document for a more detailed
> >> >> > +  explanation.
> >> >>
> >> >> Child nodes do not normally have interrupt-map properties. Isn't this
> >> >> already covered by the interrupt-map in the parent?
> >> >>
> >> >
> >> > I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
> >> > (0000:00:02), probe message looks good to me.
> >> >
> >> > pci 0000:00:01.0: fixup irq: got 224
> >> > pci 0000:00:01.0: assigning IRQ 224
> >> > pci 0000:00:02.0: fixup irq: got 225
> >> > pci 0000:00:02.0: assigning IRQ 225
> >> >
> >> > pci 0000:01:00.0: fixup irq: got 224
> >> > pci 0000:01:00.0: assigning IRQ 224
> >> > pci 0000:01:00.1: fixup irq: got 224
> >> > pci 0000:01:00.1: assigning IRQ 224
> >> > pci 0000:01:00.2: fixup irq: got 224
> >> > pci 0000:01:00.2: assigning IRQ 224
> >> > pci 0000:01:00.3: fixup irq: got 224
> >> > pci 0000:01:00.3: assigning IRQ 224
> >> >
> >> > pci 0000:02:00.0: fixup irq: got 225
> >> > pci 0000:02:00.0: assigning IRQ 225
> >> >
> >> >
> >> > But child nodes without interrupt-map properties:
> >> > It seems incorrect.
> >> >
> >> > pci 0000:00:01.0: fixup irq: got 224
> >> > pci 0000:00:01.0: assigning IRQ 224
> >> > pci 0000:00:02.0: fixup irq: got 225
> >> > pci 0000:00:02.0: assigning IRQ 225
> >> >
> >> > pci 0000:01:00.0: fixup irq: got 223
> >> > pci 0000:01:00.0: assigning IRQ 223
> >>
> >> Not entirely sure what happens here, but I guess the problem
> >> is that the 'reg' portion of the parent interrupt-map refers to
> >> the port devices, not the devices attached the devices behind
> >> them.
> >
> > I agree with you. That's why I need additional interrupt-map properties
> > to resolve IRQ correctly for the devices behind root ports.
> >
> > Not sure whether other platforms have similar case like me here.
> 
> I think it's just a bug in this specific chip where the HW designers
> wired the IRQs in a nonstandard way.
> 
> However, you really should not need the interrupt-map properties
> in the child nodes, just change the address part in the parent
> interrupt-map. Specifically, the 'bus' portion of the device address
> in the interrupt-map would have to be nonzero to refer to
> child devices.

This is what I modify for the parent node and remove interrupt-map
properties from child..

interrupt-map-mask = <0xff800 0 0 0>;
interrupt-map = <0x0000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
		 <0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
		 <0x1000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>,

		 /* workaround here*/
		 <0x10000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
		 <0x20000 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
	     <0x30000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;

It works well. But how could we handle the situation if root port0
status = "disabled" ? I think we cannot assign child bus number
dynamically from binding.

> >> On a related note, I see that you still list
> >>
> >> > +- interrupts: Three interrupt outputs of the controller. Must contain an
> >> > +  entry for each entry in the interrupt-names property.
> >> > +- interrupt-names: Must include the following names
> >> > +  - "pcie-int0"
> >> > +  - "pcie-int1"
> >> > +  - "pcie-int2"
> >>
> >> This seems to be an artifact from the older version and should be
> >> removed as the driver correctly ignores the properties now.
> >
> > Actually, everything works fine without these properties however when it
> > loads we see a few weird error message:
> >
> > pcieport 0000:00:01.0: Signaling PME with IRQ 232
> > pcieport 0000:00:02.0: enabling device (0140 -> 0142)
> > pcieport 0000:00:02.0: enabling bus mastering
> > irq 232: nobody cared (try booting with the "irqpoll" option)
> > ...
> > [<c03f6be4>] (pcie_pme_probe) from [<c03f47b8>] (pcie_port_probe_service
> > +0x44/0x6c)
> > (pcie_port_probe_service) from [<c0454cf8>] (driver_probe_device
> > +0x280/0x470)
> > ...
> > (pcie_port_device_register) from [<c03f51a0>] (pcie_portdrv_probe
> > +0x3c/0xb4)
> > (pcie_portdrv_probe) from [<c03e7acc>] (pci_device_probe+0x98/0xfc)
> > (pci_device_probe) from [<c0454cf8>] (driver_probe_device+0x280/0x470)
> > handlers:
> > [<c03f68b0>] pcie_pme_irq
> > Disabling IRQ #233
> >
> > I haven't dig it out yet, but just keep them here to solve that.
> 
> Something is going very wrong if adding the properties helps. I can't
> think of what that is, but we have to find out before the binding can
> be merged.

Not really understand PME service. But I will find the reason here.

[toc] | [prev] | [next] | [standalone]

#1639344 — Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

Hi Arnd,

I want to further explain what I have discussed in previous mail.


On Thu, 2017-05-11 at 17:08 +0800, Ryder Lee wrote:
> On Thu, 2017-05-11 at 09:17 +0200, Arnd Bergmann wrote:
> > On Thu, May 11, 2017 at 4:44 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> > > On Wed, 2017-05-10 at 12:01 +0200, Arnd Bergmann wrote:
> > >> On Wed, May 10, 2017 at 11:31 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> > >> > On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> > 
> > >> >> > +Required properties:
> > >> >> > +- device_type: Must be "pci"
> > >> >> > +- assigned-addresses: Address and size of the port configuration registers
> > >> >> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > >> >> > +  and device number.
> > >> >> > +- #address-cells: Must be 3
> > >> >> > +- #size-cells: Must be 2
> > >> >> > +- #interrupt-cells: Must be 1
> > >> >> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > >> >> > +  Please refer to the standard PCI bus binding document for a more detailed
> > >> >> > +  explanation.
> > >> >>
> > >> >> Child nodes do not normally have interrupt-map properties. Isn't this
> > >> >> already covered by the interrupt-map in the parent?
> > >> >>
> > >> >
> > >> > I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
> > >> > (0000:00:02), probe message looks good to me.
> > >> >
> > >> > pci 0000:00:01.0: fixup irq: got 224
> > >> > pci 0000:00:01.0: assigning IRQ 224
> > >> > pci 0000:00:02.0: fixup irq: got 225
> > >> > pci 0000:00:02.0: assigning IRQ 225
> > >> >
> > >> > pci 0000:01:00.0: fixup irq: got 224
> > >> > pci 0000:01:00.0: assigning IRQ 224
> > >> > pci 0000:01:00.1: fixup irq: got 224
> > >> > pci 0000:01:00.1: assigning IRQ 224
> > >> > pci 0000:01:00.2: fixup irq: got 224
> > >> > pci 0000:01:00.2: assigning IRQ 224
> > >> > pci 0000:01:00.3: fixup irq: got 224
> > >> > pci 0000:01:00.3: assigning IRQ 224
> > >> >
> > >> > pci 0000:02:00.0: fixup irq: got 225
> > >> > pci 0000:02:00.0: assigning IRQ 225
> > >> >
> > >> >
> > >> > But child nodes without interrupt-map properties:
> > >> > It seems incorrect.
> > >> >
> > >> > pci 0000:00:01.0: fixup irq: got 224
> > >> > pci 0000:00:01.0: assigning IRQ 224
> > >> > pci 0000:00:02.0: fixup irq: got 225
> > >> > pci 0000:00:02.0: assigning IRQ 225
> > >> >
> > >> > pci 0000:01:00.0: fixup irq: got 223
> > >> > pci 0000:01:00.0: assigning IRQ 223
> > >>
> > >> Not entirely sure what happens here, but I guess the problem
> > >> is that the 'reg' portion of the parent interrupt-map refers to
> > >> the port devices, not the devices attached the devices behind
> > >> them.
> > >
> > > I agree with you. That's why I need additional interrupt-map properties
> > > to resolve IRQ correctly for the devices behind root ports.
> > >
> > > Not sure whether other platforms have similar case like me here.
> > 
> > I think it's just a bug in this specific chip where the HW designers
> > wired the IRQs in a nonstandard way.
> > 
> > However, you really should not need the interrupt-map properties
> > in the child nodes, just change the address part in the parent
> > interrupt-map. Specifically, the 'bus' portion of the device address
> > in the interrupt-map would have to be nonzero to refer to
> > child devices.
> 
> This is what I modify for the parent node and remove interrupt-map
> properties from child..
> 
> interrupt-map-mask = <0xff800 0 0 0>;
> interrupt-map = <0x0000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
> 		 <0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
> 		 <0x1000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>,
> 
> 		 /* workaround here*/
> 		 <0x10000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
> 		 <0x20000 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
> 	     <0x30000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;
> 
> It works well. But how could we handle the situation if root port0
> status = "disabled" ? I think we cannot assign child bus number
> dynamically from binding.

That is to say, we route it statically if port0 (or port1) is
unavailable. The PCI child bus enumeration should look something like
this:

 pci 0000:00:01.0: fixup irq: got 224
 pci 0000:00:01.0: assigning IRQ 224
 pci 0000:00:02.0: fixup irq: got 225
 pci 0000:00:02.0: assigning IRQ 225
 
 Go wrong here! IRQ 223/224 should be assigned to the devices behind
port0 and port1.
 pci 0000:01:00.0: fixup irq: got 223
 pci 0000:01:00.0: assigning IRQ 223
 pci 0000:02:00.0: fixup irq: got 224
 pci 0000:02:00.0: assigning IRQ 224

> > >> On a related note, I see that you still list
> > >>
> > >> > +- interrupts: Three interrupt outputs of the controller. Must contain an
> > >> > +  entry for each entry in the interrupt-names property.
> > >> > +- interrupt-names: Must include the following names
> > >> > +  - "pcie-int0"
> > >> > +  - "pcie-int1"
> > >> > +  - "pcie-int2"
> > >>
> > >> This seems to be an artifact from the older version and should be
> > >> removed as the driver correctly ignores the properties now.
> > >
> > > Actually, everything works fine without these properties however when it
> > > loads we see a few weird error message:
> > >
> > > pcieport 0000:00:01.0: Signaling PME with IRQ 232
> > > pcieport 0000:00:02.0: enabling device (0140 -> 0142)
> > > pcieport 0000:00:02.0: enabling bus mastering
> > > irq 232: nobody cared (try booting with the "irqpoll" option)
> > > ...
> > > [<c03f6be4>] (pcie_pme_probe) from [<c03f47b8>] (pcie_port_probe_service
> > > +0x44/0x6c)
> > > (pcie_port_probe_service) from [<c0454cf8>] (driver_probe_device
> > > +0x280/0x470)
> > > ...
> > > (pcie_port_device_register) from [<c03f51a0>] (pcie_portdrv_probe
> > > +0x3c/0xb4)
> > > (pcie_portdrv_probe) from [<c03e7acc>] (pci_device_probe+0x98/0xfc)
> > > (pci_device_probe) from [<c0454cf8>] (driver_probe_device+0x280/0x470)
> > > handlers:
> > > [<c03f68b0>] pcie_pme_irq
> > > Disabling IRQ #233
> > >
> > > I haven't dig it out yet, but just keep them here to solve that.
> > 
> > Something is going very wrong if adding the properties helps. I can't
> > think of what that is, but we have to find out before the binding can
> > be merged.
> 
> Not really understand PME service. But I will find the reason here.

I have do some test here. PME needs port IRQs, which interrupt type was
set correctly(IRQ_TYPE_LEVEL_LOW). But we cannot set it from
interrupt-map, according to gic_set_type() /* SPIs have restrictions on
the supported types */ .

So we need to add additional interrupt properties.

 

[toc] | [prev] | [next] | [standalone]

#1638637 — Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On 10/05/17 04:07, Ryder Lee wrote:
> Add documentation for PCIe host driver available in MT7623
> series SoCs.
> 
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>   .../bindings/pci/mediatek,mt7623-pcie.txt          | 149 +++++++++++++++++++++
>   1 file changed, 149 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> new file mode 100644
> index 0000000..a9393ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> @@ -0,0 +1,149 @@
> +Mediatek Gen2 PCIe controller which is available on MT7623 series SoCs
> +
> +PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root
> +ports supports a Gen2 1-lane Link and has PIPE interface to PHY.
> +
> +Required properties:
> +- compatible: Should contain "mediatek,mt7623-pcie".
> +- device_type: Must be "pci"
> +- reg: Base addresses and lengths of the PCIe controller.
> +- #address-cells: Address representation for root ports (must be 3)
> +- #size-cells: Size representation for root ports (must be 2)
> +- #interrupt-cells: Size representation for interrupts (must be 1)
> +- interrupts: Three interrupt outputs of the controller. Must contain an
> +  entry for each entry in the interrupt-names property.
> +- interrupt-names: Must include the following names
> +  - "pcie-int0"
> +  - "pcie-int1"
> +  - "pcie-int2"
> +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> +  Please refer to the standard PCI bus binding document for a more detailed
> +  explanation.
> +- clocks: Must contain an entry for each entry in clock-names.
> +  See ../clocks/clock-bindings.txt for details.
> +- clock-names: Must include the following entries:
> +  - free_ck :for reference clock of PCIe subsys
> +  - sys_ck0 :for clock of Port0
> +  - sys_ck1 :for clock of Port1
> +  - sys_ck2 :for clock of Port2
> +- resets: Must contain an entry for each entry in reset-names.
> +  See ../reset/reset.txt for details.
> +- reset-names: Must include the following entries:
> +  - pcie-rst0 :port0 reset
> +  - pcie-rst1 :port1 reset
> +  - pcie-rst2 :port2 reset
> +- phys: list of PHY specifiers (used by generic PHY framework).
> +- phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
> +  number of PHYs as specified in *phys* property.
> +- power-domains: A phandle and power domain specifier pair to the power domain
> +  which is responsible for collapsing and restoring power to the peripheral.
> +- bus-range: Range of bus numbers associated with this controller.
> +- ranges:
> +  - The first three entries are expected to translate the addresses for the root
> +    port registers, which are referenced by the assigned-addresses property of
> +    the root port nodes (see below).
> +  - The remaining entries setup the mapping for the standard I/O and memory
> +	regions.
> +  Please refer to the standard PCI bus binding document for a more detailed
> +  explanation.
> +
> +In addition, the device tree node must have sub-nodes describing each
> +PCIe port interface, having the following mandatory properties:
> +
> +Required properties:
> +- device_type: Must be "pci"
> +- assigned-addresses: Address and size of the port configuration registers
> +- reg: Only the first four bytes are used to refer to the correct bus number
> +  and device number.
> +- #address-cells: Must be 3
> +- #size-cells: Must be 2
> +- #interrupt-cells: Must be 1
> +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> +  Please refer to the standard PCI bus binding document for a more detailed
> +  explanation.
> +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
> +  property is sufficient.
> +- num-lanes: Number of lanes to use for this port.
> +
> +Examples:
> +
> +	hifsys: syscon@1a000000 {
> +		compatible = "mediatek,mt7623-hifsys", "syscon";

If you want to put the clock controller subsystem node to the example, 
please use a valid compatible, for example:

		compatible = "mediatek,mt7623-hifsys",
			     "mediatek,mt2701-hifsys",
			     "syscon";

Thanks,
Matthias

> +		reg = <0 0x1a000000 0 0x1000>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +	pcie: pcie-controller@1a140000 {
> +		compatible = "mediatek,mt7623-pcie";
> +		device_type = "pci";
> +		reg = <0 0x1a140000 0 0x1000>; /* PCIe shared registers */
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +		#interrupt-cells = <1>;
> +		interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
> +		interrupt-names = "pcie-int0", "pcie-int1", "pcie-int2";
> +		interrupt-map-mask = <0xf800 0 0 0>;
> +		interrupt-map = <0x0000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
> +				<0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
> +				<0x1000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;
> +		clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
> +			 <&hifsys CLK_HIFSYS_PCIE0>,
> +			 <&hifsys CLK_HIFSYS_PCIE1>,
> +			 <&hifsys CLK_HIFSYS_PCIE2>;
> +		clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
> +		resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>,
> +			 <&hifsys MT2701_HIFSYS_PCIE1_RST>,
> +			 <&hifsys MT2701_HIFSYS_PCIE2_RST>;
> +		reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
> +		phys = <&pcie0_phy>, <&pcie1_phy>, <&pcie2_phy>;
> +		phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
> +		power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>;
> +		bus-range = <0x00 0xff>;
> +		ranges = <0x82000000 0 0x1a142000 0 0x1a142000 0 0x1000 /* Port0 registers */
> +			  0x82000000 0 0x1a143000 0 0x1a143000 0 0x1000 /* Port1 registers */
> +			  0x82000000 0 0x1a144000 0 0x1a144000 0 0x1000 /* Port2 registers */
> +			  0x81000000 0 0x1a160000 0 0x1a160000 0 0x00010000 /* I/O space */
> +			  0x83000000 0 0x60000000 0 0x60000000 0 0x10000000>;	/* memory space */
> +
> +		pcie@0,0 {
> +			device_type = "pci";
> +			assigned-addresses = <0x82000000 0 0x1a142000 0 0x1000>;
> +			reg = <0x0000 0 0 0 0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 0>;
> +			interrupt-map = <0 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>;
> +			ranges;
> +			num-lanes = <1>;
> +		};
> +
> +		pcie@1,0 {
> +			device_type = "pci";
> +			assigned-addresses = <0x82000800 0 0x1a143000 0 0x1000>;
> +			reg = <0x0800 0 0 0 0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 0>;
> +			interrupt-map = <0 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>;
> +			ranges;
> +			num-lanes = <1>;
> +		};
> +
> +		pcie@2,0 {
> +			device_type = "pci";
> +			assigned-addresses = <0x82001000 0 0x1a144000 0 0x1000>;
> +			reg = <0x1000 0 0 0 0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 0>;
> +			interrupt-map = <0 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;
> +			ranges;
> +			num-lanes = <1>;
> +		};
> +	};
> 

[toc] | [prev] | [next] | [standalone]

#1638713 — Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Wed, 2017-05-10 at 09:58 +0200, Matthias Brugger wrote:
> 
> On 10/05/17 04:07, Ryder Lee wrote:
> > Add documentation for PCIe host driver available in MT7623
> > series SoCs.
> > 
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> >   .../bindings/pci/mediatek,mt7623-pcie.txt          | 149 +++++++++++++++++++++
> >   1 file changed, 149 insertions(+)
> >   create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> > new file mode 100644
> > index 0000000..a9393ce
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> > @@ -0,0 +1,149 @@
> > +Mediatek Gen2 PCIe controller which is available on MT7623 series SoCs
> > +
> > +PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root
> > +ports supports a Gen2 1-lane Link and has PIPE interface to PHY.
> > +
> > +Required properties:
> > +- compatible: Should contain "mediatek,mt7623-pcie".
> > +- device_type: Must be "pci"
> > +- reg: Base addresses and lengths of the PCIe controller.
> > +- #address-cells: Address representation for root ports (must be 3)
> > +- #size-cells: Size representation for root ports (must be 2)
> > +- #interrupt-cells: Size representation for interrupts (must be 1)
> > +- interrupts: Three interrupt outputs of the controller. Must contain an
> > +  entry for each entry in the interrupt-names property.
> > +- interrupt-names: Must include the following names
> > +  - "pcie-int0"
> > +  - "pcie-int1"
> > +  - "pcie-int2"
> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> > +- clocks: Must contain an entry for each entry in clock-names.
> > +  See ../clocks/clock-bindings.txt for details.
> > +- clock-names: Must include the following entries:
> > +  - free_ck :for reference clock of PCIe subsys
> > +  - sys_ck0 :for clock of Port0
> > +  - sys_ck1 :for clock of Port1
> > +  - sys_ck2 :for clock of Port2
> > +- resets: Must contain an entry for each entry in reset-names.
> > +  See ../reset/reset.txt for details.
> > +- reset-names: Must include the following entries:
> > +  - pcie-rst0 :port0 reset
> > +  - pcie-rst1 :port1 reset
> > +  - pcie-rst2 :port2 reset
> > +- phys: list of PHY specifiers (used by generic PHY framework).
> > +- phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
> > +  number of PHYs as specified in *phys* property.
> > +- power-domains: A phandle and power domain specifier pair to the power domain
> > +  which is responsible for collapsing and restoring power to the peripheral.
> > +- bus-range: Range of bus numbers associated with this controller.
> > +- ranges:
> > +  - The first three entries are expected to translate the addresses for the root
> > +    port registers, which are referenced by the assigned-addresses property of
> > +    the root port nodes (see below).
> > +  - The remaining entries setup the mapping for the standard I/O and memory
> > +	regions.
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> > +
> > +In addition, the device tree node must have sub-nodes describing each
> > +PCIe port interface, having the following mandatory properties:
> > +
> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > +  and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- #interrupt-cells: Must be 1
> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> > +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
> > +  property is sufficient.
> > +- num-lanes: Number of lanes to use for this port.
> > +
> > +Examples:
> > +
> > +	hifsys: syscon@1a000000 {
> > +		compatible = "mediatek,mt7623-hifsys", "syscon";
> 
> If you want to put the clock controller subsystem node to the example, 
> please use a valid compatible, for example:
> 
> 		compatible = "mediatek,mt7623-hifsys",
> 			     "mediatek,mt2701-hifsys",
> 			     "syscon";
> 
> Thanks,
> Matthias

OK i will correct it.
> 
> > +		reg = <0 0x1a000000 0 0x1000>;
> > +		#clock-cells = <1>;
> > +		#reset-cells = <1>;
> > +	};
> > +
> > +	pcie: pcie-controller@1a140000 {
> > +		compatible = "mediatek,mt7623-pcie";
> > +		device_type = "pci";
> > +		reg = <0 0x1a140000 0 0x1000>; /* PCIe shared registers */
> > +		#address-cells = <3>;
> > +		#size-cells = <2>;
> > +		#interrupt-cells = <1>;
> > +		interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>,
> > +			     <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>,
> > +			     <GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
> > +		interrupt-names = "pcie-int0", "pcie-int1", "pcie-int2";
> > +		interrupt-map-mask = <0xf800 0 0 0>;
> > +		interrupt-map = <0x0000 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>,
> > +				<0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>,
> > +				<0x1000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;
> > +		clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
> > +			 <&hifsys CLK_HIFSYS_PCIE0>,
> > +			 <&hifsys CLK_HIFSYS_PCIE1>,
> > +			 <&hifsys CLK_HIFSYS_PCIE2>;
> > +		clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
> > +		resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>,
> > +			 <&hifsys MT2701_HIFSYS_PCIE1_RST>,
> > +			 <&hifsys MT2701_HIFSYS_PCIE2_RST>;
> > +		reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
> > +		phys = <&pcie0_phy>, <&pcie1_phy>, <&pcie2_phy>;
> > +		phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
> > +		power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>;
> > +		bus-range = <0x00 0xff>;
> > +		ranges = <0x82000000 0 0x1a142000 0 0x1a142000 0 0x1000 /* Port0 registers */
> > +			  0x82000000 0 0x1a143000 0 0x1a143000 0 0x1000 /* Port1 registers */
> > +			  0x82000000 0 0x1a144000 0 0x1a144000 0 0x1000 /* Port2 registers */
> > +			  0x81000000 0 0x1a160000 0 0x1a160000 0 0x00010000 /* I/O space */
> > +			  0x83000000 0 0x60000000 0 0x60000000 0 0x10000000>;	/* memory space */
> > +
> > +		pcie@0,0 {
> > +			device_type = "pci";
> > +			assigned-addresses = <0x82000000 0 0x1a142000 0 0x1000>;
> > +			reg = <0x0000 0 0 0 0>;
> > +			#address-cells = <3>;
> > +			#size-cells = <2>;
> > +			#interrupt-cells = <1>;
> > +			interrupt-map-mask = <0 0 0 0>;
> > +			interrupt-map = <0 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>;
> > +			ranges;
> > +			num-lanes = <1>;
> > +		};
> > +
> > +		pcie@1,0 {
> > +			device_type = "pci";
> > +			assigned-addresses = <0x82000800 0 0x1a143000 0 0x1000>;
> > +			reg = <0x0800 0 0 0 0>;
> > +			#address-cells = <3>;
> > +			#size-cells = <2>;
> > +			#interrupt-cells = <1>;
> > +			interrupt-map-mask = <0 0 0 0>;
> > +			interrupt-map = <0 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>;
> > +			ranges;
> > +			num-lanes = <1>;
> > +		};
> > +
> > +		pcie@2,0 {
> > +			device_type = "pci";
> > +			assigned-addresses = <0x82001000 0 0x1a144000 0 0x1000>;
> > +			reg = <0x1000 0 0 0 0>;
> > +			#address-cells = <3>;
> > +			#size-cells = <2>;
> > +			#interrupt-cells = <1>;
> > +			interrupt-map-mask = <0 0 0 0>;
> > +			interrupt-map = <0 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>;
> > +			ranges;
> > +			num-lanes = <1>;
> > +		};
> > +	};
> > 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web