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

[John Linn]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@xxxxxxxx]
> Sent: Saturday, December 01, 2012 12:49 PM
> To: Philip Balister
> Cc: Greg KH; Eli Billauer; linux-kernel@xxxxxxxxxxxxxxx; 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


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