Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

[Martyn Welch]

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.

> > >so the interface became more of a debug mechanism for me.
> > >Others have clearly found it provides enough for them to allow drivers to be
> > >written in user space.
> > >
> > >I was thinking that the opposite might be better, no windows were mapped at
> > >module load, windows could be allocated and mapped using the control device.
> > >This would ensure that unused resources were still available for kernel
> > >based drivers and would mean the driver wouldn't be pre-allocating a bunch
> > >of fairly substantially sized slave window buffers (the buffers could also
> > >be allocated to match the size of the slave window requested). What do you
> > >think?
> I'm not a VME expert, but it seems that VME windows are a quiet limited resource
> no matter how you allocate your resources. Theoretically we could put up to 32
> different boards in a single crate, so there won't be enough windows for each
> driver to allocate. That said, there is no way around this when putting together
> a really heterogeneous VME system. To overcome such problem, one could
> develop a different kernel API that would not provide windows to the
> drivers, but
> handle reads and writes by reconfiguring windows on the fly, which in turn would
> introduce more latency. Those who need such API are welcome to develop it:)

The aim of the existing APIs is to provide a mechanism for allocating 
resources. You're right, the resources are limited when scaling to a 32 
slot crate. There's a number of ways to share the resources, though they 
tend to all have trade offs. My experience has been that the majority of 
VME systems don't tend to stretch up to 32 cards.

> As for dynamic vme_user device allocation, I don't see the point in this.
> The only existing kernel VME driver allocates windows in advance, user is just
> to make sure to leave one free window if she wants to use that. Module parameter
> for window count will be dynamic enough to handle that.

If vme_user grabs all the VME windows, there are no windows available 
for any kernel level VME drivers to use. If a kernel level driver loads 
before vme_user and is allocated a window, if vme_user demands 8 windows 
(and assuming it doesn't deal with some already having been allocated 
gracefully, which it doesn't at the moment) then it doesn't load. 
Dynamic allocation would leave "unused" resources available rather than 
prospectively hogging them.

--
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@xxxxxx                  | VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/