-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue when reading IRQ in PS sent by PL #10
Comments
Hi Roland, Sorry, I must have missed this issue when you filed it. Didn't see it until now... I'm a little puzzled too. According to the Zynq TRM, IRQ 61 belongs to the PL (61 - 32 = 29). Looking at the upstream dts for zynq-7000, dmac interrupts look like this: Which seems OK... Did you find a solution for this already? Thanks, |
Hi Edgard, no problem, fortunatly I found a solution and I found that IRQ 61 belongs to the PL (61 - 32 = 29) as well thank you. So basically when we want to write a device driver subscribing on an IRQ of the Zynq in the Co-Simulation let's do in this way: First of all we need an IRQ handler:
After we have to map the IRQ, so in the device init_module we need something like this:
Remarque: 0x81 in
So the IRQs in the DTS correspond to the SystemC ports in this way:
So basically everithing work fine, I could generate IRQs in PL and subscribe on them by the Device Driver on the PS side :) Best Regards |
Dear all,
My aim is to write a Kernel Device Driver that allows to do operations when an IRQ is sent by the debug module.
In zynq_demo.cc the debug module's IRQ port is binded with the IRQ port of the zynq module :
debug.irq(zynq.pl2ps_irq[0]);
. I found that the IRQ signals are set intorp_wires_in.wires_in
(rp_wires_in.wires_in[i]((pl2ps_irq[i])
) members of thexilinx_zynq
class.After studying the Device Tree Source of remote ports of the zynq-7000
zynq-pl-remoteport.dtsi
I found that therp_wires_in@0
node corresponds to therp_wires_in.wires_in[i]
of thexilinw_zynq class
. In therp_wires_in@0
node there are the following interrupts :I guess that the interruption 29 (
0x0 29 0x4
) corresponds to the first IRQ of the zynq moduledebug.irq(zynq.pl2ps_irq[0])
.In my Kernel Device Driver (test_irq) when I initialize the driver I use the request_irq function to subscribe to the IRQ 29 :
After loading the module
isnmod test_irq.ko
I have the follwong error :The most surprising line of this error is:
[ 29.701282] genirq: Flags mismatch irq 29. 00000084 (test_irq) vs. 00000004 (f8003000.dmac)
that tells us that the f8003000.dmac requiers the IRQ (an the IRQ is not shared), that is quiet strange because in the Device Tree Source in the dmac node the IRQ 29 is not declared:After this error I declared a new IRQ (37) in the node
rp_wires_in@0
so IRQ 37 corresponds todebug.irq(zynq.pl2ps_irq[8])
if I'm not wrong? After loading the module I have no error.In the
/proc/interrupts
I can see that my moduletest_irq
has been subscribed to the IRQ 37 as we can see the log ofcat /proc/interrupts
:The device test_irq is subscribed to IRQ 37, when the debug module writes on its irq port (
irq.write(1);
) the deviceirq_handler
function should be called to print the message: [test_irq] Shared IRQ: Interrupt Occurred, but theirq_handler
function is not called.Do you have any idea, how to solve this problem ? Maybe I should use offsets between the IRQs of
dmac_s
andrp_wires_in
? Or is it an issue of QEMU ?Thank You,
Best Regards
Roland
The text was updated successfully, but these errors were encountered: