Handling interrupt routing cleanly...

[Tarl Neustaedter]

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