Open frno7 opened 3 years ago
Maybe @wisi-w can help with DEV9 registers?
Thanks, @AKuHAK, that would be lovely! I’ve begun to implement cascading interrupts for DEV9, which is to say that its IRQs from the drivers point of view behaves like all the standard IOP IRQs. Right now I’m searching for information on how to acknowledge the DEV9 (or SPD) interrupts.
DEV9 SPD interrupts seem to work nicely now. The main invention is that these IRQs are first-class, so that request_irq
release_irq
, enable_irq
and disable_irq
(corresponding to RegisterIntrHandler
, ReleaseIntrHandler
, EnableIntr
and DisableIntr
in the PS2SDK) handle them directly, as any other intrman
IRQ. This makes drivers simpler, and in some cases effortless, when special IRQ cases go away. Relaying these IRQs to the EE works automatically, for example.
The DEV9 SPD virtual IRQ assignments
make the IRQs a superset of intrman.h
in the PS2SDK.
Nice work, It would be nice to have this in ps2sdk as well, but I'm not sure we can. Since it probably involves making all drivers depend on a new module that handles the cascaded interrupts. About the naming of the cascading interrupts, they don't seem logical to me:
IRQ_IOP_DMA
-> IRQ_IOP_DMA_*
IRQ_IOP_DEV9
-> IRQ_IOP_SPD_*
?Rename IRQ_IOP_DEV9
to IRQ_IOP_SPD
, or rename IRQ_IOP_SPD_*
to IRQ_IOP_DEV9_*
to make it more consistent?
IRQ_IOP_SPD
is also defined to be equal to IRQ_IOP_SPD_ATA0
. Rename IRQ_IOP_SPD
to IRQ_IOP_SPD_BASE
or remove it?
Thanks, @rickgaiser! Regarding renaming, I’m not sure the SPD IRQs are the only DEV9 IRQs. Are they? If SPD covers all IRQs for DEV9, your suggestion makes sense to me.
Dev9 covers more than the SPEED chip (for example if you connect something different from a net adapter to the expansion bay), so to the IOP, they are Dev9 intrs. Inside the SPEED chip, there is further subdivision of the intr causes, to the various devices inside it, as you have seen.
Thanks for the clarification, @wisi-w! To improve the code somewhat in line with @rickgaiser’s suggestion I’m planning to add the special symbols IRQ_IOP_SPD_BASE
, and IRQ_IOP_SPD_LAST
, as well the comment /* Virtual SPD IRQ */
to clarify that these aren’t hardware IRQs in the traditional sense. Someone might get confused otherwise, as to where exactly these IRQs actually come from.
IRQ_IOP_SPD_BASE = 46,
IRQ_IOP_SPD_ATA0 = IRQ_IOP_SPD_BASE,/* Virtual SPD IRQ */
IRQ_IOP_SPD_ATA1 = 47, /* Virtual SPD IRQ */
IRQ_IOP_SPD_TXDNV = 48, /* Virtual SPD IRQ */
IRQ_IOP_SPD_RXDNV = 49, /* Virtual SPD IRQ */
IRQ_IOP_SPD_TXEND = 50, /* Virtual SPD IRQ */
IRQ_IOP_SPD_RXEND = 51, /* Virtual SPD IRQ */
IRQ_IOP_SPD_EMAC3 = 52, /* Virtual SPD IRQ */
IRQ_IOP_SPD_DVR = 55, /* Virtual SPD IRQ */
IRQ_IOP_SPD_UART = 58, /* Virtual SPD IRQ */
IRQ_IOP_SPD_LAST = IRQ_IOP_SPD_UART,
It seems a DEV9 IOP module is needed, for various expansion bay hardware. A prototype has been implemented in
module/dev9.c
, to support a harddisk driver. Important DEV9 registers are only available from the IOP, so the EE cannot easily manage DEV9 by itself, as it seems. Furthermore, DEV9 resources need to be shared among multiple devices, such as harddisk and network. Plan: