I am using legacy interrupts in this case. I found the issue where the interrupts were not firing (stupid issue on my part). Working on getting the data through the pipe.
I still have a question on the meaning for the ASYNC cause. After receiving and clearing interrupts (writing the ISR back to itself). I am masking the bits until they are serviced. When the interrupts are masked I get an async cause of 0x0 and the interrupts are ignored. Is the AR_INTR_ASYNC_CAUSE indicating that the interrupt has not changed since the last IMR update? If so this would be odd behavior (normally an IMR will prevent spurious ISR to relieve loading). Thanks in advance, -Lamar This email and any attachments may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please immediately delete this email and any attachments. _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
