On Wed, Apr 22, 2009 at 8:49 AM, Eddie Dawydiuk <[email protected]> wrote: > Hello, > > I'm working on a board based on the Yosemite AMCC 440EP. We have an FPGA > connected via the PCI bus, and has an IRQ line connected directly to the > 440EP. The FPGA implements two registers to indicate which core generated > the interrupt. So now the question is from a design standpoint is it > preferable to setup the IRQ as a single external IRQ then have each driver > request this same IRQ. In each ISR the driver is responsible for checking > the FPGA registers to see if the interrupt is intended for itself. Or would > it be preferable to modify the lower level irq routines such that multiple > software/virtual(not sure what the right term is here) irqs are created > corresponding to the single external IRQ. Then abstract the details of the > FPGA interrupt registers from each driver. Such that each driver request the > proper software/virtual IRQ and requires no knowledge of the fpga irq > registers. Any comments would be appreciated.
Both approaches are valid and you can use your judgment here, but here are some suggestions: If the IRQs need to be explicity acked in the FPGA iq controller, then I'd probably write a cascaded irq driver. Or, if you will be using existing device drivers, then I would also probably do a cascaded driver. However, if you're writing one-off custom drivers and there is no common coded needed for acking irqs, then I would probably just use the external IRQ. g. _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
