2010-12-09 22:41:53 Writing an interrupt handler
Wojtek Skulski (UNITED STATES)
Message: 96595
I am now starting to develop my own very first interrupt handler. The hardware is a software developer's dream: the FPGA device raises PF1 HIGH when it wants to be serviced. The service routine needs to read a few ASRAM arrays, and then write a word to an ASRAM location to restart the FPGA. Nothing could be simpler than this.
Is UIO a good starting point to begin writing such a driver? Or is there some more relevant interrupt handler to tweak?
QuoteReplyEditDelete
2010-12-09 22:44:53 Re: Writing an interrupt handler
Mike Frysinger (UNITED STATES)
Message: 96597
if you only thing you need to do is notify user space when a GPIO interrupt goes off, you could use the existing gpio-keys driver and treat it as a button press
otherwise, UIO probably would be the way to go
QuoteReplyEditDelete
2010-12-09 22:53:48 Re: Writing an interrupt handler
Wojtek Skulski (UNITED STATES)
Message: 96598
Mike:
On interrupt I want to read the FPGA content (80 kB now, up to a 603 kB in future) and process this data. I have read about "top and bottom halves" and I am trying to fit this info into expectations. I think I need to grab the 80 kB as fast as I can, stuff into some SDRAM buffer, and return from interrupt. The "other half of the driver" will process the data in user space.
I vaguely feel that UIO is the right framework for doing this, but I am not sure. I am now fishing for the hints where to start. I will appreciate your suggestions.
QuoteReplyEditDelete
2010-12-09 22:58:29 Re: Writing an interrupt handler
Mike Frysinger (UNITED STATES)
Message: 96599
UIO would only ack the interrupt. reading the data out of the fpga would be left to userspace.
QuoteReplyEditDelete
2010-12-09 23:13:01 Re: Writing an interrupt handler
Wojtek Skulski (UNITED STATES)
Message: 96600
Reading in user space may not be good. When the interrupt "event" occurs, I need to (1) move the captured data out of the FPGA as quickly as possible to prepare it for the next "event". (2) Store the data safely somewhere in SDRAM. (3) Let the user space process the the circular buffer holding one or more "events".
I am thinking that the interrupt routine should quickly transfer 80 kB from the FPGA to SDRAM (using DMA perhaps?) and return. The user space task (periodic perhaps?) will look at the SDRAM area and if it sees one or more "events", it will process them.
It looks like a "classic" scheme to me. I am trying to make sure whether UIO is the right framework.
UIO documentation is not clear to me at this point, what makes me think that perhaps it is not the right place to start.
QuoteReplyEditDelete
2010-12-09 23:27:43 Re: Writing an interrupt handler
Mike Frysinger (UNITED STATES)
Message: 96601
seems fairly complete to me:
docs.blackfin.uclinux.org/kernel/generated/uio-howto/index.html
perhaps you could declare the buffer via UIO and let userspace mmap it and have the handler do a dma_memcpy() into it.
QuoteReplyEditDelete
2010-12-10 09:54:20 Re: Writing an interrupt handler
Wojtek Skulski (UNITED STATES)
Message: 96632 Mike:
thank you for the pointer. I will dive into this. Just one question. You
are saying "mmap". But previously you said that mmap is not needed on
Blackfin architecture and one should use bare memory addresses. In fact,
in my user space programs I am accessing FPGA mapped as ASRAM
without ever calling mmap. And it works.
Could you please clarify when to use mmap, and when not? Why should I
call mmap per your advice, while previously you said not to use it?
QuoteReplyEditDelete
2010-12-10 11:37:48 Re: Writing an interrupt handler
Mike Frysinger (UNITED STATES)
Message: 96633
you're talking about sharing temporary memory between kernel space and user space via UIO. but there is no way for user space to know where that memory lives unless you do it dynamically by asking the kernel via mmap.
not all mmaps are created equal.
QuoteReplyEditDelete
2010-12-10 11:55:34 Re: Writing an interrupt handler
Wojtek Skulski (UNITED STATES)
Message: 96634 Mike: thank you for the explanation.