From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: atull <atull@opensource.altera.com>, Pavel Machek <pavel@denx.de>, gregkh@linuxfoundation.org, hpa@zytor.com, monstr@monstr.eu, michal.simek@xilinx.com, rdunlap@infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, pantelis.antoniou@konsulko.com, robh+dt@kernel.org, grant.likely@linaro.org, iws@ovro.caltech.edu, linux-doc@vger.kernel.org, broonie@kernel.org, philip@balister.org, rubini@gnudd.com, s.trumtrar@pengutronix.de, jason@lakedaemon.net, kyle.teske@ni.com, nico@linaro.org, balbi@ti.com, m.chehab@samsung.com, davidb@codeaurora.org, rob@landley.net, davem@davemloft.net, cesarb@cesarb.net, sameo@linux.intel.com, akpm@linux-foundation.org, linus.walleij@linaro.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, devel@driverdev.osuosl.org, delicious.quinoa@gmail.com, dinguyen@opensource.altera.com, yvanderv@opensource.altera.com Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document Date: Wed, 14 Jan 2015 16:06:17 +0000 [thread overview] Message-ID: <20150114160617.02fb9135@lxorguk.ukuu.org.uk> (raw) In-Reply-To: <20150113222450.GA17475@obsidianresearch.com> > 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
WARNING: multiple messages have this Message-ID (diff)
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: mark.rutland@arm.com, linux-doc@vger.kernel.org, rubini@gnudd.com, pantelis.antoniou@konsulko.com, hpa@zytor.com, s.trumtrar@pengutronix.de, devel@driverdev.osuosl.org, sameo@linux.intel.com, nico@linaro.org, ijc+devicetree@hellion.org.uk, michal.simek@xilinx.com, kyle.teske@ni.com, grant.likely@linaro.org, davidb@codeaurora.org, linus.walleij@linaro.org, cesarb@cesarb.net, devicetree@vger.kernel.org, jason@lakedaemon.net, pawel.moll@arm.com, iws@ovro.caltech.edu, atull <atull@opensource.altera.com>, galak@codeaurora.org, broonie@kernel.org, philip@balister.org, dinguyen@opensource.altera.com, monstr@monstr.eu, gregkh@linuxfoundation.org, yvanderv@opensource.altera.com, linux-kernel@vger.kernel.org, balbi@ti.com, delicious.quinoa@gmail.com, robh+dt@kernel.org, rob@landley.net, Pavel Machek <pavel@denx.de>, akpm@linux-foundation.org, davem@davemloft.net, m.chehab@samsung.c Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document Date: Wed, 14 Jan 2015 16:06:17 +0000 [thread overview] Message-ID: <20150114160617.02fb9135@lxorguk.ukuu.org.uk> (raw) In-Reply-To: <20150113222450.GA17475@obsidianresearch.com> > 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
next prev parent reply other threads:[~2015-01-14 16:08 UTC|newest] Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-06 20:13 [PATCH v8 0/4] FPGA Manager Framework atull 2015-01-06 20:13 ` atull 2015-01-06 20:13 ` [PATCH v8 1/4] doc: add bindings document for altera fpga manager atull 2015-01-06 20:13 ` atull 2015-01-06 22:05 ` Rob Herring 2015-01-06 22:05 ` Rob Herring 2015-01-06 22:34 ` atull 2015-01-06 22:34 ` atull 2015-01-09 15:50 ` Rob Herring 2015-01-09 15:50 ` Rob Herring 2015-01-09 18:58 ` atull 2015-01-09 18:58 ` atull 2015-01-06 20:13 ` [PATCH v8 2/4] fpga manager: add sysfs interface document atull 2015-01-06 20:13 ` atull 2015-01-07 8:48 ` Pavel Machek 2015-01-07 8:48 ` Pavel Machek 2015-01-09 19:14 ` atull 2015-01-09 19:14 ` atull 2015-01-09 20:56 ` Pavel Machek 2015-01-09 20:56 ` Pavel Machek 2015-01-10 8:10 ` Pantelis Antoniou 2015-01-10 8:10 ` Pantelis Antoniou 2015-01-10 15:11 ` Pavel Machek 2015-01-10 15:11 ` Pavel Machek 2015-01-11 16:29 ` atull 2015-01-11 16:29 ` atull 2015-01-12 8:45 ` Pavel Machek 2015-01-12 8:45 ` Pavel Machek 2015-01-12 13:48 ` Michal Simek 2015-01-12 13:48 ` Michal Simek 2015-01-13 7:28 ` Pavel Machek 2015-01-13 7:28 ` Pavel Machek 2015-01-13 7:40 ` Pantelis Antoniou 2015-01-13 7:40 ` Pantelis Antoniou 2015-01-13 7:56 ` Pavel Machek 2015-01-13 7:56 ` Pavel Machek 2015-01-13 17:27 ` atull 2015-01-13 17:27 ` atull 2015-01-12 16:05 ` Rob Herring 2015-01-12 16:05 ` Rob Herring 2015-01-12 16:26 ` Mark Brown 2015-01-12 16:26 ` Mark Brown 2015-01-12 18:06 ` Jason Gunthorpe 2015-01-12 18:06 ` Jason Gunthorpe 2015-01-13 16:21 ` One Thousand Gnomes 2015-01-13 16:21 ` One Thousand Gnomes 2015-01-15 21:52 ` Pavel Machek 2015-01-15 21:52 ` Pavel Machek 2015-01-12 21:01 ` One Thousand Gnomes 2015-01-12 21:01 ` One Thousand Gnomes 2015-01-12 21:43 ` Jason Gunthorpe 2015-01-12 21:43 ` Jason Gunthorpe 2015-01-13 16:28 ` One Thousand Gnomes 2015-01-13 16:28 ` One Thousand Gnomes 2015-01-13 17:26 ` Pantelis Antoniou 2015-01-13 17:26 ` Pantelis Antoniou 2015-01-13 19:44 ` atull 2015-01-13 19:44 ` atull 2015-01-14 15:58 ` One Thousand Gnomes 2015-01-14 15:58 ` One Thousand Gnomes 2015-01-13 20:00 ` Jason Gunthorpe 2015-01-13 20:00 ` Jason Gunthorpe 2015-01-13 21:37 ` atull 2015-01-13 21:37 ` atull 2015-01-13 22:24 ` Jason Gunthorpe 2015-01-13 22:24 ` Jason Gunthorpe 2015-01-14 16:06 ` One Thousand Gnomes [this message] 2015-01-14 16:06 ` One Thousand Gnomes 2015-01-14 18:12 ` Jason Gunthorpe 2015-01-14 18:12 ` Jason Gunthorpe 2015-01-14 19:01 ` Pantelis Antoniou 2015-01-14 19:01 ` Pantelis Antoniou 2015-01-15 11:36 ` One Thousand Gnomes 2015-01-15 11:36 ` One Thousand Gnomes 2015-01-15 11:44 ` Mark Brown 2015-01-15 11:44 ` Mark Brown 2015-01-15 16:34 ` atull 2015-01-15 16:34 ` atull 2015-01-15 18:47 ` Jason Gunthorpe 2015-01-15 18:47 ` Jason Gunthorpe 2015-01-15 20:45 ` One Thousand Gnomes 2015-01-15 20:45 ` One Thousand Gnomes 2015-01-15 20:54 ` Pantelis Antoniou 2015-01-15 20:54 ` Pantelis Antoniou 2015-01-21 16:01 ` One Thousand Gnomes 2015-01-21 16:01 ` One Thousand Gnomes 2015-01-21 16:33 ` Pantelis Antoniou 2015-01-21 16:33 ` Pantelis Antoniou 2015-01-21 20:27 ` Jason Gunthorpe 2015-01-21 20:27 ` Jason Gunthorpe 2015-01-21 20:32 ` Pantelis Antoniou 2015-01-21 20:32 ` Pantelis Antoniou 2015-02-15 22:40 ` Pavel Machek 2015-02-15 22:40 ` Pavel Machek 2015-02-17 17:07 ` Rob Landley 2015-02-17 17:07 ` Rob Landley 2015-02-17 19:17 ` Pavel Machek 2015-02-17 19:17 ` Pavel Machek 2015-02-19 12:46 ` Michal Simek 2015-02-19 12:46 ` Michal Simek 2015-02-21 6:31 ` atull 2015-02-21 6:31 ` atull 2015-02-17 18:12 ` Jason Gunthorpe 2015-02-17 18:12 ` Jason Gunthorpe 2015-01-15 21:42 ` Jason Gunthorpe 2015-01-15 21:42 ` Jason Gunthorpe 2015-01-17 21:11 ` Pavel Machek 2015-01-17 21:11 ` Pavel Machek 2015-01-06 20:13 ` [PATCH v8 3/4] staging: fpga manager: framework core atull 2015-01-06 20:13 ` atull 2015-01-06 20:13 ` [PATCH v8 4/4] staging: fpga manager: add driver for socfpga fpga manager atull 2015-01-06 20:13 ` atull 2015-01-10 18:11 ` [PATCH v8 0/4] FPGA Manager Framework Konrad Zapalowicz 2015-01-10 18:11 ` Konrad Zapalowicz 2015-01-11 16:08 ` atull 2015-01-11 16:08 ` atull 2015-01-11 16:24 ` Konrad Zapalowicz 2015-01-11 16:24 ` Konrad Zapalowicz 2015-01-11 19:52 ` Pavel Machek 2015-01-11 19:52 ` Pavel Machek 2015-01-11 20:58 ` Konrad Zapalowicz 2015-01-11 20:58 ` Konrad Zapalowicz 2015-01-11 21:31 ` Pavel Machek 2015-01-11 21:31 ` Pavel Machek 2015-01-12 13:50 ` Michal Simek 2015-01-12 13:50 ` Michal Simek 2015-01-12 14:06 ` Dan Carpenter 2015-01-12 14:06 ` Dan Carpenter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150114160617.02fb9135@lxorguk.ukuu.org.uk \ --to=gnomes@lxorguk.ukuu.org.uk \ --cc=akpm@linux-foundation.org \ --cc=atull@opensource.altera.com \ --cc=balbi@ti.com \ --cc=broonie@kernel.org \ --cc=cesarb@cesarb.net \ --cc=davem@davemloft.net \ --cc=davidb@codeaurora.org \ --cc=delicious.quinoa@gmail.com \ --cc=devel@driverdev.osuosl.org \ --cc=devicetree@vger.kernel.org \ --cc=dinguyen@opensource.altera.com \ --cc=galak@codeaurora.org \ --cc=grant.likely@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=ijc+devicetree@hellion.org.uk \ --cc=iws@ovro.caltech.edu \ --cc=jason@lakedaemon.net \ --cc=jgunthorpe@obsidianresearch.com \ --cc=kyle.teske@ni.com \ --cc=linus.walleij@linaro.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=m.chehab@samsung.com \ --cc=mark.rutland@arm.com \ --cc=michal.simek@xilinx.com \ --cc=monstr@monstr.eu \ --cc=nico@linaro.org \ --cc=pantelis.antoniou@konsulko.com \ --cc=pavel@denx.de \ --cc=pawel.moll@arm.com \ --cc=philip@balister.org \ --cc=rdunlap@infradead.org \ --cc=rob@landley.net \ --cc=robh+dt@kernel.org \ --cc=rubini@gnudd.com \ --cc=s.trumtrar@pengutronix.de \ --cc=sameo@linux.intel.com \ --cc=yvanderv@opensource.altera.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.