[lkml]   [2017]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 00/16] Intel FPGA Device Drivers
On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote:
> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <> 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 <> 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.

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


 \ /
  Last update: 2017-04-17 17:57    [W:0.193 / U:0.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site