On 2012-Apr-4 13:30 , Artyom Tarasenko wrote:
Could it be that OpenBIOS is missing interrupt-map and interrupt-map-mask properties for the PCI bus?
On a real Ultra-5 it looks like this: interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 interrupt-map-mask 0000003e 00000000 00000000
What is mapped to what?
I couldn't find any documentation how these properties work, except for Linux and OpenSolaris sources. Thought I ask here before trying to reconstruct the picture from them.
These are documented at least as far back as the Safari binding, in section 5.2.1.4 (assuming that spec got published). They are used to route interrupts differently than the data interconnects for devices - specifically, when hardware has taken the interrupt pins from a device and brought them in to the CPU through a path which bypasses all the intervening bridges. The specification for interrupt-map is:
child.hi child.mid child.lo child.intrspec intr-parent.phandle intr-parent.intrspec
Basically, it defines the child, the child's interrupt then points to the parent where the interrupt appears and what interrupt it appears as. In the above Ultra-5 spec, it looks like the first three cells are defining the child (3c?), and the interrupt from that child (presumably zero), saying that this interrupt appears under node f005fa24 as interrupt 33.
The interrupt-map-mask is simply a mask applied to the child information it's defined as
child.hi child.mid child.lo child.intrspec
Evidently on the Ultra-5, we aren't using three cells to identify the child, only two. So we probably skip child.mid in both of the above specifications.
On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2012-Apr-4 13:30 , Artyom Tarasenko wrote:
Could it be that OpenBIOS is missing interrupt-map and interrupt-map-mask properties for the PCI bus?
On a real Ultra-5 it looks like this: interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 interrupt-map-mask 0000003e 00000000 00000000
What is mapped to what?
I couldn't find any documentation how these properties work, except for Linux and OpenSolaris sources. Thought I ask here before trying to reconstruct the picture from them.
These are documented at least as far back as the Safari binding, in section 5.2.1.4 (assuming that spec got published). They are used to route interrupts differently than the data interconnects for devices - specifically, when hardware has taken the interrupt pins from a device and brought them in to the CPU through a path which bypasses all the intervening bridges. The specification for interrupt-map is:
child.hi child.mid child.lo child.intrspec intr-parent.phandle intr-parent.intrspec
Basically, it defines the child, the child's interrupt then points to the parent where the interrupt appears and what interrupt it appears as. In the above Ultra-5 spec, it looks like the first three cells are defining the child (3c?), and the interrupt from that child (presumably zero), saying that this interrupt appears under node f005fa24 as interrupt 33.
The interrupt-map-mask is simply a mask applied to the child information it's defined as
child.hi child.mid child.lo child.intrspec
Evidently on the Ultra-5, we aren't using three cells to identify the child, only two. So we probably skip child.mid in both of the above specifications.
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.
On Wed, Apr 4, 2012 at 7:59 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2012-Apr-4 13:30 , Artyom Tarasenko wrote:
Could it be that OpenBIOS is missing interrupt-map and interrupt-map-mask properties for the PCI bus?
On a real Ultra-5 it looks like this: interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 interrupt-map-mask 0000003e 00000000 00000000
What is mapped to what?
I couldn't find any documentation how these properties work, except for Linux and OpenSolaris sources. Thought I ask here before trying to reconstruct the picture from them.
These are documented at least as far back as the Safari binding, in section 5.2.1.4 (assuming that spec got published). They are used to route interrupts differently than the data interconnects for devices - specifically, when hardware has taken the interrupt pins from a device and brought them in to the CPU through a path which bypasses all the intervening bridges. The specification for interrupt-map is:
child.hi child.mid child.lo child.intrspec intr-parent.phandle intr-parent.intrspec
Basically, it defines the child, the child's interrupt then points to the parent where the interrupt appears and what interrupt it appears as. In the above Ultra-5 spec, it looks like the first three cells are defining the child (3c?), and the interrupt from that child (presumably zero), saying that this interrupt appears under node f005fa24 as interrupt 33.
The interrupt-map-mask is simply a mask applied to the child information it's defined as
child.hi child.mid child.lo child.intrspec
Evidently on the Ultra-5, we aren't using three cells to identify the child, only two. So we probably skip child.mid in both of the above specifications.
And what are child.hi and child.lo? Is it the physical address, stored in the reg property?
But then the filter (address & 0x3e) == 0x3c can potentially hit really a lot of devices?
-
Artyom Tarasenko -
Blue Swirl -
Tarl Neustaedter