lkml.org 
[lkml]   [2015]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v8 2/4] fpga manager: add sysfs interface document
    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


    \
     
     \ /
      Last update: 2015-02-16 00:01    [W:2.324 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site