lkml.org 
[lkml]   [2012]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
Date
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Saturday, December 01, 2012 12:49 PM
> To: Philip Balister
> Cc: Greg KH; Eli Billauer; linux-kernel@vger.kernel.org; Pavel Machek; John Linn; Michal Simek; Ira W.
> Snyder; Josh Cartwright
> Subject: Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
>
> On Saturday 01 December 2012, Philip Balister wrote:
> > On 11/30/2012 09:36 AM, Greg KH wrote:
> > > 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.
>
> I agree that is a concern, but for now, I'm mostly worried about
> the kernel-to-user interface. If we can agree on a driver interface
> that works for Xillybus as well as any of the others we know about,
> we can start using that as the generic kernel FPGA interface.
>
> Once we get a second FPGA driver, that can use the same user
> interface but talk to the hardware in a different way, and then
> we can reorganise the code to keep the user interface bits in a
> common driver, away from the hardware specific parts.
>
> If you see anything in the user interface that directly depends on
> the Xillybus IP block, then that would make the approach impossible
> and we should change that to be more generic.
>
> > 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.
> >
> > 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 :)
>
> Agreed. If I understand you correctly though, your approach is specific
> to a particular hardware implementation (Zynq) on the user interface layer,
> which I think is exactly what we should avoid. Obviously, there is
> always a driver involved that is specific to the IP block you load into
> an FPGA at runtime, and that is ok. The two parts that I think we
> should agree on are:
>
> a) How to get a payload into the FPGA
>
> b) How to find a device driver that can make the payload interface to user
> space.

Yes I agree with these 2 parts and keeping them separated.

Josh's comments were aligned with where we want to go also with the device tree
and Grant's work.

Thanks
John

>
> Arnd




\
 
 \ /
  Last update: 2012-12-03 22:01    [W:0.108 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site