> On 08 Jul 2015, at 16:22, Martyn Welch <martyn.we...@ge.com> 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-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
