[haiku-development] Re: Free irq

  • From: "Michael Lotz" <mmlr@xxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 14 Oct 2011 12:44:49 +0200

Stefano Ceccherini <stefano.ceccherini@xxxxxxxxx> wrote:
> It's not exactly like that. A HPET timer can be routed to various irq
> lines, and these are listed in the timer capability register.
> For example, my Fujitsu-Siemens laptop's HPET timers can be routed to
> irq 11, 21, 23, 24. On Qemu it seems they can be routed to irq 2 
> only.
> After you chose an interrupt (and here, it's better to use a free
> one), you set a bit in the HPET timer configuration register, and use
> install_io_interrupt_handler() like any other driver which needs an
> interrupt.

I see, so it's a normal routed interrupt then, not one that can be 
generated locally (via APIC/CPU directly).

> Now, the problem is that I have no way to tell if the interrupt I
> chose is already taken.
> I guess that with the new interrupt api you introduced
> reserve_io_interrupt_vectors(), etc.) I could try every interrupt in
> the HPET list until I get one which is not taken.
> Correct ?

Not exactly. The purpose of the new API is to coordinate between the 
entities that generate interrupt vectors in the various ways. The routed 
interrupts coming in via legacy PIC / IO-APIC, the SMP interrupts and 
possibly APIC timer interrupts coming in via the local APIC directly, 
MSI/MSI-X messages and software generated vectors (i.e. syscalls) 
generated directly on the CPU. All of these need a chunk out of the 256 
- ARCH_INTERRUPT_BASE IO interrupt vectors and they need to know which 
ones to use.

In your case though, it seems as if the interrupts are just normal 
routed interrupts (via PIC, IO-APIC) so they can in all likelihood be 
shared as well. They have to fall within the vector range of the PIC or 
IO-APIC, so you can't reserve them. Routed interrupts tend to be 
hardcoded in one way or another either by being actually just hardwired 
to the corresponding pins, or by being routed to a link device that can 
be set to one of a few possible interrupt lines (they're not as 
frequently encountered than fixed configs though from my experience). 
Everything > ISA has to have their interrupts shareable, i.e. the 
devices provide an interrupt status register in some form to check if 
an interrupt was actually generated by the device in question, so 
installing multiple interrupt handlers on the same vector is not a 
problem there (other than the performance overhead). If this is true 
for the HPET as well then you can just pick a vector at random and 
install the interrupt handler onto it as would any other device driver.

If you actually need a non-shared interrupt, then we need another API 
to reserve/find non-shareable interrupts within a certain "vector 
domain" (the IO-APIC routed interrupts for example). The problem with 
that is that even if you get a non-shared interrupt at the time you 
install your handler (a simple flag could be defined that requests non-
shareability on installing the handler), it isn't really guarantued 
that no-one actually needs that vector later on. I fear that you might 
not be able to find a "free" slot in all (many? most?) cases actually, 
because of the fixed routed interrupt lines.

So basically the question is if your HPET interrupts are shareable or 
not. If they aren't then we'll have to come up with an API extension to 
allow installing non-shareable interrupt handlers (and possibly a 
callback to notify in the conflict case so that you could try 
installing to a different vector)...

Regards
Michael

Other related posts: