Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755276AbbBOWkO (ORCPT ); Sun, 15 Feb 2015 17:40:14 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:33225 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752760AbbBOWkL (ORCPT ); Sun, 15 Feb 2015 17:40:11 -0500 Date: Sun, 15 Feb 2015 23:40:06 +0100 From: Pavel Machek To: Jason Gunthorpe Cc: Pantelis Antoniou , One Thousand Gnomes , atull , Greg Kroah-Hartman , 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 , Linus Walleij , pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, devel@driverdev.osuosl.org, Alan Tull , dinguyen@opensource.altera.com, yvanderv@opensource.altera.com Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document Message-ID: <20150215224006.GA5626@amd> References: <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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150121202700.GB4942@obsidianresearch.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2803 Lines: 63 On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote: > On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote: > > Hi Alan, > > > > > On Jan 21, 2015, at 18:01 , One Thousand Gnomes wrote: > > > > > > On Thu, 15 Jan 2015 22:54:46 +0200 > > > Pantelis Antoniou wrote: > > > > > >> Hi Alan, > > >> > > >>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes wrote: > > >>> > > >>> 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. > > >>> > > >>> 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. > > 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. > > 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. Well, your current device aalso has 1GB RAM, no? > Other systems might have to take the ram hit. I'd say the general case is "store bitstream in RAM" we can add optimalizations later. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/