Ok, fair enough, you can see all *_EOF interrupts as being consumed by one
user - the dma channel driver. So then it is similar to a serial (or
whatever else) driver handling multiple instances of the hardware on one
system.
Let's consider what we would get, if we don't use the irq chip API:
1. we request two interrupts - function and error - normally using
request_irq in the ipu irq driver
2. in the dma channel driver you have to register new clients with the ipu
irq driver so it can call the dma channel driver EOF irq handler with
the correct argument - the number of interrupting DMA channel
3. on an interrupt you have to implement masking / unmasking / acking of
interrupts, list locking, whatever it takes yourself
so you end up with an API similar to ipu_request_irq() from Freescale...
Yes, you can allocate your interrupt descriptors dynamically, you can save
a few more bytes in every descriptor object... But is it all worth it?
Ok, we can make this differently:
1. I create a static constant array of virtual irq number <-> ipu irq bit
maps, with currently only two elements - for the framebuffer and the
camera, and use it in irq demultiplexing.
2. I increment NR_IRQS by two and put a comment explaining where to look
for implementing support for more IPU interrupts.
3. as new users come and implement support for more IPU interrupts, they
add entries to the array and increment NR_IRQS.
This way we add only as many irq descriptors as we really use, but the
mapping becomes absolutely internal, so looking in /proc/interupts gives
you little understanding of whose interrupts you see there.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
