lkml.org 
[lkml]   [2015]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v8 2/4] fpga manager: add sysfs interface document
From
Date
Hi Jason,

> On Jan 21, 2015, at 22:27 , Jason Gunthorpe <jgunthorpe@obsidianresearch.com> 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.
>
> 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



\
 
 \ /
  Last update: 2015-01-21 21:41    [W:0.198 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site