Re: [PATCH] x86: Get irq for hpet timer

[Kevin Hao <kexin.hao@windriver.com>]

On Thu, 2008-05-22 at 04:47 +0100, Maciej W. Rozycki wrote:
> On Wed, 21 May 2008, Clemens Ladisch wrote:
> 
> > >  Hmm, you probably want to skip all lines that are edge-triggered.
> > > Otherwise you may have problems with sharing.
> > 
> > HPET interrupts can be either edge or level triggered.  Probably we
> > should modify it according to the type of the interrupt line we're
> > trying to grab.
> 
>  Edge-triggered lines are generally associated with legacy devices.  It
> may not be possible to grab one without disturbing the other device.
> 
> > >  This driver is quite platform-specific -- how about instead of blindly
> > > probing for interrupt lines, you actually allocate one somehow in platform
> > > code?
> > 
> > I don't have much of a clue about that "somehow", but this sound like a
> > good idea.  ;-)
> > 
> > I think hpet_reserve_platform_timers() might be the place for this.
> > 
> > It gets called from hpet_late_init(), which is a fs_initcall, so I think
> > we should be careful not to grab some unsharable interrupt that might be
> > needed by some ISA device whose driver is initialized later.
> > (This was a bug in 2.6.25-rc5: <http://bugzilla.kernel.org/show_bug.cgi?id=10382>)
> 
>  I have had a look at the relevant areas of ACPI and HPET specs and it
> looks pretty straightforward, although not all the information is recorded
> in system tables.  Essentially you are free to choose an arbitrary
> interrupt supported by the HPET -- which you can find in the timer's
> routing capability (as the proposed patch is doing).
> 
>  However you are right you really want to select one which does not
> conflict with a legacy device, so it's probably best to avoid the legacy
> range altogether (worth noting as for example the system I have handy has
> the capability of its timer #2 set to 0x00f00800 -- here IRQ11 may not be
> safe to use)

But if we avoid all the legacy range, the hpet timer will have no chance
to work on a host using legacy PIC.

>  and then you have to check how many inputs beyond the legacy
> range are supported by the I/O APICs in the system -- you can have a look
> at mp_find_ioapic() to see how obtain that information and then you can
> call mp_register_gsi() on the interrupt line selected like this to set up
> routing in the I/O APIC as necessary.  Level-triggered mode has to be used
> as the resulting interrupt entry may happen to be shared with a PCI
> interrupt.

Yes, we should setup routing in the I/O APIC and use level-triggered
mode. I think it's better to use acpi_register_gsi than mp_register_gsi.
Is that right?

Best Regards,
Kevin

> 
>  Though I have just noticed there is something wrong with the spec -- it
> says that "The interrupts are all active high." which precludes sharing,
> hmm... -- broken spec?  If hardware designers actually followed it in this
> respect (I wouldn't be surprised as for some of them software is abstract
> enough a concept not to be bothered with, and then it is a spec after
> all), then I am afraid we need to have a way to get an exclusive
> reservation of an I/O APIC line.  It could be tough with a system using
> fixed routing and reusing a legacy IRQ might be the only choice -- if
> supported by the HPET router, that is.
> 
>  Of course if the HPET supports MSI delivery and the kernel configuration
> has it enabled, then you can avoid all the hassle with finding an
> available IRQ line altogether.
> 
>   Maciej