From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pantelis Antoniou Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document Date: Wed, 21 Jan 2015 22:32:23 +0200 Message-ID: <7E60D554-8660-4CDB-BF68-D39DD29039BE@konsulko.com> References: <20150113162847.2778b5a5@lxorguk.ukuu.org.uk> <20150113200032.GA16205@obsidianresearch.com> <20150113222450.GA17475@obsidianresearch.com> <20150115184726.GA23247@obsidianresearch.com> <20150115204502.591bca1d@lxorguk.ukuu.org.uk> <20150121160151.453ba403@lxorguk.ukuu.org.uk> <20150121202700.GB4942@obsidianresearch.com> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150121202700.GB4942@obsidianresearch.com> Sender: linux-doc-owner@vger.kernel.org To: Jason Gunthorpe Cc: One Thousand Gnomes , atull , Greg Kroah-Hartman , Pavel Machek , hpa@zytor.com, Michal Simek , Michal Simek , Randy Dunlap , Linux Kernel Mailing List , devicetree@vger.kernel.org, robh+dt@kernel.org, Grant Likely , iws@ovro.caltech.edu, linux-doc@vger.kernel.org, Mark Brown , philip@balister.org, rubini@gnudd.com, Steffen Trumtrar , jason@lakedaemon.net, kyle.teske@ni.com, nico@linaro.org, Felipe Balbi , m.chehab@samsung.com, davidb@codeaurora.org, Rob Landley , davem@davemloft.net, cesarb@cesarb.net, sameo@linux.intel.com, Andrew Morton Linu List-Id: devicetree@vger.kernel.org Hi Jason, > On Jan 21, 2015, at 22:27 , Jason Gunthorpe wrote: >=20 > On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote: >> Hi Alan, >>=20 >>> On Jan 21, 2015, at 18:01 , One Thousand Gnomes wrote: >>>=20 >>> On Thu, 15 Jan 2015 22:54:46 +0200 >>> Pantelis Antoniou wrote: >>>=20 >>>> Hi Alan, >>>>=20 >>>>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes wrote: >>>>>=20 >>>>> On Thu, 15 Jan 2015 11:47:26 -0700 >>>>> Jason Gunthorpe 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. >>>>>=20 >>>>> If you have a filesysytem before the FPGA is set up then it belon= gs in >>>>> the file system. As you presumably loaded the kernel from somewhe= re there >>>>> ought to be a file system (even an initrd). >>>>>=20 >>>>=20 >>>> Request firmware does not imply keeping it around. You can always = re-request >>>> when reloading (although there=E2=80=99s a nasty big of caching th= at needs to be >>>> resolved with the firmware loader). >>>=20 >>> 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 dependanci= es >>> 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 potentia= lly >>> any unexpected error/reset. >>>=20 >>=20 >> In that case the only safe place to put it is in the kernel image it= self, which >> is something the firmware loader already supports. >=20 > My point is that the current firmware layer is overly cautious and > FPGAs are very big. My current project on small Xilinx device has a > 10MB programming file. The biggest Xilinx device today has a max > bitfile size around 122MB. >=20 > So keeping that much memory pinned in the kernel when I can prove it > is uncessary for my system (either because there is no suspend/resume > possibility, or because I know the CPU can always access the > filesytem) is very undesirable. >=20 > Other systems might have to take the ram hit. >=20 > Since it seems like the kernel has no way to know, we probably have > have a way to tell it not to cache the bitfile. >=20 The firmware loader was not originally meant to handle these cases, but I=E2=80=99m sure it=E2=80=99s not an insurmountable obstacle. > Jason Regards =E2=80=94 Pantelis