Hi Jason, > On Jan 21, 2015, at 22:27 , Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> wrote: >>> >>> On Thu, 15 Jan 2015 22:54:46 +0200 >>> Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> wrote: >>> >>>> Hi Alan, >>>> >>>>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: >>>>> >>>>> On Thu, 15 Jan 2015 11:47:26 -0700 >>>>> Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> 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. > > Other systems might have to take the ram hit. > > 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. > The firmware loader was not originally meant to handle these cases, but I’m sure it’s not an insurmountable obstacle. > Jason Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
