On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote: > On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <jgli...@redhat.com> 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 <jgli...@redhat.com> > >> > > 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