On 08/07/15 16:02, Dmitry Kalinkin wrote:
On 08 Jul 2015, at 16:22, Martyn Welch <martyn.welch@xxxxxx> wrote:
On 06/07/15 18:24, Dmitry Kalinkin wrote:
Some functionality was dropped as it was not good practice
(such as receiving VME interrupts in user space, it's not really doable if
the slave card is Release On Register Access rather than Release on
Acknowledge),
Didn't know about RORA. I wonder how different this is compared to the
PCI bus case.
Little I suspect. What it does mean is that there's no generic mechanism for clearing down an interrupt, so a device specific interrupt routine is required, which needs to be in kernel space.
Yet PCI somehow managed to settle with UIO.
"If, on the other hand, your hardware needs some action to be performed
after each interrupt, then you must do it in your kernel module."
https://www.kernel.org/doc/htmldocs/uio-howto/adding_irq_handler.html
Now imagine I am working with a board using vme_user API and I need to
implement interrupts. The PCI case teaches me that I need to write a board specific
UIO driver. My board is ROAK and allows to configure it's interrupt to any level and
any status/id. So I only use a standard vme_irq_request API that generates IACK
cycle for me automatically. I also don’t want to limit my end user with a choice of
interrupt level and status/id and so I make it configurable. In the end I’ve got a very
generic ROAK device driver. What did I do wrong?
Nothing by the sounds of it. If you have ROAK hardware, life is a lot
simpler.
Martyn
Cheers,
Dmitry
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@xxxxxx | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
