![]() | |||||||||||||
Messages in this thread |
Dave Olson <olson@unixfolk.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-07-12 09:01 [from the cache] ©2003-2008 | |||||||||||||