Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

From: Jason Gunthorpe
Date: Wed Jan 14 2015 - 13:14:12 EST


On Wed, Jan 14, 2015 at 04:06:17PM +0000, One Thousand Gnomes wrote:

> and I think you effectively have the user usage covered here for such
> things. It much like GPIO pins - we can describe them but we can also
> declare they are not visible to the user.

A missing element in mainline is a kind of VFIO scheme to let user
space access the FPGA registers designated for user space use.

We have been using these patches since 2.6.16 to allow user space to
access the FPGA register resources via a PCI like /sys/../resource0
mmapable:

https://github.com/jgunthorpe/linux/commit/59d5d13ddeffa8980ccc6248ebb5f1678ccb23f4
https://github.com/jgunthorpe/linux/commit/7c29c4344627be8a3906d64d32db533bc131df86
https://github.com/jgunthorpe/linux/commit/e41bb4a197368a9d505d66b627aee82f2d2b8895

We deliberately split up the FPGA registers and the assign user space
permissions to the resource0 files in a way that makes sense for our
app. Typically there are 10-20 FPGA register regions. User space does
not access register regions that control DMA.

> The swappable case mostly comes out of the /dev node. Once you have the
> dev node it becomes a detail of the OS not the FPGA driver as to who may
> open it, and how it is handed about. It might be an FPU manager daemon it
> might not.

Right, but the thing that scares me about the swappable case is the
kernel side support.. The FPGA has to connect to the CPU in some way,
it must have some address assigned, etc. Swapping needs to take care
of all those details in some way.

A fixed bus interface block and dynamic reconfiguration for the
remainder is probably the way to manage that. But, that implies that
even a family of swappable FPGAs will have a DT overlay associated
with it.

Ideally, I could see wanting to have a file format that combines the
overlay and FPGA bitfile. A loader tool would use the /dev/ interface
to setup both elements. That would be much more robust than the
current scheme I see (eg Xilinx) using where the bitfile and DT bit
live in completely different places and have to be perfectly matched.

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