Re: [Qemu-devel] device assignment for embedded Power

[Scott Wood]

On Fri, 1 Jul 2011 17:32:43 -0500
Anthony Liguori <address@hidden> wrote:

> On 07/01/2011 11:43 AM, Scott Wood wrote:
> > However, we'll need to address the question of what it means to say "irq 10"
> 
> It depends on what the bus is.  If you're going to declare "system bus" 
> which is sort of what we call ISA for the PC,

More like "arbitrary MMIO".  Could be an on-chip peripheral.  Could be some
external custom chip.  Could be an entire PCIe root complex.

> then it can map trivially to the interrupt controller's inputs.

Which interrupt controller?  We might want to assign an IRQ that's on some
cascaded controller.

We also have some things like MPIC IPIs and timers,
that are on the main interrupt controller but aren't normal numbered
interrupts.  We use the ability to have multiple cells in an interrupt
specifier to express these.  And while you could make up fake numbers for
these to force it to be linear, someone has to come up with this mapping and
get qemu, its users, and the kernel to agree on it.  We already have a
repository for such bindings for the device tree.

That's not to say that the device tree should be forced onto platforms that
have some other reasonable way of doing it, of course -- just that it's
nice to be able to refer to it when it's there.

> > -- outside of PC-land there often isn't a global IRQ numberspace that isn't
> > a fiction created by some software layer.
> 
> PC's don't have a global IRQ number space FWIW.  When we say:
> 
> -device isa-serial,irq=4
> 
> This really means, "ISA irq 4", which is mapped to the PIIX3 and then 
> routed through GSI, then the APIC architecture to correspond to some 
> interrupt for some physical CPU.

Well, it's been a while since I've dealt with such things on PCs...  I
thought there was at least some standard way of interpreting things like
IRQ numbers that the BIOS wrote into PCI config space.

> > Addressing this is one of the
> > device tree's strengths.
> 
> Not really.  There's nothing magical about the device tree.  It's just a 
> guest visible description of the platform hardware that isn't probe-able 
> in some bus framework.  ACPI does exactly the same thing.  I'll concede 
> that the device tree is far nicer than ACPI but again, it's not magical :-)

I didn't say it was the only way to express it -- just that the device tree,
or something like it, comes in useful here.

And we're not about to do ACPI on powerpc. :-)

-Scott