News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

IRQF2P Interupt not being seen in driver when moving to 4.4, but works in 3.17

Started by danwwright, October 10, 2016, 11:36:28 PM

Previous topic - Next topic

danwwright

I am facing this issue- no fabric interrupts seen by my driver after the move to kernel 4.4.  I've read that I should find the interrupt numbers dynamically in my driver via calls to:
platform_get_resource(pdev, IORESOURCE_IRQ, 0);
but when I add this platform_get_resource() call to my driver probe() function it always returns NULL.  I'm guessing that this is because my device tree is deficient somehow.  My issue is how to correctly remedy this.

My driver has built into it Xilinx SDK code for speaking with:
axi_dma (3 instances)
axi_gpio (1 instance), and
axi_uartlite  (1 instance).
All 5 of these interrupts I would like to map to my driver.

My device tree was generated by "petalinux-config --get-hw-description=hw-description" using the .hdf exported from my Vivado design and so the generated pl.dtsi has device tree entries that contain all the particulars needed to make the kernel aware of the existence of my peripherals in the FPGA fabric.

My challenge is how to compose a correct device tree entry to make the system aware that all of these "belong to" my driver so that (presumably) the platform_get_resource() call in my driver probe() function will no longer be returning NULL and so that I can get the interrupts mapped correctly.

Can anyone point me to an example of such a device tree entry?  The example would need to show how all 5 of these relevant interrupts can all be forwarded to the specified driver.  Thanks!

Andrei Errapart

What is in your device tree right now?

Couldn't you just override the "compatibility" property of all the devices in the device tree to the one specified in your driver? This way it will be almost automatic, only minimal amount of device tree has to be overriden. The probe() function will be called 5 times, once for every device, thus some bookkeeping will be necessary.

danwwright

You're right- the problem in my device tree attempts before had been that the "compatibility" property was not pointing to my driver.  I fixed that and I now have a working driver that IS seeing the fabric interrupts.  Thanks!