From mboxrd@z Thu Jan 1 00:00:00 1970 From: atull Subject: Re: [PATCH v2 2/3] fpga manager: framework core Date: Tue, 9 Dec 2014 10:07:42 -0600 Message-ID: References: <1414007405-32186-1-git-send-email-atull@opensource.altera.com> <1414007405-32186-3-git-send-email-atull@opensource.altera.com> <20141024105200.GA20775@amd> <20141208225519.64501d2d@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: <20141208225519.64501d2d@lxorguk.ukuu.org.uk> Sender: linux-doc-owner@vger.kernel.org To: One Thousand Gnomes Cc: Grant Likely , Pavel Machek , Greg Kroah-Hartman , Jason Gunthorpe , "H. Peter Anvin" , Michal Simek , Michal Simek , Randy Dunlap , Linux Kernel Mailing List , "devicetree@vger.kernel.org" , Pantelis Antoniou , Rob Herring , Ira Snyder , "linux-doc@vger.kernel.org" , Mark Brown , philip@balister.org, rubini , Steffen Trumtrar , Jason , kyle.teske@ni.com, Nicolas Pitre , "Balbi, Felipe" , Mauro List-Id: devicetree@vger.kernel.org On Mon, 8 Dec 2014, One Thousand Gnomes wrote: > On Sat, 6 Dec 2014 13:00:17 +0000 > Grant Likely wrote: > > > On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek wrote: > > > Hi! > > > > > >> * /sys/class/fpga_manager//firmware > > >> Name of FPGA image file to load using firmware class. > > >> $ echo image.rbf > /sys/class/fpga_manager//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