WDMA + WED #3
Notifications
Due Date
No due date set.
Depends on
#2 Ethernet
tplink_xx230v/kernel
Reference: tplink_xx230v/kernel#3
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
IRQs:
The WED and WDMA hardware blocks are probably inherited from the EN7528 SoC design. It seems like they took the mips irq indices and mapped them in with an offset of 16.
The wed is supposed to only be able to accelerate in the downstream direction. The NPUs are supposed to be able to do both US/DS. The NPUs are most likely driver dependant.
If the aim is long term linux mainline support then I think the WED path should be taken instead of the NPUs. On the AN7581 the NPUs are standard RISCV32 and in theory one could implement open source packet offloading there. The AN7523 NPU binaries are some kind of obfuscation. Most likely the opcodes are substituted or something.
Anyway wed enabled driver code should be possible to get going as it should be similar to what Mediatek has in main line.
I haven't found any reference drivers in Econet's GPLs so far. I'm going to download them to my computer so I can search better. I found almost nothing in the GPL I have from Airoha.
When I was testing the Mediatek drivers, I couldn't get any signal that was working.
I dont think this hit production devices besides for EN7528. And you need to understand alot about the mt76 to be able to get it working properly. The wed/wdma is from the same generation as MT7622 so maybe it is needed to look back at that platform and its open code to see if the old integration code worked better.
Ok, it looks like the WED is connected to GDM3. So that is how packets come in to the PPE(Frame engine). The frame engine needs proper setup to handle the packets.
Therefore, the functioning of the frame engine is a priority