Interrupts on the GameCube
Michael Steil <[email protected]>
| Newsgroups | gmane.linux.ports.game-cube.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi! tmbinc and me have been talking about how to implement interrupts on the GameCube. The GameCube has an interrupt controller with 14 sources. Each source is a device, and each device can trigger one or more different interrupts by only having one line to the interrupt controller. This is quite similar to other architectures: Interrupt 8 in this case comes from the VI (Video Interface), and the VI has 4 different sources for interrupts. The original GameCube system software presents a linear system to the user. It is aware of all possible interrupts sources at the second level and presents them in a single list. The user must only register for one specific VI interrupt, for example, and not for the common VI interrupt and then check which one it was, using the VI registers. GCLIb also implements this behavior. It is my understanding that it is common in Linux to only implement the first level in the kernel interrupt handling code, i.e. 14 sources, and that drivers must do the rest manually. This is done because the generic kernel interrupt code cannot be aware of all different devices in a system - on a normal computer you can change the configuration easily and remove or add devices, like PCI cards. On the GameCube, the number of different interrupts is fixed; there is no way to add a device that can trigger another interrupt, so the generic interrupt code would already handle all interrupts at the sources and pretend that this two-level design didn't exist. There are pros for each side. Presenting two levels is more the Linux way, while linearizing the interrupts is easier for driver developers and has no real disadvantages. I tend to prefer the Linux way, tmbinc seems to prefer the GameCube SDK way. What are your opinions? Michael ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn