> 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. 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? Cheers, Dmitry _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
