Re: [Xen-ia64-devel] consoles, iosapics, and device interrupts

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Lundi 21 Novembre 2005 16:58, Alex Williamson a écrit :
> On Mon, 2005-11-21 at 12:51 +0200, Tristan Gingold wrote:
> > Le Vendredi 18 Novembre 2005 16:52, Alex Williamson a écrit :
> > >    AFAICT, ns16550 only outputs a character at a time, so interrupt vs
> > > polling doesn't really come into play for early output.  The problem
> > > though is how do we get the irq data back into ns16550?  We have to
> > > call acpi_register_gsi() to translate the PCDP provided GSI to an irq
> > > vector. That can only be done after acpi_boot_init() finds the IOSAPICs
> > > in late_setup_arch().  We certainly don't want to go blind (no console)
> > > until most of the way through late_setup_arch().  Thus we need some way
> > > to get an output console working early, then register the IRQ later.  I
> > > don't know how to do that cleanly.
> >
> > I don't understand here.  This is already how it works: the console first
> > works by polling, then the IRQ *might* be enabled later.
>
>    This is the way the normal 8250 serial driver works in the Linux
> kernel, but I don't believe the same can be said for the ns16550 driver
> in the hypervisor.  Polling would require that a timer periodically
> check the UART for work.  I don't see that such a mechanism exists.
> Therefore, an IRQ must be enabled by the ns16550 driver to get console
> input.  Console output appears to be un-buffered and sent a character at
> a time.  Therefore console output works even w/o interrupts.
Yes.
We were misunderstanding: console output always works!


>    To get an IOSAPIC based interrupt working, we first need to get the
> Global System Interrupt (GSI) for the device.  This effectively
> describes the Redirection Table Entry (RTE) of the IOSAPIC the device
> pulls for an interrupt.  The GSI doesn't really mean anything until we
> use it to program the RTE on the IOSAPIC with an interrupt vector.  At
> the point where we currently call ns16550_init(), we only know the GSI.
> The processor side "IRQ" cannot be known until we discover the IOSAPIC
> namespace and are able to register the GSI and translate it into an
> interrupt vector via acpi_register_gsi().  The driver initialization
> function ns16550_init() expects a data structure complete with the
> processor interrupt vector for the device.  We don't know that at the
> time it's currently called, nor does the ns16550 driver provide a way to
> update the IRQ information later other than to call ns16550_init()
> again.  Hope that helps,
Right.
However the 16550 can be programmed using the ISA compatibility stuff.  The 
IRQ pin and IOSAPIC can be determined from the IRQ number.

Tristan.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel