Re: [PATCH 2/2] Initial generic hypertransport interrupt support.

[Eric W. Biederman]

Dave Olson <olson@xxxxxxxxxxxx> writes:

> On Tue, 11 Jul 2006, Eric W. Biederman wrote:
> | There is a hypertransport capability that implements a rough equivalent
> | of a per device ioapic.  It is quite similar to MSI but with a different
> | register level interface.
>
> It's really just the same as MSI, and is set up and handled pretty
> much the same way.

No it is not just the same.  There is not global enable bit, only
per irq enables.  There is always a mask bit.  The ht irq generates
a 0 byte (with magic defines for the 32 byte enables) write while an
msi generates a 4 byte write with no byte enables.  With ht irqs
the maximum number of irqs is 120 not the one with plain MSI or
the 4k with MSI-X.

But from the perspective of using them in a driver the concept really
is the same.


> | Since native hypertransport devices do not implement a pin emulation mode
> | as native pci express devices do so if you want an interrupt you must support
> | the native hypertransport method.
>
> Right.
>
> | The pathscale ipath-ht400 driver already in the kernel tree uses these
> | and uses so an ugly hack to make work that broke in the last round of
> | the msi cleanups.  I also know of a driver under development for a
> | device that uses these as well.
>
> Umm, it's not broken by any of the the MSI cleanups, at least
> through last week's 2.6.18.

The code that breaks it is only in -mm.  It's scheduled for 2.6.19.
All of the MSI magic in ioapic land on i386 and x86_64 is deleted.
The code just needs to age a bit and let the few unexpected
corner case crop up, and get sorted out.

Hopefully fixing the ipath driver is one of the things we can sort out.

> | So I want to use this so I can get irqs from native hypertransport
> | devices.
>
> This part I never really quite understood.  Why do you want a separate
> interface than the existing request_irq().

request_irq is still needed.  The question is how do you get the irq.

> and pci_enable_msi()? 

The HT and msi semantics are moderately different, but I have
implemented the equivalent of pci_enable/disable_msi.  So the
code is not a pci standard but just a ht standard I didn't use the
pci prefix.

>  Yes,
> there needs to be some HT-specific implementation behind it, but I
> don't see a reason for a whole new interface.  Most of the rest of
> the HT stuff is setup via the pci_* functions, so why not the interrupts?

The reason I did not reuse code from msi.c is that the code in msi.c
is absolutely terrible.  Also note that even the different flavors
of msi have their own enable/disable routines.

I expect I will make msi.c match htirq.c instead of the other way around.
Of course I don't expect the interface exported to drivers to change.

Eric


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