Message-ID: <alpine.DEB.2.02.1501131336220.29145@linuxheads99>
Date:	Tue, 13 Jan 2015 13:44:01 -0600
From:	atull <atull@...nsource.altera.com>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
CC:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Pavel Machek <pavel@...x.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<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

On Tue, 13 Jan 2015, Pantelis Antoniou wrote:

> Hi Alan,
> 
> > On Jan 13, 2015, at 18:28 , One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> > 
> > On Mon, 12 Jan 2015 14:43:14 -0700
> > Jason Gunthorpe <jgunthorpe@...idianresearch.com> wrote:
> > 
> >> On Mon, Jan 12, 2015 at 09:01:34PM +0000, One Thousand Gnomes wrote:
> >>> There are plenty of people today who treat the FPGA as an entirely
> >>> dynamic resource. It's not like flashing a controller, its near
> >>> immediate.
> >> 
> >> But this is a completely different use case. Remember, there are
> >> *megabytes* of internal state in a FPGA, and it isn't really feasible
> >> to dump/restore that state.
> > 
> > People already do it with cases where it makes sense
> > 
> 
> Those people have failed to show up and provide input and/or code.
> 
> >> It is one thing to context switch a maths algorithm that is built to
> >> be stateless, it is quite another to context switch between, say an
> >> ethernet core with an operating Linux Net driver doing DMA and a maths
> >> algorithm.
> > 
> > And people already do it with thins like maths algorithms.
> > 
> 
> Again those people have failed to show up and provide input and/or code.
> 
> >> A DT overlay approach where the overlay has to be unloaded to 'free'
> >> the FPGA makes alot of sense to me for the stateful kernel driver
> >> environment, and open/close/etc makes alot of sense for the stateless
> >> switchable userspace environment - other than sharing configuration
> >> code, is there any overlap between these use cases????
> > 
> > There is a lot of code overlap in things like loading the bitstreams,
> > there is also some overlap because you want to be able to assign FPGA
> > resources. For example if you have four FPGAs and you want to use one for
> > OS stuff (say video) you want the other three to be open/close
> > accessible, but if you've not got a video driver loaded and are running
> > the same board headless you'd like all four to be handed out as normal
> > resources.
> > 
> > So IMHO it's no different to say kmalloc. We don't pre-empt kernel memory
> > and give it to users but we don't reserve memory for kernel and not use
> > it.
> > 
> >>> Its completely dynamic and it will get more so as we switch from the
> >>> painful world of VHDL and friends to high level parallel aware language
> >>> compilers for FPGAs and everyone will be knocking up quick FPGA hacks.
> >> 
> >> Only for some users. In my world FPGAs are filled with bus interface
> >> logic, ethernet controllers, memory controllers, packet processing
> >> engines, etc. This is all incredibly stateful - both in the FPGA
> >> itself, and in the Linux side w/ drviers. It certainly will not ever
> >> work in the model you are talking about.
> > 
> > For those cases I mostly agree (the state in the FPGA isn't always a
> > problem as you can program an FPGA to DMA its state out).
> > 
> >> Even if the digital state could somehow be frozen, dumped and
> >> restored, all the FPGA external interface logic has *ANALOG* state
> >> that cannot ever be dump/restored. It just isn't feasible for that
> >> class of application.
> > 
> > Yes, however as we are starting to get things like OpenCL for FPGA they
> > become extremely attractive for a wide range of purposes that don't
> > involve glueing them to electronica in quite the same way. All the 'GPU
> > as CPU' type uses and more begin to apply.
> > 
> 
> Your points are valid, but they are mostly academic right now.
> 
> We have a lot of well known use cases that this patchset addresses
> satisfactorily. The possible users of the cases you point out are 
> welcome to provide input and working code to address their needs.
> 
> At this point in time, no-one has showed up; is there a reason for
> this needed capability to be delayed in order to address something
> that no-one has expressed interest for?
> 
> > Alan
> > —
> 
> Regards
> 
> — Pantelis
> 
> 

There has been a lot of discussion in the past.  It is possible that
some of the use models are conflicting, but that doesn't really mean
that one model is more valid and needs to be the
winner that determines the only valid way to use FPGAs under Linux.

I like the dynamic usage model and the DT overlays model both.  It
is likely that both will be added and used.

This set of patches gets something started.  The sysfs interface
is built on a set of functions that can be used to build other
interfaces.  An earlier set of patches included DT overlay support,
but I've taken that out for the moment.  It's going into
drivers/staging so that we can use it and grow it.

Alan

Powered by blists - more mailing lists