> -----Original Message----- > From: Arnd Bergmann [mailto:a...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
