Did PCI/IRQ allocation change significantly after 4.2 kernel?

[greg@kroah.com (Greg KH)]

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