| Message ID | m34mm5tj4b.fsf@t19.piap.pl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@8 { /* MAC/PHY on bus 8 */ > - compatible = "marvell,sky2"; > + pcie@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@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@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@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@gateworks.com for more information on how to obtain the MAC addr's from the board's EEPROM. Regards, Tim
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.
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
--- 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@8 { /* MAC/PHY on bus 8 */ - compatible = "marvell,sky2"; + pcie@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@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@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@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"; + }; + }; + }; }; };
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): 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