On Wed, Mar 30, 2016 at 11:51:50AM -0400, Rob Groner wrote:
On Tue, 2016-03-29 at 17:57 -0700, Greg KH wrote:
On Tue, Mar 29, 2016 at 04:11:22PM -0400, Rob Groner wrote:
Your first glance is probably correct. The driver handles reads and writes to registers via IOCTLs from the user library, as well as interrupts and DMA. There are probably two main reasons the driver is structured like that: 1) All "new" drivers here are essentially tailored versions of previous drivers that have been around for a while, so this wasn't built-from-scratch new. While it means that any poor design decisions made early on are perpetuated, it also means to us that we aren't re-inventing the wheel and we're mostly using a driver that has proven to work for quite a while. 2) The library code for the board is shared (internally) with our Windows driver package, and in some cases DOS too. Since Windows uses IOCTLs, we can essentially share the exact same library files, and only the IOCTL call itself is OS-specific.
I know #1 is not a good reason and I'd be happy to work towards re-writing the driver in a more correct way, but probably not if it would cause us to have to split into a Linux and Windows library versions. Keeping the library common at this point has saved us a lot of development time.
I understand the need for userspace libraries to be "unified", but you might be able to get away with no kernel driver at all, just use the UIO driver for your device and then read/write the memory mapped area of your card directly from your library/application. That will have the benifit of making your Linux implementation faster as well :)
I'm looking at the UIO API for the first time, and I'm beginning to understand it, and I *do* see the benefits of it. Instead of working to get this driver accepted in the kernel, I think I am going to instead make a UIO implementation my pet project.
From what I've learned so far, I'll still need a kernel driver for the interrupt handler, just much smaller.
That is correct.
One thing I haven't been able to find out for sure, however, is if DMA is possible through a UIO implementation. Not seeing any mention of it on kernel.org isn't encouraging.
It keeps coming up in dicussion on how to do this in a "generic" way, look at the lkml archives for the details. But you can do this in a specific-way for your own device, there are 2 drivers in the tree that handle this in some manner, try looking at those for inspiration. thanks, greg k-h