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