On Wed, 14 Jan 2015 11:12:58 -0700 Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. Agreed entirely. > 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. Or some other resource, it could be described by PCI but something is going to need to describe it when we get to that state and something will need to set up the IOMMU for it and potentially manage virtualising it or assigning it to things like docker instances. > 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. yes - there is a model for this in Linux already. Some of the audio subsystems have "firmware" files distributed which are actually a structured file that userspace parses to get a real set of firmware for the controller and a set of descriptions for things like mixer controls. They have the same basic problem - when you change firmware your control interfaces may change so you need both descriptions together. Alan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
