It seems that you don't figure out how real hardware works AT ALL. IRQ callbacks and private data CANNOT BE SHARED as they are INTERNAL TO ONE IRQ CONTROLLER. IRQ management, once again, is completelly specific to an IRQ controller technology and absolutely not related to the CPU you may use on the same board. So it's a complete nonsense to try to share IRQ notion in the CPU. IRQ notions and management is completely different to one IRQ controller technology to another.
On Sat, 2007-04-07 at 21:45 +0100, Paul Brook wrote: > On Saturday 07 April 2007 21:28, J. Mayer wrote: > > On Sat, 2007-04-07 at 20:10 +0100, Paul Brook wrote: > > > On Saturday 07 April 2007 19:32, J. Mayer wrote: > > > > On Sat, 2007-04-07 at 18:14 +0000, Paul Brook wrote: > > > > > CVSROOT: /sources/qemu > > > > > Module name: qemu > > > > > Changes by: Paul Brook <pbrook> 07/04/07 18:14:41 > > > > > > > > The patches in the PowerPC target seem complete nonsense. > > > > > > Can you give specific examples? > > > > I'm talking about the CPU code. > > There is NO notion of external IRQ allocation in the PowerPC > > specification. > > Quoting from ppc.c (both before and after my patch): > > /*****************************************************************************/ > /* PowerPC internal fake IRQ controller > * used to manage multiple sources hardware events > > My patch did not change how this worked at all. It just changed it from using > an ad-hoc system of callpacks and opaque parameters to using a standard > mechanism for connecting interrupt sources, be they internal or external. > > MIPS works exactly the same way. No. MIPS CPU have an internal IRQ controller and often one or many external ones. It's completely different and cannot be easily compared to what done internally in a PowerPC. > > Where do you see that a > > machine with a PowerPC cannot manage more than 32 IRQ ? > > Any PPC that needs more that 32 internal interrupt sources is already broken. > Notice how the old bitmask is a uint32_t. You don't understand a single word of what I wrote or you don't understand at all what is the difference between a CPU and an IRQ controller. The code you quote concerns INTERNAL EXCEPTION MANAGEMENT. It's no way related with an IRQ controller and will never be. One or more exception, like in any CPU, can be connected to an IRQ controller (or more, cascaded, for example). The IRQ management is done inside the IRQ controller, not in the CPU and all the hardware IRQ interface are SPECIFIC to the IRQ controller. Then, this is to be emulated internally in the controller and has no notion to be shared in the CPU (as there is none in the real hardware). The existing code ACTUALLY WORKS with more than 32 IRQs as you can cascade any number of IRQ controller one to the other. Each IRQ controller handle its own events and manage the callbacks to the cascade. There is only one controller in the chain connected to the CPU. Then, you can virually have an infinite number of IRQ, managed by a chain of controllers, using different technologies then cannot share any data execpt the IRQ events on the cascade. THAT's HOW REAL HARDWARE WORKS AND THAT'S HOW IT'S EMULATED FOR POWERPC IN THE CODE BEFORE YOU BREAK IT ! > > SO your patch is a complete nonsense and YES IT BREAKS MY WORKS SO IT > > HAS TO BE REVERTED. > > I can only fix the code that I have access to. You broke the commited code.... And you also completely break any new development for the PowerPC target as most real machine cannot be emulated now (even PREP is broken, using 3 IRQ controllers). > However if there is agreement from other maintainers I will revert my patch. I only ask you to revert all that affects the PowerPC target. If the other developpers want their target to follow this broken way, it does not hurt me as long as it does not break fundamental concept for PowerPC emulation. -- J. Mayer <[EMAIL PROTECTED]> Never organized
