Message-ID: <20121201165612.GG3113@kroah.com>
Date:	Sat, 1 Dec 2012 08:56:12 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Philip Balister <philip@...ister.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Eli Billauer <eli.billauer@...il.com>,
	linux-kernel@...r.kernel.org, Pavel Machek <pavel@...x.de>,
	John Linn <john.linn@...inx.com>,
	Michal Simek <michal.simek@...inx.com>,
	"Ira W. Snyder" <iws@...o.caltech.edu>,
	Josh Cartwright <josh.cartwright@...com>
Subject: Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA
 (programmable logic)

On Fri, Nov 30, 2012 at 07:19:16PM -0800, Philip Balister wrote:
> On 11/30/2012 09:36 AM, Greg KH wrote:
> >On Fri, Nov 30, 2012 at 05:28:47PM +0000, Arnd Bergmann wrote:
> >>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@...ister.org> (OpenSDR)
> >>Dinh Nguyen <dinguyen@...era.com> (ARM SOCFPGA maintainer)
> >>Pavel Machek <pavel@...x.de> (SOCFPGA contributor)
> >>John Linn <john.linn@...inx.com> (Zynq maintainer)
> >>Michal Simek <michal.simek@...inx.com> (Zynq maintainer)
> >>Ira W. Snyder <iws@...o.caltech.edu> (Carma driver author)
> >
> >Yes, I know of at least one more device other than the ones listed above
> >that wants this type of functionality as well, so defining it in a
> >standard user/kernel api manner would be very good to do.
> 
> I'm concerned that a standard driver for FPGA's will be a very
> difficult problem.
> 
> The Xillybus driver looks interesting on several levels, however my
> first concern is depends on a FPGA IP block that is not open source.
> This is not a bad thing, just a potential obstacle for some people.

As long as that doesn't affect the kernel code, I don't see the obstacle
here.  What am I missing?

> I've been engaged in design discussions today with my customer. Our
> target is the Xilinx Zynq hardware. The first pass at a driver
> focuses on creating the minimal amount of code in the kernel doing
> most of the logic in user space. So the driver code allocates a
> large chunk of RAM for the FPGA to read/write to, provides a mmap
> function so user space can see this RAM, also mmaps in the address
> space of an AXI slave so the user space can control the logic. This
> approach has no dependencies on what is loaded into the fpga.

Would a simple UIO driver work best for this type of arrangement?  Then
those types of hardware wouldn't even need to mess with a fpga-type
interface.

> This is a very different approach then the Xillybus driver, but
> should also be useful to a large class of people. Hopefully, we can
> converge on a set of useful drivers, and not end up with a million
> drivers all based on custom fpga configuration :)

Odds are, this should look something like the firmware interface in the
end, right?  Userspace dumps a bunch of data to the device, and then
needs the driver to toggle some bits somewhere to enable the device.
Also, a few control calls like clearing the device, and other minor
things should be all that is needed, right?

So, in the grand tradition of, "The first one there wins", why not base
it all off of your driver, and how that works, and we can go from there :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists