Start a new topic

interrupt driven BSP

We have a PC720 with an FMC110 and our application requires that we have a method to use interrupt driven DMA.  What we would like to do is generate an interrupt inside the FPGA when our custom logic finished then our software on the host PC wakes up with the interrupt and performs a DMA pull.  Your driver and firmware as provided do not support interrupts. We met with Pierrick today and he mentioned that in the past the BSP had interrupt support and suggested that you might be able to provide the code to generate and handle interupts for the PC720.  We are using 64 bit linux if the driver exists.

Dear Sir,

There is a mailbox system in the 4FM API and the firmware can send 32 bit values to a mailbox.

The idea is that the software is waiting on a mailbox to arrive (the function for that is blocking, _4FM_ReadMailbox()). Generally the value returned is the number of bytes to offload so the sw can offload the data.  So you can have a loop constantly waiting for a mailbox to arrive before to move forward; This the way we implemented many recorders.

Also know that the mailbox scheme as a software queue in the device driver so you cannot miss a mailbox which makes the scheme reliable.

On the firmware side, I believe that the mailbox interface is there in the pc720_host_if but simply not used, I will need to confirm that if you need so.

I hope that helps!

Best Regards,
Hello Again,

On windows we also have a scheme built around overlapped IO structure where you can use Windows "events
" in order to wake up a sleeping process.

This is not available on Linux unfortunately. I believe you could have a thread waiting on _4FM_ReadMailBox, offloading the data and telling another processing thread some data is being available. Just make sure to only have one thread communicating with the PC720 at once, concurrent access is not supported.

Best Regards,

Have you ever used true PCIe interrupts in the linux driver?
Dear Sir,

The device driver is using interrupts; there are several interrupt sources registered in the device driver.

As far as the mailbox is concerned, each time a mailbox interrupt is received, the device driver stores the value in a software queue. Reading the register clears the interrupt (this is in kernel code).

On the API side, the read mailbox function asks a mailbox value from the software fifo and wait up to the next device driver ping; either the value or a timeout value coming from the device driver. The function is blocking during this time.

The scheme is perfectly sound. A thread is waiting on a ping from the firmware, blocking on the read mailbox function. As soon the ping is received, read mail box function returns letting the thread know how many byte to offload. If the size of data is constant, then the mailbox value is dummy. As soon the data is received, in other words the read data completed (also blocking) you notify the worker thread about it. Generally you would use a double buffering scheme, where the worker thread consumes data while another DMA operation is running.

I hope that helps,

Thanks. My concern was that the check mailbox was polling the card over and over. This would degrade pcie bus performance.  It sounds like although blocking, the check mailbox function uses interrupts so it doesn't tie up the pcie bus during waits.  I understand that I can't open more than one handle to a single card so the polling wouldn't be an issue but I will have 8 cards sharing the bus so obviously ting up the pcie bank with looping "peek" operations would take a toll on performance.

Thanks for the insight I think I have what I needed.
Perfect, thanks for the feedback!
This topic is being closed because the issue is considered as resolved by 4DSP. Feel free to create a new topic for any further inquiries.