Re: [PATCH 00/16] Intel FPGA Device Drivers

[Jerome Glisse]

On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote:
> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <jglisse@xxxxxxxxxx> wrote:
> 
> Hi Jerome,
> 
> > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
> >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
> >> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> >> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@xxxxxxxxxx> wrote:
> >> > >
> >> > > > It is like if on GPU we only had close source compiler for the GPU
> >> > > > instructions set. So FPGA is definitly following different rules than
> >> > > > open source upstream GPU kernel driver abides to.
> 
> Sorry, not a GPU guy, can you point me to something that documents
> this policy of 'only opensource compilers for GPU'?  I looked under
> linux/Documentation and didn't see anything.

https://lists.freedesktop.org/archives/dri-devel/2010-July/001828.html

There is no explicit mention about compiler but trust me it is included
in everyones mind. You can ask Dave i am sure he would reject a driver
with everything open except the shader compiler.


> The current patchset doesn't have anything to do with FPGA toolchains
> but you're using this patchset as a platform to talk about toolchain
> issues.

Well Intel inclusion of FPGA triggered my curiosity and when that patchset
came accross my inbox i did wonder where the open source userspace was and
went looking for it to no avail. So this isn't against a specific patchset
but more broadly against the whole drivers/fpga/ story. Sorry if this was
not clear.


> It sounds like you are opposed to any kernel support of loading images
> on FPGAs until all vendors have opensource toolchains.

Yes that is what i am saying. They are different standard in the kernel
and i would rather have one clear standard about driver needing proper
open source userspace to go along with any upstream driver.

Beside when it comes to FPGA i am still puzzle on why no one release info
on the bitstream. They all provide details documentation on the internal
(LUT, flip-flop, logic block layout and connection, memory block, ...).
So there is nothing hidden in the bitstream. I am guessing the only good
reason i can think of is to make it harder to map a bitstream back to
VHDL/Verilog/...

Cheers,
Jérôme