Hi Dmitry, On 7 July 2015 at 12:47, Dmitry Kalinkin <dmitry.kalinkin@xxxxxxxxx> 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@xxxxxxxxx> > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
