Re: [PATCH v2 2/3] fpga manager: framework core

[atull]

On Tue, 9 Dec 2014, One Thousand Gnomes wrote:

Hi Alan,

> > I agree with the view that a FPGA is something that can get reprogrammed a lot.
> > That's a flexibility we want to use.  I don't see a problem with using firmware
> > to do the programming as long as we have a lightweight interface where we can
> > load an image, use it, then later reset the FGPA and load a different image
> > instead.
> > 
> > This assumes that the system will have a pile of FPGA images sitting on
> > the filesystem for us to switch between.
> > 
> > My intent is to also support loading using device tree overlays.  This is a lot
> > more linux-like and less of something just bolted on.  The flow here is:
> > 
> > * load a DT overlay
> 
> Don't assume DT. The entire world doesn't run DT

There's all kinds of things I'm not assuming here.  But at the same time I want
this to be widely useful and to not set general policies for proper FPGA use.

This patchset provides a sysfs interface for doing fpga image programming.
So I'm not assuming DT always.  Also I am exporting some functions that can be
used to expose some other interface if you want.  Those functions can load the
FPGA given either a buffer or a chunk of a buffer or a name of a FPGA file.
So I'm looking to enable broad use while still having a framework that is
quite lightweight.

We aren't *required* ignore DT either, are we?  Exciting things are happening
with DT, now that it is starting to not be a static thing.

> 
> > * this causes the fpga to get programmed
> > * appropriate bridges get enabled
> > * appropriate drivers get probed
> 
> For the case of a fixed function device it's sort of equivalent to a
> firmware load (in fact it *is* just a firmware load). The fixed function
> cases don't actually even need a 'firmware manager' or an FPGA class. In
> fact they shouldn't IMHO have one because the fact version A of the
> device requires firmware bitstream X, and bitstream X is an altera FPGA
> bitstream is an implementation detail. Revision B could be a
> microcontroller or something else and you still just shove a bitstream
> down it. No FPGA class is needed or appropriate. FPGA loader helpers yes.

There are lots of FPGA use cases.  Yes, a production use case could involve
the FPGA being loaded by the boot loader or from EEPROM.  These patches
have nothing to do with that.

I'm not trying to set policy as to what the valid use cases for FPGA are.
I'm just providing a way to load FPGA images without rebooting Linux.

One case where that is helpful is when you are developing your FPGA
image and want to keep reloading it.

> 
> In the enterprise space the model for FPGA use is usually a lot more
> flexible, big racks of FPGA boards that are handed out as resources to
> processes. They may be uploading fixed bitstreams but they may also be
> splicing bitstreams (eg splicing in 'ROM' images) and in the future as
> the Chinese break the existing FPGA market up I imagine we'll even see
> open bitstream formats.

I have no problem with any of that.  For me, the 'firmware' interface is
a convenient way of getting an image.  We can reprogram as much as we
want with as many 'firmware' images we like.

Also note that this framework does not assume anything about the contents
of the 'firmware' images.  It does not try to parse those images.  It
just loads them.

> 
> In the smaller system world emulators, real time and all sorts of maker
> type projects use the FPGA boards as a dynamic resource already. It might
> be running GNU radio, then driving a 3D printer, then doing processor
> emulation for a games console. The FPGAs hanging off my desktop box have
> been all sorts of things from video processors to emulated systems and
> even block drivers for weird recalcitrant hardware. Next stop may well be
> Localtalk 8)
> 
> In the academic world the model is similar, they are being treated as OS
> resources by the various reconfigurable OS projects, most of which are
> themselves Linux patch sets.
> 
> IMHO we have two use cases
> 

There are a lot more than two use cases.  If you follow the history of
the FGPA manager on the mailing list, a lot of people who like one
use case have no use for any of the other use cases.

I want to provide something that is handles the low level stuff of
reconfiguring a FPGA.  

> 1. Fixed function firmware - in which case the driver already handles it
> and we don't care if its FPGA bitstreams or microcode or CPU code or
> whatever

If your FPGA is already configured before Linux boots, these patches aren't
needed for that use.  

But even in that case, it can be handy for reloading images during development.

> 
> 2. Dynamic use cases where we need a resource we own, which means
> enumerate/open/close/read/write interfaces including firmware.
> 

In the case of a framework that will (1) reconfigure the fpga and then turn
around and (2) expose what the fpga is providing as a resource, 
you will need a way of dynamically loading the image into the FPGA.  That's
what this provides.

> For use case #1 I don't believe we need magic classes for FPGA and in

Magic?  Nope, it's a device driver.  What I have here on my desk is a soc
with a FPGA bolted onto an ARM. There is a device in there that is called
the "fpga manager".  This device's function is to configure the FPGA.  So
I created a FPGA class to put the driver that controls this 'fpga manager'
device.  This is a framework because I want to expose a useful interfaces
that other manufacturors could use, promote common code and common
interfaces.

> fact they are actually a mistake, for use class #2 request_firmware()
> doesn't work because it's intentionally quite blind to things like
> namespaces and permissions models. Both benefit greatly from library
> functions to handle the more standardised uploaded mechanisms.
> 
> I agree entirely with Michael about putting it in staging and working
> from there.
> 

Please look at my v4 patches which move this to drivers/staging.  Also  I
have dropped the DT stuff for now since not all of what it depends on is
in the main tree yet.

Alan Tull

> Alan
> 

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