05-24-2012 10:47 PM
I have a ZC702 board loaded with a custom PL device running Linux. The custom device can assert the Shared Peripheral Interrupt of FPGA0 (#61). In the device driver, the request_irq() function was used to bind ISR with IRQ61.
After loading the driver with 'modprobe drivername', the /proc/interrupts shows the binding of device driver (sevdev_alt) and IRQ-61 was successful; see below:
61: 0 0 GIC sevdev_alt
At triggering the device to assert the IRQ line, cscope showed the assertion of device output as expected.
However, the ISR was NOT invoked. This was confirmed via the /proc/interrupts AND a driver parameter that counts number of times being interrupted.
The result was same with either edge or level setting.
I am pretty sure device's output was properly connected to the FPGA0 pin of GIC. Unfortunately cscope can only probe this far.
What might be wrong? Any debugging suggestion?
06-01-2012 07:24 AM
Hi. We have a similar problem. Might be the same root cause. I have set up my Linux IRQ handler for IRQ61 just like above using irq_request().
If I set the bit for IRQ61 in the ICDISPR1 "Set-Pending" register:
$ devmem 0xf8f01204 32 0x20000000
...the interrupt handler fires just like expected, so the Linux side of things seems to be ok. I'm using the default trigger option which seems to be fine for other peripherals in the chip.
However, I get no response when the FPGA side sets the IRQF2P signal bit 0 or bit 1 (we will use both). The FPGA guys assures me that things are correct on their side as far as they can see :)
Now on to the in my view pretty funny/strange observation I did:
I had a look on the spi_status_1 register at 0xF8F01D08 where I was expecting to find the raw interrupt status for irq61. In this register I can actually see bits toggling when toggling the IRQ status from the FPGA side, so the connection is somewhat working. However, instead of bit 29 and 30 as I would have expected, it is bit 26 and 27 which toggles, which in my view would correspond to IRQ 59 and 58.
Is this really expected behaviour? :)
Is there something else that has to be done to the interrupt controller to make it accept the PL interrupts? I've been spending some hours reading the data sheet but cannot find anything, but I might very well have missed something.
06-03-2012 09:58 PM
Thanks for posting your observation.
No, I have not had a solution for that yet.
06-05-2012 06:21 AM
06-05-2012 07:17 AM
Would you shed some light?
How did IRQF2P ends up on IRQ91?
Did you not see the IDCSPR bit 58 when interrupt is asserted anymore?
Did you need to change hardware at all?
06-05-2012 07:24 AM
More info: IRQF2P is actually not bit reversed, but padded from the wrong direction. So if using one interrupt it ends up on IRQ91 instead of 61, two interrupts; IRQ 90 and 91 and so on. Xilinx is looking into fixing the padding.
I do not know the reason for the funny bits in the spi_status register, maybe those bits are not linearly mapped to SPI IRQ numbers. Since I've got the interrupt handling working, I will not look into it more. :)
06-05-2012 07:26 AM
06-05-2012 04:28 PM
Maybe this can help:
@0xF8F01D04, spi_status_0 is IRQ#32 ( SPI#0 )
@0xF8F01D04, spi_status_0 is IRQ#63 ( SPI#31 )
@0xF8F01D08, spi_status_1 is IRQ#64 ( SPI#32 )
@0xF8F01D08, spi_status_1 is IRQ#95 ( SPI#63 )
I beleive the documentation is a little bit misleading.
02-09-2013 08:52 AM
I have the same problem. The driver detects the new IP component into the PL, but the interrupt handler is never executed. Any suggestion?
05-15-2013 01:24 AM
Actually I am doing project with zedboard, I added a custom peripheral I want use it in interrupt in all example that I said with zynq they use the Axi gpio in orfer to use interrupt. In my case I have a custom peripheral that I added with the create import peripheral and I don't know how do the interrupt. Do you have an indea ?