Thoughts on arch/parisc/irq.c
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines
I'm still convinced PA Processor HPAs should be passed to GSC drivers seperately (eg
dino.c). On IA64 platforms, I/O SAPIC and Local Sapic also seperate the target address and "vector". I left David Mossberger voice mail about this - I suspect/hope the problem has already been solved.
Passing that kind of info out to arch specific drivers is ok. The rest of the system wants a single opaque long cookie (with or without milk) . You can even make that cookie a cast on a struct addr.
Quoted 2 lines
Not HP's style. Too hostile. The process is to file "Change Requests"
- a kind of black hole where managers pull statistics. :^)
I've dealt with HP in another project. Im glad TPG are doing the HP interfacing not me 8)
Quoted 3 lines
I see three levels: block all IRQs, enable IRQs, and bh. It sounds like those correspond to SPLHI/SPL7, SPL5, and SPL2. Am I still on the right track?
Yes I think so. Im not that hot on the old BSD terminology
Quoted 4 lines
implement more than one level of SPL. But I now agree not much is lost since two important levels are supported. As long as the clock gets serviced, the timeouts it generates would run at about the same time. More on this below.
We never do timeouts in loops in an IRQ handler by checking versus the clock. We also tend to use RDTSC or similar features if available - apic clock, etc so we recover lost ticks too
Quoted 2 lines
in this context. Knowing that Intel is eager to support UDI on linux, I would be worried about how UDI is made to work. (Hint: I worked on
I don't know any major Linux hacker who views UDI with anything but mild amusement. Linux people tend to be latency freaks.
Quoted 4 lines
After doing this exercise, I agree with Alan - not much is lost. The ATT flavor Unixes need SPL6 because streams processing (another message passing subsystem) can take a really long time in the IRQ context and thus block the clock.
The crazies at gcom who did some streams based stuff for Linux (not in the standard kernel) do their streams processing in the bh context for some reason.
Where we get drivers for hardware that is really horrible we sometimes do
my_irq
mark_bh
mask irq
return from irq
as the entire IRQ handler - the aha152x scsi controller is an example of that. Thankfully for the devices people buy when they want speed you don't have that problem.
Alan