| Message ID | 20180529192148.8286-1-kristian.evensen@gmail.com |
|---|---|
| State | Superseded |
| Delegated to: | John Crispin |
| Headers | show |
| Series | [OpenWrt-Devel] ramips: Fix pcie interrupt mapping for ZBT WE1326 | expand |
Hi, On Tue, May 29, 2018 at 9:21 PM, Kristian Evensen <kristian.evensen@gmail.com> wrote: > + interrupt-map = <0x10000 0 0 1 &gic GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>, > + <0x20000 0 0 1 &gic GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>; > + Now that the offending commit has been reverted, this patch can be ignored. However, I thought I should provide some context on this change, as the recent discussions on the forum triggered me to do a more thorough investigation of what actually went wrong. Any feedback, or plain "YOU ARE WRONG", are very much welcome as I am not very experience with dts, setting up pci and interrupts, etc. Before commit 5f7396ebef09, the IRQ was set inside a large if-clause (removed by the mentioned commit). The wifi radios on the 1326 are on PCIe bus 1, slot 0 (mt76x2) and bus 2, slot 1 (mt7603). When PCIe is about to be enabled, pcie_link_status is six for both radios. The RALINK_INT_PCIE-values map directly to interrupts specified for PCIe in the dtsi-file. I.e., RALINK_INT_PCIE0 is GIC_SHARED 4, PCIE1 is 24 and PCIE2 is 25. Before 5f7396ebef09, the IRQ for mt76x2 was always set to PCIE1 (24) and mt7603 to PCIE2 (25). /proc/interrupts looks as follows on a working WE1326: 24: 2792 0 0 0 MIPS GIC 31 mt76x2e 25: 13123 0 0 0 MIPS GIC 32 mt7603e The hardware interrupt numbers are calculated by doing GIC_SHARED_HWIRQ_BASE + x (where X is either 4, 24 or 25). GIC_SHARED_HWIRQ_BASE is defined as GIC_NUM_LOCAL_INTRS, which is seven. This is why we see GIC 31 and 32. See /drivers/irqchip/irq-mips-gic.c and /arch/mips/include/asm/mips-gic.h in the kernel sources for more details about the calculations, values, etc.. After commit 5f7396ebef09, the static IRQ assigned for the given bus/slot combos are removed and the IRQ values from the DTS are used directly. A consequence of this is that the first pci device (mt76x2) in the 1326 is incorrectly assigned IRQ 11. /proc/interrupts after 5f7396ebef09 looks as follows: 24: 0 0 0 0 MIPS GIC 11 mt76x2e The correct interrupts should be as above. I.e, mt76x2 should have IRQ 31 (GIC_SHARED 24) and mt7603 IRQ 32 (GIC_SHARED 25). By applying my patch and thus update the interrupt map, the correct interrupt mapping was restored. /proc/interrupts looks as follows: 23: 23 0 0 0 MIPS GIC 32 mt7603e 24: 3010 0 0 0 MIPS GIC 31 mt76x2e In order to confirm that the IRQ-mapping on the WE1326 are different from (some) other mt7621-devices, I checked the interrupt mapping on the ZBT WG3526 (which worked before and after commit). It looks as follows: 23: 84765 0 0 0 MIPS GIC 11 mt7603e 24: 27389 0 0 0 MIPS GIC 31 mt76x2e I.e., mt7603 (first pci device) is GIC_SHARED 4 and mt76x2 GIC_SHARED 24. The paths to the pci-devices are the same on both WE1326 and WG3526 (0000:01:00.0 and 0000:02:00.0). BR, Kristian
diff --git a/target/linux/ramips/dts/ZBT-WE1326.dts b/target/linux/ramips/dts/ZBT-WE1326.dts index 6cbab66307..72707192a2 100644 --- a/target/linux/ramips/dts/ZBT-WE1326.dts +++ b/target/linux/ramips/dts/ZBT-WE1326.dts @@ -84,6 +84,9 @@ &pcie { status = "okay"; + interrupt-map = <0x10000 0 0 1 &gic GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>, + <0x20000 0 0 1 &gic GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>; + pcie0 { mt76@0,0 { reg = <0x0000 0 0 0 0>;
Commit 5f7396ebef09 ("ramips: improve interrupt mapping") changed how pcie interrupts are mapped for mt7621. The default interrupt mapping in mt7621.dtsi is incorrect for the ZBT WE1326, causing wifi not to work. This commit updates the WE1326 DTS with the correct interrupt mapping, restoring wifi. Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com> --- target/linux/ramips/dts/ZBT-WE1326.dts | 3 +++ 1 file changed, 3 insertions(+)