[haiku-commits] Re: r41328 - haiku/trunk/src/system/kernel/arch/x86
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 06 May 2011 21:00:07 +0200
> 2011/5/5 <mmlr@xxxxxxxx>:
> > +static void
> > +pic_disable()
> > +{
> > + // Mask off all interrupts on master and slave
> > + out8(0xff, PIC_MASTER_MASK);
> > + out8(0xff, PIC_SLAVE_MASK);
> > +}
>
> From my understanding this should only be done on systems with a real
> PIC and should be checked beforehand with a flag in the MADT table,
> but since the PIC hasn't been used in ages I think it could safely be
> skipped.
No, you have the IMCR (Interrupt Mode Configuration Register) in mind.
The PIC (whether virtual or physical) is in use on all Haiku installs
right now, so it makes sense to mask it off completely after the
handover. Per specs it shouldn't be necessary as the system actually
needs to detect the configuration of the IOAPIC and turn the PIC off,
but this simply ensures that no doubled interrupts can arrive.
> > // prefer the ioapic over the normal pic
> > dprintf("using ioapic for interrupt routing\n");
> > sCurrentPIC = &ioapicController;
>
> sCurrentPIC should be set to &ioapicController before ACPI init, as
> it
> will install an interrupt handler with the pic interrupt functions
> otherwise.
I'm aware of that (as stated in the commit message), but you can't just
set the controller before initialization. The IOAPIC isn't configured
at this point, so you must not activate one of the entries. Instead
installing of the SCI needs to be delayed on the ACPI side.
> > Modified: haiku/trunk/src/system/kernel/arch/x86/irq_routing_table.
> > cpp
>
> The scanning in this file can probably be rewritten much better. The
> difference between INT and EXTINT is that INT's are internal (to the
> APIC IIRC) and EXTINT are external. I think we should just mess with
> EXTINT. Also it currently only finds PCI root bridges,not PCI-E.
You're mixing up different things here. ExtInt vs. Int is an APIC
configuration telling whether interrupts are delivered on the APIC bus
or not (all of them will be internal when the IOAPIC is in use).
The structures here are acpi_resource_irq vs.
acpi_resource_extended_irq. They both represent routing table entries
where the normal IRQ resource is more limited in what it can describe
(due to using a bitmap instead of vector numbers). ACPICA already
converts both resources to pretty much the same representation (i.e.
converting the bitmap to a vector number), but since the structure
layout is different for both they need to be handled separately. My
system only ever uses acpi_resource_irq, so I can't really tell whether
extended IRQ resources work, but I don't see why not.
> I plan on writing some printing code for _PRS functions, let me know
> if I can help.
There's no need to. The IRQ routing part is basically complete and
works as expected. The missing link is simply that the PCI config space
(and by extension our PCI module) aren't updated with the GSI values.
Therefore drivers will attach to the wrong IRQs (by reading the PIC IRQ
from PCI config space or from pci_info instead of the GSI). To solve
this I attempt to update the PCI config space by writing the GSI to the
interrupt_line register. The only problem hindering this right now is
to correctly match the device _ADR to a PCI module device (or an
ACPI_PCI_ID). I'm currently testing out different possibilities to get
that matching going. From there on out things should be good to go,
except for maybe blacklisting / quirk handling. FreeBSD simply checks
the BIOS date for that and cuts off at 1998 IIRC which seems like a
simple but effective approach.
Regards
Michael
Other related posts:
