[parisc-linux] Thoughts on arch/parisc/irq.c

[Alan Cox]

> Alan - looks like something got dropped here. Try again?

The perils of 2am posting - add the word "different"

> I think there is going to a problem with "cookies" on PA.
> The problem is GSC devices need to program an "EIM" register.
> (For Dino, this is IAR0). The contents of the EIM register
> are a processor HPA (bits 11-31) and EIRR bit number (bits 0-4;
> ie a value 0-31). The location of this register is NOT
> defined by PA I/O architecture - or at least not well defined.
> Is this a real problem or not?

It isnt. If need be you hand out irq numbers to drivers that are
indexes into an array that gives all the real gsc/pci mappings, registers
and other goodies.

> > on the next return. BH's are not run if they are already running - they
> > are single threaded with respect to each other right now - that may change
> > to be 'with respect to self' one day.
> 
> For single CPU is doesn't matter. For SMP scalability it might.

Thats why it might change 

> SPL levels allow the system clock to always get service regardless of how
> badly an ISR behaves on the interrupt stack. SPL levels also allow

We flame people who write badly behaving irq handlers instead. 

> to guarantee the timeout is called "pretty soon". SPL levels also
> allow device drivers to service IRQs while the bottom half is active.

We service IRQs with the bottom half active. The idea is that all non
immediate processing occurs at bh layer - think of the BH system as a BSD
like kernel with only one SPL level.

Having one level reflects the realities of more machines and doesn't really
lose us anything. A typical example flow is

	user space
	[IRQ arrives]
		myether_irq
			handle ring buffer
			netif_rx(buffer)
		 	(marks the NET bh to run)
		end irq
		runs net_bh if not running, irqs are enabled
		process packets
		done
	user space


Alan