On Mon, 8 Dec 2014, One Thousand Gnomes wrote: > On Sat, 6 Dec 2014 13:00:17 +0000 > Grant Likely <grant.likely@xxxxxxxxxx> wrote: > > > On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek <pavel@xxxxxxx> wrote: > > > Hi! > > > > > >> * /sys/class/fpga_manager/<fpga>/firmware > > >> Name of FPGA image file to load using firmware class. > > >> $ echo image.rbf > /sys/class/fpga_manager/<fpga>/firmware > > > > > > I .. still don't think this is good idea. What about namespaces? > > > The path corresponds to path in which namespace? > > > > I don't understand your concern here. This allows userspace to name > > the FPGA bitstream that the kernel will use during request_firmware(), > > and it will show up as the $FIRMWARE value in the uevent file, but it > > is still the responsibility of userspace to choose what to load, and > > it can freely ignore the setting of $FIRMWARE if it needs to. > > I think the entire model here is basically pedicated on a bogus > assumption that an FPGA is a one shot device. It's not. It's a fast > reloadable reusable device. A lot of work being done with FPGAs in > operating systems already involves basically task switching and > scheduling FPGAs as a shared resource pool. Trying to nail something > together with request_firmware is several years behind the curve. > > From userspace it needs to be a open, load, use, close type model, not a > static or semi-static pile of mappings. > > Alan > Hi Alan, I agree with the view that a FPGA is something that can get reprogrammed a lot. That's a flexibility we want to use. I don't see a problem with using firmware to do the programming as long as we have a lightweight interface where we can load an image, use it, then later reset the FGPA and load a different image instead. This assumes that the system will have a pile of FPGA images sitting on the filesystem for us to switch between. My intent is to also support loading using device tree overlays. This is a lot more linux-like and less of something just bolted on. The flow here is: * load a DT overlay * this causes the fpga to get programmed * appropriate bridges get enabled * appropriate drivers get probed When the DT overlay is removed, all these get undone in the reverse order. Alan Tull -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
