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

Alessio Igor Bogani alessioigorbogani at gmail.com
Tue Jul 7 12:51:13 UTC 2015


Hi Dmitry,

On 7 July 2015 at 12:47, Dmitry Kalinkin <dmitry.kalinkin at gmail.com> wrote:
[...]
> The API I had in mind would have only vme_master_read and vme_master_write
> that would take absolute addresses (not relative to any window). These
> variants
> of access functions would then try to reuse any window that is already able
> to serve
> the request or wait for a free window and reconfigure it for the need of the
> request.
> After usage the window is to be returned back to the window pool.

Interesting approach.

> Other way to implement these would be to use DMA for everything, since it
> doesn’t
> have the limitations that the windows have.


> On 07 Jul 2015, at 10:08, Alessio Igor Bogani <alessioigorbogani at gmail.com>
> wrote:
[...]
>> In fact this is a big obstacle for adoption of this VME stack (at least for
>> us). We use VME a lot and we care about latency as well so we use only
>> kernel-space drivers for ours VME boards but unfortunately the VME stack let
>> us to link a single board with a single window/image (so max 8 boards on
>> tsi148) only. That said that stack has proven to be very rock solid.
>
> Current VME stack links windows not to the boards, but to device drivers.
> Driver
> could potentially minimise window usage within it’s scope (any sort of
> window
> reusing, like mapping whole A16 once to be used with all boards), but this
> won’t
> work across multiple drivers. Even if all of your drivers are window-wise
> economic,
> they will still need some amount of windows per each driver. Not that we
> have that
> many kernel drivers...

Yes you can share a window/image between all boards of the same type
(in effect we are porting our drivers in this way) *but* it isn't the
expected way to work (see Documentation/vme_api.txt struct
vme_driver's probe() and match() functions and the GE PIO2 VME
driver).

Ciao,
Alessio


More information about the devel mailing list