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

[Pantelis Antoniou]

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

>> Having the kernel hold the FPGA as a swppable file handle/mmap of some
>> sort is next best (obviously the fs must be operating during resume)
> 
> For a lot of hardware that gets somewhat hairy because you don't know
> what the dependancies between devices are on the resume but yes.
> 
>> Unswappable kernel memory is the worst choice
> 
> There is another case here - which is where the firmware is somewhere
> else physically. For example in PCI ROM space, or flash, but designed to
> be loaded by the OS.
> 
> 

One of the ideas rolling about is to put the device tree overlay blob in
an EEPROM and then load it from there (not from the filesystem).

>> I think to justify the ioctls you need a reason to have the context
>> of a FD. sysfs is stateless, so if my process dies the kernel doesn't
>> know.
> 
> That isn't to say the stateless information doesn't belong in sysfs. Eg
> you don't neccessarily want to open the device node and go through ioctls
> just for bits of information that are interesting to reporting tools.
> 
> (Imagine an 'lsfpga' tool for the kind of things you'd leave in sysfs)
> 
>> Identifying the ioctls needed would probably clarify things. My
>> rough start would be 
>> 
>> - Get status: programed, not programmed, error?
>>  Bitfile type? (eg Xilinx has nearly every permutation of bit/byte
>>  ordering)
> 
> That's probably some kind of "what are you" ioctl that returns the
> vendor/type information.
> 

Can we please not use ioctls if possible. Configfs seems to work just fine
for configuration and for any other higher speed API we should use read/write/mmap.

Ioctls are a pain for scripting and interpreted languages usually.

>> - Hand over to a DT overlay (how does this work?) Lock transfers
>>  from FD to kernel
> 
> That bit isn't stateful so I would actually have expected something in
> the kernel ABI along the lines of 
> 
>           request_fpga(blah)
> 
> which does
> 
>             if in use by user
>                    EBUSY
>             lock it (all user opens will fail)
> 
> and
> 
>            release_fpga(blah)
> 
> and a sysfs node indicating its busy (and perhaps also what for if the
> request_fpga passes a textual name)
> 
>> Not sure about partial reconfiguration - clearly the kernel needs to
>> know and check that the bitfiles are of the correct family, I wonder
>> if the approach should be to program a basis on the FPGA which then
>> creates a new FPGA device in the system that can accept the partial
>> reconfiguration - this way the locking makes sense, the basis is
>> locked by the kernel and devices and the overlay remains
>> lockable/swappable/whatever by a dedicated /dev/ node ??
> 
> I think so.
> 
> If you closed the device you have no idea what happened between the close
> and a re-open, therefore you have no idea what the FPGA state is.
> 
>> Just thinking aloud, I've never had a use case for partial
>> reconfiguration.
> 
> The API handles it but whether it needs to be there from day one I don't
> know.
> 

Making the API handle partial reconfiguration from day one might be pushing tricky.
I donât remember any case where I came across a need for it.

We could do with a virtual FPGA topology; have a root FPGA thatâs keeping the
common unchanged bits and another thatâs keeping the bits that do change.

Dunno how nice it would be in practice though.

> Alan
> 

Regards

â Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/