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

[One Thousand Gnomes]

> 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

> * 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.

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.

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

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

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

For use case #1 I don't believe we need magic classes for FPGA and in
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.

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/