Re: [PATCH 00/16] Intel FPGA Device Drivers

[Alan Cox]

> Well Intel inclusion of FPGA triggered my curiosity and when that patchset
> came accross my inbox i did wonder where the open source userspace was and
> went looking for it to no avail. So this isn't against a specific patchset
> but more broadly against the whole drivers/fpga/ story. Sorry if this was
> not clear.
> 
> 
> > It sounds like you are opposed to any kernel support of loading images
> > on FPGAs until all vendors have opensource toolchains.  
> 
> Yes that is what i am saying. They are different standard in the kernel
> and i would rather have one clear standard about driver needing proper
> open source userspace to go along with any upstream driver.

So Red Hat will stop shipping any hardware with loadable firmware ?

No I thought not 8)

I think you need to be much clearer what you are talking about. The GPU's
load closed firmware. The sound cards load closed firmware. The pieces we
demand are open (with the exception of the rather strange position
Debian takes) are the actual pieces you need to use the device on the
Linux side - so the 3D libraries, 2D acceleration libraries, wifi
interfaces, audio playback and so on.

The FPGA bitstreams are and always have been counted as firmware (nothing
here is new except that existing systems load FPGA firmware via
devicetree at boot rather than dynamically). That's true of the Xilinx
drivers, the many FPGA drivers for existing ARM and other processor
platforms containing FPGA today that are in kernel.

The second part of the equation is the tools for selecting a bitstream,
and for running whatever accelerator you loaded. Generally that's just a
device that mmap's the accelerator into whatever application wishes to
bash on it. The bits you need to load a bitstream do need to be open, and
the device driver that does the mmio mappingand there will no doubt over
time be other drivers where you do want to kernel mediate your FPGA
functions.

Some bitstreams will need their own drivers, others may want to use
existing drivers. Crypto for example if loaded on an FPGA you'd probably
want to go via the kernel crypto hooks and FPGA hardware for some
applications might want to expose gpios, serial ports, virtio etc. For
debug or if I've got a CPU on my bitstream I might even want to expose a
standard 16x50 UART to the serial drivers.

Generally though most bitstreams are pretty latency sensitive, often used
for real time work, and just provide a set of registers to any
application wanting to use that service.

(Consider for example a Z80 processor emulator on the FPGA - do you
really want to define kvm hooks for Z80 virtualization, or 6502, or all
the rest us retro folks are going to enable ???

Alan