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

[Arnd Bergmann]

On Tuesday 04 December 2012, Philip Balister wrote:
> On 12/01/2012 12:48 PM, Arnd Bergmann wrote:
> > 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.
> 
> Actually, the user interface will depend on what "code" is loaded into 
> the FPGA (side note, people argue over FPGA's being hardware or 
> software). So it is entirely possible to load an FPGA with a XillyBus 
> device, and ethernet interface, I2S, and the "UIO" appraoch I am working on.

Yes, absolutely. Or multiple instances each of them even. Or constantly
reload the FPGA depending on the application running in user space.

> We can use device tree to tell the kernel what drivers are needed, and 
> Josh mentioned some ideas on managing device tree entries combined with 
> the fpga image.
> 
> So it is very possible for one fpga to have several device drivers, each 
> using different user interfaces. It is entirely possible to create a 
> device in the fpga that uses an existing hardware interface so you could 
> use the existing Linux driver to control it.

One implication of using the device tree though is that it's statically
configured, and you can't just load something else into it if you
want to run something else. This is certainly fine in many cases,
but I think we also need to consider the case where it is not know
at boot time which image will get loaded into the FPGA.

Note that you can actually put the byte stream for the FPGA image
into a device tree property so you don't have to load it from
disk, which may not be easy for technical (e.g. the FPGA 
implementing you storage interface) or legal (e.g. the patents
preventing you from shipping the image with a standard Linux
distro) reasons.
 
> Just to be clear, what are you calling payload here? Is it the data that 
> is used to configure the fpga, or actual data going back and forth? I'm 
> a little concerned that not everyone understand how flexible the FPGA is.

I mean the configuration byte stream.

	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/