Dave Olson <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
