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

From: Alessio Igor Bogani
Date: Tue Jul 07 2015 - 03:13:49 EST


Hi Dmitry,

On 6 July 2015 at 19:24, Dmitry Kalinkin <dmitry.kalinkin@xxxxxxxxx> wrote:
[...]
>
> 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.

In my humble opinion using user-space drivers (as workaround for
limited windows/images) introduce more latency than let VME driver
dynamically configure windows/images. After all VME systems usually
aren't so much dynamic by its nature (Who likes continuously put in
and out a board which requires an insertion force between 20 and 50
kg?) and are instead heavily used in critical contexts often in
non-stop way.

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.

Until now we have used a modified version of the old vmelinux.org
stack for sharing windows/images between all (ours) VME kernel drivers
and we would be very happy to see something similar in vanilla (at
least coalescence two adjacent addresses with same modifiers).

> Those who need such API are welcome to develop it :)

I would be glad to try it if the maintainer is willing to receive this
type of changes.

Ciao,
Alessio
--
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/