Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753900AbdDQRPL (ORCPT ); Mon, 17 Apr 2017 13:15:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39952 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752107AbdDQRPJ (ORCPT ); Mon, 17 Apr 2017 13:15:09 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4AA53C0567B5 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jglisse@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4AA53C0567B5 Date: Mon, 17 Apr 2017 13:15:06 -0400 From: Jerome Glisse To: Alan Tull Cc: "Luebbers, Enno" , Moritz Fischer , Wu Hao , linux-fpga@vger.kernel.org, Linux Kernel Mailing List , "Kang, Luwei" , "Zhang, Yi Z" Subject: Re: [PATCH 00/16] Intel FPGA Device Drivers Message-ID: <20170417171504.GA5632@redhat.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 17 Apr 2017 17:15:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4765 Lines: 100 On Mon, Apr 17, 2017 at 11:22:08AM -0500, Alan Tull wrote: > 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. You are mixing thing. I say no driver without open source userspace. For GPU this means something like a mesa driver and mesa driver include a compiler but not in the form you expect (it is does not provide what i would call a toolchain). But it can be something else. It could be a standalone opencl implementation with what we call a finalizer (ie something that goes from some intermediate representation down to the hardare ISA). So if you go look back at new driver submission like Adreno or Vivante. They provided link to the open source driver they submited to mesa along their kernel patchset posting. For FPGA this would mean a tool that can map something like VHDL,Verilog or even something lower level like a list of lut equation with a netlist between them (and flip-flop and other blocks). So mapping this down to the bitstream. It is call a toolchain for FPGA so that's the word i did use. > >> 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. I am not saying let delete this. Ok it is there, i dislike that fact, but it is there. I am asking: is this allowed for FPGA ? If so why ? Do everyone understand the risks of accepting this ? ... Now if community believe that we should only accept kernel code with open source userspace bits then community can say no more changes to drivers/fpga until you have said open source bits. That would send a clear signal. Silently accepting drivers/fpga/ with no clear rules leave everyone in the dark. People that wish to see only driver with open source userspace knows that company will be happy to stay in this status quo and won't do anything toward open source. Thinking differently would be utterly naive. A company will not do something unless there is a clear incentive to do so. Cheers, J?r?me