Handling interrupt routing cleanly...
Tarl Neustaedter
Tarl.Neustaedter at sun.com
Wed Feb 4 19:14:00 CET 2004
Eric W. Biederman wrote:
>>Plural. We have a number of devices which generate multiple interrupts.
>>On PCI, that usually means being constrained to four interrupts, but
>>for on-board devices we can deal with whole bunches of interrupt lines
>>per device.
>
>
> That part I could not quite understand when reading the OF spec. How
> you can have multiple values per property. Base address registers
> seemed to have the same problem.
Ah. In the case of interrupts, where it's usually a single-cell
value per interrupt, a trivial case is encoded as:
h# 17 encode-int " interrupts" property
In the case of a PCI slot where we (OpenFirmware) don't know what
the device is, but have to allow for all four interrupts being
used, we'll do something like:
h# 1 encode-int
h# 2 encode-int encode+ \ encode+ concatenates two encoded properties
h# 3 encode-int encode+
h# 4 encode-int encode+ " interrupts" property
When retrieving the property, you always get a address/length pair.
It's up to the consumer to know what the base length of the item
is, to know whether it's one or more items. In the above particular
case:
{2} ok " interrupts" get-property
{2} ok .s \ Show what stack has; address length false
f00da140 10 0
{2} ok drop dump
\/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
f00da140 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 ................
This shows four (4-byte) cells, containing 1,2,3 and 4.
The "reg" property is more of the same, but it's almost always
got multiple entries. E.g., for a PCI device, we'll have a reg
property with 5 cells for each entry (three address and two size),
and at least two entries:
reg 00000800 00000000 00000000 00000000 00000000
02000810 00000000 00000000 00000000 00200000
The first line describes config space for a device, in this case
for a device on pci address 1, function 0. The next four cells
aren't relevant for config-space entries.
The second line describes a BAR; in this case, a memory addressable BAR
at offset 10, which describes 200000 bytes of address space. Since this
bar is relocateable, the 2nd and 3d cells are not filled in (are zeroes).
> The only interesting thing I have is that in when using
> APICs interrupts are routed differently than when using
> the legacy x86 PIC.
Ah. That I missed. I'd never thought of interrupts being
routed differently depending on something else. Assuming
Linux is only going to use APICs, I wouldn't bother
describing the legacy PIC, unless I'm missing something
about interrupt configuration requiring that information
anyway.
Tarl
More information about the coreboot
mailing list