Porting guide ar71xx to ath79?


that hwirq corresponds to the second argument of function irq_linear_revmap:

generic_handle_irq(irq_linear_revmap(apc->domain, 1));

(This line is taken from line 284 of arch/mips/pci/pci-ar71xx.c)
It's completely software defined here although it's called "hwirq". The "hwirq" means the corresponding hardware IRQ number of the current IRQ chip. In our case here, we don't actually have a hardware IRQ chip, we just read the interrupt status register and execute the corresponding IRQ handler of pci devices. We registered an IRQ chip in pci driver but that "IRQ chip" is dummy.
I suggest adding some debug print in ar71xx_pci_irq_handler and check which bit of AR71XX_RESET_REG_PCI_INT_STATUS is triggered when receving an interrupt.
I think I can't help further here due to lack of a router.


I can give you access to the router from the net.


That's too hard for me to debug.
Do you have devmem installed in your firmware? After reading some code I guess the pci interrupt are incorrectly masked. If you are free you can try to dump RST_PCI_INTERRUPT_MASK(0x1806001c). I guess the correct value of the last three bit should be 011 (0x3) and the value on ath79 will be 110 (0x6).


devmem used to be there, but it is disabled by menuconfig.
It's not there now, but it will be there in 10 min.


root@OpenWrt:~# devmem 0x1806001c


So now I have both interfaces up, but wlan1 doesn't work at all. No errors in syslog.


I'm quite confused now. Similar problems exist on both pci-ar71xx and pci-ar724x but how could pci-ar724x works with a broken interrupt-map and a broken mask/unmask function?

At least it shows that the mask is incorrect(although the value is unexpected). I'll do some debug on my qca9558 router later :frowning:

root@OpenWrt:~# cat /proc/interrupts
  3:          0      MIPS   3  ehci_hcd:usb1
  4:       1249      MIPS   4  19000000.eth
  5:          0      MIPS   5  1a000000.eth
  7:      60353      MIPS   7  timer
  8:         17      MISC   3  ttyS0
 11:          0      MISC   6  ohci_hcd:usb2
 12:      59597  AR71XX PCI   1  ath9k
 13:          0  AR71XX PCI   2  ath9k
ERR:          4
wlan0     Link encap:Ethernet  HWaddr   
          inet6 addr: fe80::218:e7ff:fe8c:3f71/64 Scope:Link
          RX packets:465 errors:0 dropped:0 overruns:0 frame:0
          TX packets:425 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:61289 (59.8 KiB)  TX bytes:108456 (105.9 KiB)

wlan1     Link encap:Ethernet  HWaddr
          inet6 addr: fe80::218:e7ff:fe8c:3f73/64 Scope:Link
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:214 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:37877 (36.9 KiB)


And I can always give you access to DIR-825 over IPv4 or IPv6. You can flash it or do whatever you want.


At least I know why the broken pci-ar724x works now...

  1. Somehow the incorrect interrupt-controller property defined there caused all the devices bind to the first IRQ on the registered dummy IRQ chip, and this is correct for those pcie controller since there will be only one possible device on each pcie controller.
  2. The mask/unmask function called irq_linear_revmap(apc->domain, d->irq) with incorrect arguments, and irq_linear_revmap will return 0 when arguments are invalid, and 0 is the correct bit to mask/unmask the interrupt controller.


A fix will be ready in about 20 minutes.
edit: I mean a fix for ar7100


Sounds very good!


@Pilot6 How did you get devmem to work?
I am trying to debug a GPIO register but even with CONFIG_KERNEL_DEVMEM and CONFIG_KERNEL_DEVKMEM enabled in kernel config devmem complains about /dev/mem not being available




Well that makes sense.


I've updated my code at https://github.com/981213/openwrt/tree/ath79_pci and you can test again if you are free.


Thanks, I will do it now. Today is my last vacation day ))


Yes!!!! It works perfectly.


You are a genius. I hope I could read the code and understand it so fast!
It would take me a month to find that all out. Maybe not enough.


@981213 Do we really need the interrupt-controller subnode?
The problem was not with mapping. If we set different interrupts in ath9k nodes, it should work the same way now.

It is more convenient to configure mappings in case of different devices though.