Dan, Aaron, On 3 May 2016 at 15:18, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > On Tue, May 03, 2016 at 02:52:54PM +0200, Alessio Igor Bogani wrote: [...] >> It would be great since we have a lot of VME drivers (for devices not >> for bridges) which we would like see mainlined. >> Unfortunately, considering the limitations of the current VME stack >> implementation, submit these is almost useless. > > What do we need to do to make it better? We tend to put a single VME master (with Linux) into the 21 slots (which it is maximum for the standard) VME crate and fill remaining 20 slots with VME slave boards (serial ports, DAQ cards and so on). Every VME master can allocate 7/8 (memory) windows to communicate with VME slaves but, using current VME API, we can't control more than 7/8 boards at the same time unless we use VME_USER (aka VME in user-space). Unfortunately: 1) We fear that VME_USER could add unbound latencies (sorry I don't have any number) 2) VME_USER isn't usable if VME slave boards implements "release on register access" interrupt style 3) Inside an allocated memory windows there are also registers which we don't like have exposed to user-space In very briefly current VME stack don't handle (limited) resources in any way but let drivers use it. I would like to try to convert the static resource management approach to a dynamic one but I don't found the time yet. Ciao, Alessio _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
