Message-ID: <Pine.LNX.4.55.0805220105560.4894@cliff.in.clinika.pl>
Date:	Thu, 22 May 2008 04:47:00 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Clemens Ladisch <clemens@...isch.de>
cc:	Kevin Hao <kexin.hao@...driver.com>, venkatesh.pallipadi@...el.com,
	bob.picco@...com, mingo@...hat.com, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, Balaji Rao <balajirrao@...il.com>
Subject: Re: [PATCH] x86: Get irq for hpet timer

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) 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.

 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists