From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753962AbdDQQWz convert rfc822-to-8bit (ORCPT ); Mon, 17 Apr 2017 12:22:55 -0400 Received: from mail.kernel.org ([198.145.29.136]:44364 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753381AbdDQQWx (ORCPT ); Mon, 17 Apr 2017 12:22:53 -0400 MIME-Version: 1.0 In-Reply-To: <20170417155723.GA4547@redhat.com> References: <1490875696-15145-1-git-send-email-hao.wu@intel.com> <20170406202700.GA3674@redhat.com> <20170411193806.GA33858@eluebber-mac02.jf.intel.com> <20170412132919.GA16072@redhat.com> <20170412153746.GA17158@redhat.com> <20170414194817.GA27424@eluebber-mac02.jf.intel.com> <20170414204955.GA4805@redhat.com> <20170417155723.GA4547@redhat.com> From: Alan Tull Date: Mon, 17 Apr 2017 11:22:08 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/16] Intel FPGA Device Drivers To: Jerome Glisse Cc: "Luebbers, Enno" , Moritz Fischer , Wu Hao , linux-fpga@vger.kernel.org, Linux Kernel Mailing List , "Kang, Luwei" , "Zhang, Yi Z" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse wrote: > 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. > > https://lists.freedesktop.org/archives/dri-devel/2010-July/001828.html This starts out saying: "Now this is just my opinion as maintainer of the drm, and doesn't reflect anyone or any official policy" > There is no explicit mention about compiler You are right about that, there is no 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. How would that work? Before the GPU driver is accepted, an open toolchain also needs to be submitted? It's worth it to check out the responses since they not overwhelmingly positive and tend to rather be outlining the complicating factors. Many if not most say essentially that his stance was simplistic and unproductive, slamming the door on the people from whom the solution would come. And keep in mind, this wasn't about what you've made it out to be in the first place; this is about open/closed source GPU drivers, not toolchains. > > >> 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. Deleting drivers/fpga wouldn't be a step forward to the openness you seek. > > 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