From: Pantelis Antoniou <pantelis.antoniou@konsulko.com> To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, atull <atull@opensource.altera.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Pavel Machek <pavel@denx.de>, hpa@zytor.com, Michal Simek <monstr@monstr.eu>, Michal Simek <michal.simek@xilinx.com>, Randy Dunlap <rdunlap@infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, devicetree@vger.kernel.org, robh+dt@kernel.org, Grant Likely <grant.likely@linaro.org>, iws@ovro.caltech.edu, linux-doc@vger.kernel.org, Mark Brown <broonie@kernel.org>, philip@balister.org, rubini@gnudd.com, Steffen Trumtrar <s.trumtrar@pengutronix.de>, jason@lakedaemon.net, kyle.teske@ni.com, nico@linaro.org, Felipe Balbi <balbi@ti.com>, m.chehab@samsung.com, davidb@codeaurora.org, Rob Landley <rob@landley.net>, davem@davemloft.net, cesarb@cesarb.net, sameo@linux.intel.com, Andrew Morton <akpm@linux-foundation.org>, Linus Walleij <linus.walleij@linaro.org>, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, devel@driverdev.osuosl.org, Alan Tull <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, 21 Jan 2015 18:33:12 +0200 [thread overview] Message-ID: <D466D9FF-25DA-4765-9469-128733BEBC4D@konsulko.com> (raw) In-Reply-To: <20150121160151.453ba403@lxorguk.ukuu.org.uk> Hi Alan, > On Jan 21, 2015, at 18:01 , One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: > > On Thu, 15 Jan 2015 22:54:46 +0200 > Pantelis Antoniou <pantelis.antoniou@konsulko.com> wrote: > >> Hi Alan, >> >>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: >>> >>> On Thu, 15 Jan 2015 11:47:26 -0700 >>> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote: >>>> It is a novel idea, my concern would be that embedding the FPGA in the >>>> DT makes it permanent unswappable kernel memory. >>>> Not having the kernel hold the FPGA is best for many uses. >>> >>> If you have a filesysytem before the FPGA is set up then it belongs in >>> the file system. As you presumably loaded the kernel from somewhere there >>> ought to be a file system (even an initrd). >>> >> >> Request firmware does not imply keeping it around. You can always re-request >> when reloading (although there’s a nasty big of caching that needs to be >> resolved with the firmware loader). > > Which comes down to the same thing. Unless you can prove that there is a > path to recover the firmware file that does not have any dependancies > upon the firmware executing (and those can be subtle and horrid at times) > you need to keep it around for suspend/resume at least and potentially > any unexpected error/reset. > In that case the only safe place to put it is in the kernel image itself, which is something the firmware loader already supports. >> One of the ideas rolling about is to put the device tree overlay blob in >> an EEPROM and then load it from there (not from the filesystem). > > That's a fine example of one you can probably always get to and avoid > caching. However if its in eeprom you don't need request_firmware anyway ! > Sure, I never said that request_firmware is the only way to get hold of a blob. It just happens to be the most convenient one for the kernel (when the blob resides somewhere on a filesystem). >> Can we please not use ioctls if possible. Configfs seems to work just fine >> for configuration and for any other higher speed API we should use read/write/mmap. > > You don't have the needed state in configfs as far as I can see. > Sure, but there’s no reason for it not to be there. >> Ioctls are a pain for scripting and interpreted languages usually. > > You can do ioctls in perl just fine if you are mad (and if you are > using perl you are ;-) ) while python has a complete explicit fcntl.ioctl > model. > Sure, it can be made to work, but it is a pain. >> Making the API handle partial reconfiguration from day one might be pushing tricky. >> I don’t remember any case where I came across a need for it. > > Agreed - I don't see the point in adding it until someone needs it and can > describe what is needed accurately. > /me nods. > Alan Regards — Pantelis
WARNING: multiple messages have this Message-ID (diff)
From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> To: One Thousand Gnomes <gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>, atull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, Pavel Machek <pavel-ynQEQJNshbs@public.gmane.org>, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org>, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>, Randy Dunlap <rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, iws-lulEs6mt1IksTUYHLfqkUA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, philip-6RQC9ztksjxg9hUCZPvPmw@public.gmane.org, rubini-kaDoWcXyVrEAvxtiuMwx3w@public.gmane.org, Steffen Trumtrar <s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org, kyle.teske-acOepvfBmUk@public.gmane.org, nico-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>, m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, davidb-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org, sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>Lin Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document Date: Wed, 21 Jan 2015 18:33:12 +0200 [thread overview] Message-ID: <D466D9FF-25DA-4765-9469-128733BEBC4D@konsulko.com> (raw) In-Reply-To: <20150121160151.453ba403-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> Hi Alan, > On Jan 21, 2015, at 18:01 , One Thousand Gnomes <gnomes-qBU/x9rampVWwHNkJWuZSg@public.gmane.orgorg.uk> wrote: > > On Thu, 15 Jan 2015 22:54:46 +0200 > Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote: > >> Hi Alan, >> >>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes <gnomes-qBU/x9rampWTnxY3oEoUhg@public.gmane.orgu.org.uk> wrote: >>> >>> On Thu, 15 Jan 2015 11:47:26 -0700 >>> Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote: >>>> It is a novel idea, my concern would be that embedding the FPGA in the >>>> DT makes it permanent unswappable kernel memory. >>>> Not having the kernel hold the FPGA is best for many uses. >>> >>> If you have a filesysytem before the FPGA is set up then it belongs in >>> the file system. As you presumably loaded the kernel from somewhere there >>> ought to be a file system (even an initrd). >>> >> >> Request firmware does not imply keeping it around. You can always re-request >> when reloading (although there’s a nasty big of caching that needs to be >> resolved with the firmware loader). > > Which comes down to the same thing. Unless you can prove that there is a > path to recover the firmware file that does not have any dependancies > upon the firmware executing (and those can be subtle and horrid at times) > you need to keep it around for suspend/resume at least and potentially > any unexpected error/reset. > In that case the only safe place to put it is in the kernel image itself, which is something the firmware loader already supports. >> One of the ideas rolling about is to put the device tree overlay blob in >> an EEPROM and then load it from there (not from the filesystem). > > That's a fine example of one you can probably always get to and avoid > caching. However if its in eeprom you don't need request_firmware anyway ! > Sure, I never said that request_firmware is the only way to get hold of a blob. It just happens to be the most convenient one for the kernel (when the blob resides somewhere on a filesystem). >> Can we please not use ioctls if possible. Configfs seems to work just fine >> for configuration and for any other higher speed API we should use read/write/mmap. > > You don't have the needed state in configfs as far as I can see. > Sure, but there’s no reason for it not to be there. >> Ioctls are a pain for scripting and interpreted languages usually. > > You can do ioctls in perl just fine if you are mad (and if you are > using perl you are ;-) ) while python has a complete explicit fcntl.ioctl > model. > Sure, it can be made to work, but it is a pain. >> Making the API handle partial reconfiguration from day one might be pushing tricky. >> I don’t remember any case where I came across a need for it. > > Agreed - I don't see the point in adding it until someone needs it and can > describe what is needed accurately. > /me nods. > Alan Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-01-21 16:33 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 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 [this message] 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=D466D9FF-25DA-4765-9469-128733BEBC4D@konsulko.com \ --to=pantelis.antoniou@konsulko.com \ --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=gnomes@lxorguk.ukuu.org.uk \ --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=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.