> The request_firmware interface should be for the DT overlay path, and > other schemes shouldn't use it. The name should come from the DT and > no place else. For the static bindings agreed (or ACPI but that's a detail) or other dynamic discovery post boot. > 2) The bootloader starts the kernel and passes a DT that describes > the hard logic and soft logic using a scheme like I outlined. The > kernel is responsible to request_firmware the bitfile and start > the FPGA and connect the drivers. > > DT purists will rightly point out that this isn't great, but it > is a simple and pragmatic solution. > > This probably falls out automatically if #3 is implemented.. > 3) The bootloader starts the kernel with a DT that only describes the > hard logic. > > Userspace must load a DT overlay early on. Otherwise proceeds like #2. > > In both 2 and 3 the FPGA can be reprogrammed on resume by re-doing > request_firmware. 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. > And for folks that need more control, expose all the knobs explicitly > to user space: > 4) There is a /dev/ node for the fpga that allows > - ioctl to program via mmap'd file (no request_firmware) > > The ioctl has an option for the kernel to hang on to the mmap > for the repogram on resume case. > - ioctl to get status/error reporting/etc > - ioctl to load/bind a DT overlay to the FPGA instance > This provides a gap where userspace can boot and configure the > FPGA internals before binding the kernel drivers. > (end result is the same as #3 case, but no request_firmware) > - (future) ioctl to load a swappable FPGA (what Alan is talking > about) 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. > The key thing is that we have a FPGA object that can be associated > with some DT element, and the kernel can then keep track if the FPGA > is is in use or not. Exactly like you said in your reply. I think this is right. You have a set of FPGA objects initially coming from DT and system enumerations and later maybe even showing up via hotplug. You have a set of bindings which describes what to do with those that have fixed bindings. The fpga /dev entries are then a subset of the enumerated list which has not been marked as OS in use (or they return -EBUSY and can't be opened) At that point it works like pretty much everything else. > I have no problem with the in kernel stuff, and I'd have no problem if > the sysfs controls were in debugfs for testing purposes. It just > doesn't make sense to me to expose that kind of interface as a > permanent API... That's my big concern too. We need an FPGA manager in kernel clearly. We need kernel ability to program FPGA bitstreams (if only because there are both boot time and suspend/resume cases that turn into complete insanity otherwise). Alan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
