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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-arm-kernel