Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Jason Gunthorpe <jgunthorpe@obsidianresearch.com>]

On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:

> + Jason Gunthorpe

Thanks, looks interesting, we could possibly use this interface if it 
met our needs..
 
> On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> > This new subsystem should unify all fpga drivers which
> > do the same things. Load configuration data to fpga
> > or another programmable logic through common interface.
> > It doesn't matter if it is MMIO device, gpio bitbanging,
> > etc. connection. The point is to have the same
> > inteface for these drivers.

So, we have many years of in-field experience with this and this API
doesn't really match what we do.

Here are the steps we perform, from userspace:
 - Ask kernel to place FPGA into reset and prepare for programming
   * Kernel can return an error (eg FPGA failed to erase, etc)
   * this is the PROG_N low -> DONE high, PROG_N high -> INIT_N high
     sequencing on Xilinx chips
 - Ask kernel to load a bitstream.
   * Userspace locats the bitstream file to load, and the mmaps it.
   * Userspace passes the entire file in a single write() call to the
     kernel which streams it over the configuration bus
   * The kernel can report an erro rhere (eg Xilinx can report CRC
   error)
 - Ask the kernel to verify that configuration is complete. 
   * On Xilinx this wait for done to go high
 - Ask the kernel to release the configuration bus (tristate
   all drivers) (or sometimes we have to drive the bus low,
   it depends on the bitfile, user space knows what to do)

It is very important that userspace know exactly which step fails
because the resolution is different. We use this in a manufacturing
setting, so failures are expected and need quick root cause
determination.

You could probably address that need by very clearly defining a
variety of errno values for the various cases. However, it would be a
disaster if every driver did something a little different :|

Using request_firmware exclusively is not useful for us. We
format the bitfile with a header that contains our internal tracking
information. Sometimes we need to bitswap the bitfile. Our userspace
handles all of this and can pass a bitfile in memory to write().

request_firmware would be horrible to use :)

Our API uses a binary sysfs attribute to stream the FPGA data, you
might want to consider that.

Regards,
Jason