lkml.org 
[lkml]   [2015]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectGeneric VME UIO driver
From
Date

> 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.
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

\
 
 \ /
  Last update: 2015-07-08 17:21    [W:0.173 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site