Porting guide ar71xx to ath79?

At current master it looks this way

root@Router:~# cat /proc/interrupts
           CPU0       
  3:          0      MIPS   3  ehci_hcd:usb1
  4:       4140      MIPS   4  19000000.eth
  5:       3608      MIPS   5  1a000000.eth
  7:      40387      MIPS   7  timer
  8:         14      MISC   3  ttyS0
 11:          0      MISC   6  ohci_hcd:usb2
 12:      19179  AR71XX PCI   1  ath9k, ath9k
ERR:          1

Errors are counting as soon as Wi-Fi is on.

If I add interrupts = <0>; to ath9k0 and interrupts = <1>; to ath9k1,

it looks


 12:      0  AR71XX PCI   0  ath9k
13:        0 AR71XX PCI    1  ath9k

This looks good, but when the second device requires an interrupt, nothing happens and it crashes.

On ar71xx it looked

 40:      0  AR71XX PCI   0  ath9k
41:        0 AR71XX PCI    1  ath9k

IRQ numbers don't matter, but we need to split them somehow.

It seems that there is a bug somewhere, so the irq domain has only one IRQ. It is supposed to have 8 as defined in AR71XX_PCI_IRQ_COUNT. So the second one just is not cascaded. Maybe I am wrong.

And I see that ATH79_PCI_IRQ_COUNT == 6 and AR71XX_PCI_IRQ_COUNT == 8
I think the problem is that apc->domain is not populated properly.

I think irq_create_mapping() should be called.

the "no irq domain found" comes from an accidentally removed "interrupt-cells" in pci-controller node. But now I met some other errors and I'm checking it.

Maybe it's a wrong way. I am now building ar71xx to see what are the hwirq bound to 40 and 41.

40/41 are just software defined IRQ values and you can find them in arch/mips/pci/pci-ar71xx.c. They are interrupts dispatched from a specific cpu interrupt(in a way I said above).
I've got it working on QCA9558. I'll post the dts fix for ar7100.dtsi later.

I wanted to know which hardware irq's were triggered by them.

I think I can fix the dtsi myself. Did you post the main patch?

@Pilot6 I've updated my branch. You can test my new dtsi now :slight_smile:

BTW: The address that waiting for parsing its IRQ will be masked by interrupt-map-mask and then matched
in interrupt-map. So changing the last value in interrupt-map-mask to 0 allows using one line for all 4 PCI interrupts.

OK, I'll see if it works one way or another.

I needed to finish another build. I'll test in a couple of min.

You are a real genius!!!!

root@Router:~# cat /proc/interrupts
           CPU0       
  3:          0      MIPS   3  ehci_hcd:usb1
  4:        833      MIPS   4  19000000.eth
  5:        566      MIPS   5  1a000000.eth
  7:       9966      MIPS   7  timer
  8:         17      MISC   3  ttyS0
 11:          0      MISC   6  ohci_hcd:usb2
 12:       1739  AR71XX PCI   1  ath9k
 13:          0  AR71XX PCI   2  ath9k
ERR:          0

But the problem is that 5GHz doesn't work now. I am looking what happens.

So, we got 2 interrupts, but nothing works with them.
I could achieve having 2 interrupts by adding interrupts properties to ath9k.

But the driver is unable to cascade two.

@981213 See this

root@Router:/sys/kernel/debug/irq/irqs# cat 12
handler:  handle_level_irq
status:   0x00000400
            _IRQ_NOPROBE
istate:   0x00000000
ddepth:   0
wdepth:   0
dstate:   0x02400000
            IRQD_IRQ_STARTED
node:     0
domain:  :ahb:apb:pcie-controller@180c0000:interrupt-controller
 hwirq:   0x1
 chip:    AR71XX PCI
  flags:   0x0
root@Router:/sys/kernel/debug/irq/irqs# cat 13
handler:  handle_level_irq
status:   0x00000400
            _IRQ_NOPROBE
istate:   0x00000000
ddepth:   0
wdepth:   0
dstate:   0x02400000
            IRQD_IRQ_STARTED
node:     0
domain:  :ahb:apb:pcie-controller@180c0000:interrupt-controller
 hwirq:   0x2
 chip:    AR71XX PCI
  flags:   0x0

hwirq is different. I think we need to use irq_create_mapping().
I was doing it, but could't figure to which hwirq to map the domain.

Now it looks looks 0x1 is the correct choice.

@981213 Why are you modifying also the ar724x pcie driver?
ar724x is always a pcie interface and pcie isn´t a bus, so only one device per pcie interface.

Two reasons:

  1. IRQ modifications for both drivers are the same, since I don't have an AR7161 router I can use other qca routers to test my modification.
  2. I saw someone reported that their ath10k devices also has the mentioned "low throughput" problem and I'm now testing whether this problem exists.

That branch isn't the final branch for the pull request :slight_smile:

1 Like

Is this probably related to the write buffer flush? On ar71xx this was only implemented on interrupts for ge0 and ge1 and for ar934x also on pcie and wmac.

On ath79 it looks like the write buffer is flushed for almost everything (ge0, ge1, wmac, pci, usb) on soc´s from ar71xx till qca95xx...