Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 28 November 2012, Eli Billauer wrote:
> 
> Xillybus is a general-purpose framework for communication between programmable
> logic (FPGA) and a host. It provides a simple connection between hardware FIFOs
> in the FPGA and their respective device files on the host. The user space
> programming model is like piping data from or to the FPGA.
> 
> The underlying transport between the host and FPGA is either PCIe or AXI
> (AMBA bus by ARM).
> 
> The Xillybus logic (IP core) is configurable in the number of pipes it presents
> and their nature. The driver autodetects these pipes, making it essentially
> forward-compatible to future configurations. The benefit of having this driver
> enabled in the kernel is that hardware vendors may release a new card, knowing
> that it will work out of the box on any future Linux machine, with the specific
> configuration defined for the FPGA part.
> 
> This driver has been available for download for over a year, and has been
> actively used on a wide variety of kernels versions and configurations.

I have a much higher-level comment on this driver: There seem to be a number
of parties that are interested in having reprogrammable logic available in
Linux and that will want to merge their drivers. I'm aware of these other
people that must have some interest (and one person I can't mention here
because of NDA):

Philip Balister  <philip@balister.org> (OpenSDR)
Dinh Nguyen <dinguyen@altera.com> (ARM SOCFPGA maintainer)
Pavel Machek <pavel@denx.de> (SOCFPGA contributor)
John Linn <john.linn@xilinx.com> (Zynq maintainer)
Michal Simek <michal.simek@xilinx.com> (Zynq maintainer)
Ira W. Snyder <iws@ovro.caltech.edu> (Carma driver author)

I believe it is in everybody's interest to define a single kernel-to-user
interface that can be used to install a payload in an any of the FPGA
implementations, and a common way to probe logical devices that are
implemented in that FPGA.

Your driver seems like an good start for such an interface, and I
think it would be reasonable to put it into a new drivers/fpga/
subsystems rather than a "misc" driver, but that requires at least
the user level interface to be generic enough to cover all the use
cases. Ideally, the in-kernel interface would also be generic to allow
plugging in additional hardware drivers and allowing to add independent
back-ends for functionality based on the model that gets loaded into
the FPGA. However, we don't have to do it right away, as we can always
change in-kernel interfaces when needed, unlike the user interfaces
that have to remain stable.

	Arnd