Generic VME UIO driver

Dmitry Kalinkin dmitry.kalinkin at gmail.com
Wed Jul 8 15:02:35 UTC 2015


> On 08 Jul 2015, at 16:22, Martyn Welch <martyn.welch at 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


More information about the devel mailing list