The current User Guide source (0210345cd9cf19629010277732280e9e7248771e) says that the Audio-DMA subsystem cannot generate interrupts. In exact tested core 03b24c6, the GS4510 implementation gates each channel event with audio_dma_irqenb(i), sets its interrupt flag, and then sets irq_internal and CPU irq_pending (src/vhdl/gs4510.vhdl, lines 4533–4553).
Current development HEAD a915893 retains the same route at lines 4552–4573. Closed issue #811 records that Audio-DMA IRQ support was implemented, tested and merged in 2024, so this appears to be stale documentation rather than unexpected core behavior.
Could the Audio-DMA section and $D713 register description be updated to describe the four enable/flag pairs and their CPU interrupt route? Our software now clears $D713 during interrupt ownership because inherited firmware or hypervisor state may otherwise leave a channel interrupt armed.
This is a documentation correction against a named core revision, not a claim that the core behavior is defective.
The current User Guide source (0210345cd9cf19629010277732280e9e7248771e) says that the Audio-DMA subsystem cannot generate interrupts. In exact tested core 03b24c6, the GS4510 implementation gates each channel event with audio_dma_irqenb(i), sets its interrupt flag, and then sets irq_internal and CPU irq_pending (src/vhdl/gs4510.vhdl, lines 4533–4553).
Current development HEAD a915893 retains the same route at lines 4552–4573. Closed issue #811 records that Audio-DMA IRQ support was implemented, tested and merged in 2024, so this appears to be stale documentation rather than unexpected core behavior.
Could the Audio-DMA section and $D713 register description be updated to describe the four enable/flag pairs and their CPU interrupt route? Our software now clears $D713 during interrupt ownership because inherited firmware or hypervisor state may otherwise leave a channel interrupt armed.
This is a documentation correction against a named core revision, not a claim that the core behavior is defective.