On 06/07/15 14:50, Dmitry Kalinkin wrote:
On Mon, Jul 6, 2015 at 4:22 PM, Martyn Welch <martyn.welch@xxxxxx> wrote:
Sorry about the *really* late reply, loads of emails some how missed my
periodic search of the mailing list.
I'm happy with the addition of DMA, just not sure whether it's worth adding
an extra device file just to handle DMA. Could the user space application
not just use the control device?
That would require an additional ioctl field for DMA channel id in case we want
to support both DMA channels on tsi148.
Or just dynamically allocate and free a resource for the DMA operation?
It would make sense to save that device minor if Documentation/devices.txt
was good.
But it has only 4 slave and 4 master windows whereas we would want to
make some parameters for vme_user to configure this allocation numbers up
to 8 slaves and 8 masters.
The vme_user module was originally envisaged as a mechanism to provide
support for applications that had been written to use the original
driver at vmelinux.org. 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), 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?
--
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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
