Re: Generic VME UIO driver

[Martyn Welch <martyn.welch@ge.com>]

On 08/07/15 16:02, Dmitry Kalinkin wrote:
>
>> On 08 Jul 2015, at 16:22, Martyn Welch <martyn.welch@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.

"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@ge.com                  | VAT:GB 927559189