Message-ID: <50BA5AEF.3010109@balister.org>
Date:	Sat, 01 Dec 2012 11:30:55 -0800
From:	Philip Balister <philip@...ister.org>
To:	Greg KH <gregkh@...uxfoundation.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 12/01/2012 08:56 AM, Greg KH wrote:
> 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?

Nothing. The Xillybus approach is valid. It just depends on their piece 
of fpga code. If you are not willing to license that, you will need to 
reverse engineer their fpga code, or sues a different (equally valid) 
method to communicate with the fpga. Think of their fpga blob as a 
specific implementation of a network card.  Not all network cards expose 
the same hardware interface.

The important thing to realize is that the fpga is user configurable. It 
is possible to create an infinite number of possible "devices" in it 
that can use any number of device drivers in Linux.

Think of it a a soc, with a large part that the end user can customize 
with his own IP. In the Xilly case, they have created a custom piece of 
hardware in the fpga that needs a driver with a specific interface to 
users space.

>
>> 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.
>

It is very close to a UIO approach. My key problem I am trying to solve 
is getting a "large" buffer space for the driver and a way to 
communicate the physical address and size of the buffer to the fpga. The 
fpga has several ports that allow it to directly read/write RAM, but it 
needs to know physical addresses.

>> 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?
>

For zynq, there is an out of tree ( :) ) driver that handles the 
firmware loading. This is an independent problem.

> 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 :)
>

I do not think there will be any one driver that will work for all use 
cases due to the variety of devices that can be implemented in the fpga.

Philip


> 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