DEV9 module

[frno7]

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:

• identify attached DEV9 hardware;
• power off DEV9 if it isn’t used;
• power on DEV9 if some driver needs it;
• initialise DEV9 registers as needed;
• share, acknowledge and mask DEV9 interrupts as needed;
• document DEV9 registers, etc. (is there some reliable source?).

[AKuHAK]

Maybe @wisi-w can help with DEV9 registers?

[frno7]

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.

[frno7]

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

iopmod/include/iopmod/irqs.h

Lines 50 to 58 in c7c68d2

	IRQ_IOP_SPD_ATA0 = 46,
	IRQ_IOP_SPD_ATA1 = 47,
	IRQ_IOP_SPD_TXDNV = 48,
	IRQ_IOP_SPD_RXDNV = 49,
	IRQ_IOP_SPD_TXEND = 50,
	IRQ_IOP_SPD_RXEND = 51,
	IRQ_IOP_SPD_EMAC3 = 52,
	IRQ_IOP_SPD_DVR = 55,
	IRQ_IOP_SPD_UART = 58,

make the IRQs a superset of intrman.h in the PS2SDK.

[rickgaiser]

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?

[frno7]

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.

[wisi-w]

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.

[frno7]

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,