All of lore.kernel.org
 help / color / mirror / Atom feed
* IMX6 - PCIe device tree assignments
@ 2015-06-18 10:18 Krzysztof Hałasa
  2015-06-22 13:34 ` Tim Harvey
  0 siblings, 1 reply; 4+ messages in thread
From: Krzysztof Hałasa @ 2015-06-18 10:18 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

The situation: Gateworks Ventana with IMX6q, 8-port PCIe bridge (PLX
tech PEX 8609), two PCIe devices behind the bridge (one of those is an
Ethernet controller).

The Ethernet controller lacks EEPROM/etc. and it's MAC address has to be
initialized using the device tree.

IMX6                      [1]           PEX [2]
-[0000:00]---00.0-[01-0a]--+-00.0-[02-0a]--+-01.0-[03]--
                           |               +-04.0-[04]----00.0
                           |               +-05.0-[05]--
                           |               +-06.0-[06-07]----00.0-[07]--
                           |               +-07.0-[08]----00.0
                           |               +-08.0-[09]----00.0 Ethernet
                           |               \-09.0-[0a]--
                           \-00.1 (PEX special device)

Gateworks have the following patch for this (and the MAC address
assignment works):

--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -369,8 +369,42 @@
 	reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
 	status = "okay";

-	eth1: sky2 at 8 { /* MAC/PHY on bus 8 */
-		compatible = "marvell,sky2";
+	pcie at 0,0 {
+		/* 00:00.0 0604: 16c3:abcd root host-bridge */
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		reg = <0x0 0 0 0 0>;
+
+		pcie at 0,0 {
+			/* 01:00.0 0604: 10b5:8609 PEX switch bridge */
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			reg = <0x0 0 0 0 0>;
+
+			/*
+			 * GigE PCI dev node needs to be defined so that enet
+			 * driver can use it to obtain its boot-loader
+			 * specified MAC
+			 */
+			pcie at 8,0 {
+				/* 02:08.0 0604: 10b5:8609: PEX port bridge */
+				#address-cells = <3>;
+				#size-cells = <2>;
+				device_type = "pci";
+				reg = <0x4000 0 0 0 0>;
+
+				eth1: pci at 0,0 {
+					/* 08:00.0 0200: 11ab:4380: GigE */
+					#address-cells = <3>;
+					#size-cells = <2>;
+					device_type = "pci";
+					reg = <0x0 0 0 0 0>;
+					compatible = "marvell,sky2";
+				};
+			};
+		};
 	};
 };

Unfortunately the patch has a side effect - it messes up the PCIe
interrupts. Basically all PCI IRQs except for the special device handled
internally by the PEX 8609 bridge are set to 155:

                                      good    bad (with patch)
00:00.0 PCI bridge: (IMX6 host bridge)
        Interrupt: pin A routed to IRQ 155
01:00.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 155
01:00.1 System peripheral: PEX-8609
        Interrupt: pin B routed to IRQ 154 (not changed)
02:01.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 154 -> 155
02:04.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 155
02:05.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 154 -> 155
02:06.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 153 -> 155
02:07.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 152 -> 155
02:08.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 155
02:09.0 PCI bridge: PEX-8609
        Interrupt: pin A routed to IRQ 154 -> 155
04:00.0 Techwell Device 6864
        Interrupt: pin A routed to IRQ 155
06:00.0 PCI bridge
08:00.0 Techwell Device 6869
        Interrupt: pin A routed to IRQ 152 -> 155
09:00.0 Ethernet controller
        Interrupt: pin A routed to IRQ 155

This is the case with v3.18 + the Ventana patchset from Gateworks, and
with vanilla v4.0 with only the above DT patch applied.

The question is: what's wrong in the patch, and how do I fix it?
--
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

^ permalink raw reply	[flat|nested] 4+ messages in thread

* IMX6 - PCIe device tree assignments
  2015-06-18 10:18 IMX6 - PCIe device tree assignments Krzysztof Hałasa
@ 2015-06-22 13:34 ` Tim Harvey
  2015-06-26  6:20   ` Krzysztof Hałasa
  0 siblings, 1 reply; 4+ messages in thread
From: Tim Harvey @ 2015-06-22 13:34 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 18, 2015 at 3:18 AM, Krzysztof Ha?asa <khalasa@piap.pl> wrote:
> Hello,
>
> The situation: Gateworks Ventana with IMX6q, 8-port PCIe bridge (PLX
> tech PEX 8609), two PCIe devices behind the bridge (one of those is an
> Ethernet controller).
>
> The Ethernet controller lacks EEPROM/etc. and it's MAC address has to be
> initialized using the device tree.
>
> IMX6                      [1]           PEX [2]
> -[0000:00]---00.0-[01-0a]--+-00.0-[02-0a]--+-01.0-[03]--
>                            |               +-04.0-[04]----00.0
>                            |               +-05.0-[05]--
>                            |               +-06.0-[06-07]----00.0-[07]--
>                            |               +-07.0-[08]----00.0
>                            |               +-08.0-[09]----00.0 Ethernet
>                            |               \-09.0-[0a]--
>                            \-00.1 (PEX special device)
>
> Gateworks have the following patch for this (and the MAC address
> assignment works):
>
> --- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
> @@ -369,8 +369,42 @@
>         reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
>         status = "okay";
>
> -       eth1: sky2 at 8 { /* MAC/PHY on bus 8 */
> -               compatible = "marvell,sky2";
> +       pcie at 0,0 {
> +               /* 00:00.0 0604: 16c3:abcd root host-bridge */
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               device_type = "pci";
> +               reg = <0x0 0 0 0 0>;
> +
> +               pcie at 0,0 {
> +                       /* 01:00.0 0604: 10b5:8609 PEX switch bridge */
> +                       #address-cells = <3>;
> +                       #size-cells = <2>;
> +                       device_type = "pci";
> +                       reg = <0x0 0 0 0 0>;
> +
> +                       /*
> +                        * GigE PCI dev node needs to be defined so that enet
> +                        * driver can use it to obtain its boot-loader
> +                        * specified MAC
> +                        */
> +                       pcie at 8,0 {
> +                               /* 02:08.0 0604: 10b5:8609: PEX port bridge */
> +                               #address-cells = <3>;
> +                               #size-cells = <2>;
> +                               device_type = "pci";
> +                               reg = <0x4000 0 0 0 0>;
> +
> +                               eth1: pci at 0,0 {
> +                                       /* 08:00.0 0200: 11ab:4380: GigE */
> +                                       #address-cells = <3>;
> +                                       #size-cells = <2>;
> +                                       device_type = "pci";
> +                                       reg = <0x0 0 0 0 0>;
> +                                       compatible = "marvell,sky2";
> +                               };
> +                       };
> +               };
>         };
>  };
>
> Unfortunately the patch has a side effect - it messes up the PCIe
> interrupts. Basically all PCI IRQs except for the special device handled
> internally by the PEX 8609 bridge are set to 155:
>
>                                       good    bad (with patch)
> 00:00.0 PCI bridge: (IMX6 host bridge)
>         Interrupt: pin A routed to IRQ 155
> 01:00.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 155
> 01:00.1 System peripheral: PEX-8609
>         Interrupt: pin B routed to IRQ 154 (not changed)
> 02:01.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 154 -> 155
> 02:04.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 155
> 02:05.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 154 -> 155
> 02:06.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 153 -> 155
> 02:07.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 152 -> 155
> 02:08.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 155
> 02:09.0 PCI bridge: PEX-8609
>         Interrupt: pin A routed to IRQ 154 -> 155
> 04:00.0 Techwell Device 6864
>         Interrupt: pin A routed to IRQ 155
> 06:00.0 PCI bridge
> 08:00.0 Techwell Device 6869
>         Interrupt: pin A routed to IRQ 152 -> 155
> 09:00.0 Ethernet controller
>         Interrupt: pin A routed to IRQ 155
>
> This is the case with v3.18 + the Ventana patchset from Gateworks, and
> with vanilla v4.0 with only the above DT patch applied.
>
> The question is: what's wrong in the patch, and how do I fix it?
> --
> Krzysztof Halasa
>
> Industrial Research Institute for Automation and Measurements PIAP
> Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Krzysztof,

I became aware of the interrupt mapping side-effect recently of this
downstream patch as well. I believe the issue is that the pci nodes
need to be fully described including the interrupt* properties. My
plan is to address this with a bootloader fixup which will dynamically
build the device-tree representation of the pcie nodes on the bus
(because some boards have PCI switches with differing number of
ports).

For now, do not use the down-stream patch and assign the mac addresses
in a different fashion if using mainline linux on the GW54xx/GW53xx.
You can contact support at gateworks.com for more information on how to
obtain the MAC addr's from the board's EEPROM.

Regards,

Tim

^ permalink raw reply	[flat|nested] 4+ messages in thread

* IMX6 - PCIe device tree assignments
  2015-06-22 13:34 ` Tim Harvey
@ 2015-06-26  6:20   ` Krzysztof Hałasa
  2015-06-26 13:19     ` Tim Harvey
  0 siblings, 1 reply; 4+ messages in thread
From: Krzysztof Hałasa @ 2015-06-26  6:20 UTC (permalink / raw)
  To: linux-arm-kernel

Thanks for your response.

Tim Harvey <tharvey@gateworks.com> writes:

> I became aware of the interrupt mapping side-effect recently of this
> downstream patch as well. I believe the issue is that the pci nodes
> need to be fully described including the interrupt* properties. My
> plan is to address this with a bootloader fixup which will dynamically
> build the device-tree representation of the pcie nodes on the bus
> (because some boards have PCI switches with differing number of
> ports).

Wouldn't it be better if the device tree PCI code accepted the extra
data (basically the "eth1" alias) without changing information which
wasn't explicitly specified (such as IRQ mapping)?

> For now, do not use the down-stream patch and assign the mac addresses
> in a different fashion if using mainline linux on the GW54xx/GW53xx.

That's what I have been doing, though the patch looks like a better,
transparent solution.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

^ permalink raw reply	[flat|nested] 4+ messages in thread

* IMX6 - PCIe device tree assignments
  2015-06-26  6:20   ` Krzysztof Hałasa
@ 2015-06-26 13:19     ` Tim Harvey
  0 siblings, 0 replies; 4+ messages in thread
From: Tim Harvey @ 2015-06-26 13:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 25, 2015 at 11:20 PM, Krzysztof Ha?asa <khalasa@piap.pl> wrote:
> Thanks for your response.
>
> Tim Harvey <tharvey@gateworks.com> writes:
>
>> I became aware of the interrupt mapping side-effect recently of this
>> downstream patch as well. I believe the issue is that the pci nodes
>> need to be fully described including the interrupt* properties. My
>> plan is to address this with a bootloader fixup which will dynamically
>> build the device-tree representation of the pcie nodes on the bus
>> (because some boards have PCI switches with differing number of
>> ports).
>
> Wouldn't it be better if the device tree PCI code accepted the extra
> data (basically the "eth1" alias) without changing information which
> wasn't explicitly specified (such as IRQ mapping)?

Yes - and this is how I originally had thought/hoped it worked. I
haven't had time to dig into the interrupt mapping issue that the
downstream patch referenced causes so its possible I'm making a bad
assumption and its something else.

>
>> For now, do not use the down-stream patch and assign the mac addresses
>> in a different fashion if using mainline linux on the GW54xx/GW53xx.
>
> That's what I have been doing, though the patch looks like a better,
> transparent solution.

I agree - there should be a simple way for the bootloader firmware to
get mac addresses to the kernel (without having to know fully where it
sits on the bus IMHO so you don't have to have full PCI support in the
bootloader). I will be sure to cc you when I can get to it and come up
with a better solution (whether its an upstream linux device-tree
change for GW54xx/GW53xx or if its a bootloader firmware fix).

Tim

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-06-26 13:19 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-18 10:18 IMX6 - PCIe device tree assignments Krzysztof Hałasa
2015-06-22 13:34 ` Tim Harvey
2015-06-26  6:20   ` Krzysztof Hałasa
2015-06-26 13:19     ` Tim Harvey

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.