Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

[Pavel Machek <pavel@denx.de>]

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 <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.
> 
> 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