Date:	Thu, 15 Jan 2015 22:54:46 +0200
From:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	atull <atull@...nsource.altera.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Pavel Machek <pavel@...x.de>, hpa@...or.com,
	Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>, rdunlap@...radead.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	devicetree@...r.kernel.org, robh+dt@...nel.org,
	Grant Likely <grant.likely@...aro.org>, iws@...o.caltech.edu,
	linux-doc@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	philip@...ister.org, rubini@...dd.com,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	jason@...edaemon.net, kyle.teske@...com, nico@...aro.org,
	Felipe Balbi <balbi@...com>, m.chehab@...sung.com,
	davidb@...eaurora.org, Rob Landley <rob@...dley.net>,
	davem@...emloft.net, cesarb@...arb.net, sameo@...ux.intel.com,
	akpm@...ux-foundation.org,
	Linus Walleij <linus.walleij@...aro.org>, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, devel@...verdev.osuosl.org,
	Alan Tull <delicious.quinoa@...il.com>,
	dinguyen@...nsource.altera.com, yvanderv@...nsource.altera.com
Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

Hi Alan,

> On Jan 15, 2015, at 22:45 , One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> 
> On Thu, 15 Jan 2015 11:47:26 -0700
> Jason Gunthorpe <jgunthorpe@...idianresearch.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).

>> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists