j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 2012-Apr-4 16:15 , Artyom Tarasenko wrote:
So, basically, without these properties, software would have no way to tell what CPU interrupt is pulled when the device irq becomes active, right?
That's correct. The normal, default, cases work fine - where the interrupts are routed along the same paths as the data. These properties let us work around the cases where hardware engineers decided to wire things differently.
Nice explanation. I read the Open Firmware draft interrupt mapping document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), but I was more confused after reading it than before.
Hm. Since it's a part of a standard specification, the other machines (i.e. PPC) might need these properties as well?
Only if they have hardware where interrupts are routed in strange ways.
This originally came about when we wanted separate interrupts for a bunch of small devices which were all connected through the same bridge - and normal behaviour would have muxed several of these interrupts onto overlapping A/B/C/D interrupt lines. By routing the interrupts directly into pins giving us unique interrupts, we avoided having OS software having to poll each of several devices on every interrupt.
Note that these interrupt properties aren't actually used by Openboot - they're just passed along to make life easier on Solaris (and other clients).