FPGA manager user space interface
Florian Fainelli
f.fainelli at gmail.com
Mon Jul 11 10:38:37 PDT 2016
Hi Alan,
On 07/11/2016 09:59 AM, atull wrote:
> On Sun, 10 Jul 2016, Florian Fainelli wrote:
>
> Hi Florian,
>
> I'm in the process of upstreaming FPGA Regions support which
> allows reprogramming by applying Device Tree Overlays. If you
> want to see a tree which has the latest patches for that, I have
> all that in our github tree.
>
> https://github.com/altera-opensource/linux-socfpga/tree/socfpga-4.6
>
> The documentation for the DT overlays is in
> Documentation/devicetree/bindings/fpga/fpga-region.txt
>
> Documentation for the DT configfs interface is in
> Documentation/devicetree/configfs-overlays.txt
>
> The idea here is explained at legnth in the doc, but basically
> the user can use the configfs interface to apply a DT
> overlay that causes the FPGA to be reprogrammed and child
> devices to get added and probed.
>
> I like DT overlays a lot, but I do not expect that (or anything
> else) will be a good interface for every use case. The FPGA
> Manager Framework went through a legnthy discussion on the
> mailing list where several people wanted the interface to match
> what they were already using. Interfaces similar to what you
> suggest below were proposed and shot down. My conclusion from
> all that was to implement the kernel API functions such that
> people could add whatever interfaces they needed for their use
> case.
While I agree that the current state of the FPGA manager is completely
sane, and people making products including a FPGA will want something
(kernel driver or user-space scripts) that load a given set of bistreams
(under version control), it still feels like there is a small bit of
debugging and or use cases where it is desireable to have a way, from
user-space to load an arbitrary FPGA bitstream which is not set in stone
from e.g: a Linux kernel driver. More than being able to change
something on the filesystem, it's about being able to reload the
bitstream from user-space that seems to be critically missing imho.
Do you have links to the original discussion so I could get an idea of
what were the different points back then?
Thanks!
>
>
>> Hi all,
>>
>> I just wrote a FPGA manager driver for the TS-7300 board which features
>> an Altera Cyclone II on board. While the finished solution is my case
>> might be something like the MFD driver for the FPGA devices requesting
>> the bitstream load and registering the different devices it exposes,
>> during development it is nice to exercise the FPGA manager driver to
>> load something:
>
> It sounds like your goal is to use the FPGA Manager API inside
> the kernel, but it would be helpful to have an easy userspace
> interface during development. Is that right?
>
>>
>> - a quick way is to add a pair of sysfs attributes to define the
>> bitstream filename and to trigger the load
>>
>> - offer a more consistent and robust interface through e.g; a character
>> device that you can write/read/poll to see the loading progress about
>
> Sysfs and char driver interfaces have been proposed and shot down
> a few times already.
>
> The first version of the FPGA Manager Framework was a char
> driver. To program the FPGA, the user had to do 'cat
> bitstream-file > /dev/fpga0'. Bridge support was a separate
> thing that was also controlled by sysfs. It was messy and if
> userspace could easily do the wrong thing and crash the system.
>
>>
>> - have the driver exposing FPGA peripherals be exposing an user space
>> interface to trigger a (re)load/(re)/configuration, although that's
>> really something that belongs in the FPGA manager it seems
>
> If you use the device tree configfs interface, you can do that.
> It might not be exactly what you are thinking of. And there is
> a learning curve in getting the overlays right.
>
>>
>> I am mostly curious if these were taken into account during the initial
>> design and it is agreed upon that yes these are some of options and that
>> userspace loading is just anecdotal we do not need any userspace
>> interface, or if this is just missing and we want one?
>
> There will be use cases that will need various userspace interfaces.
> It's been hard to get people who are already using FPGAs to agree
> on using any one interface because they would have to change the
> code they already have running.
>
>> Either way, I
>> don't mind submitting what I came up with for the TS-7300 board.
>
> Yes, that would be great.
>
>>
>> Thanks!
>> --
>> Florian
>>
--
Florian
More information about the linux-arm-kernel
mailing list