From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752119AbdLFQ2t (ORCPT ); Wed, 6 Dec 2017 11:28:49 -0500 Received: from smtp-out6.electric.net ([192.162.217.186]:51219 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751500AbdLFQ2r (ORCPT ); Wed, 6 Dec 2017 11:28:47 -0500 From: David Laight To: "'Alan Tull'" CC: Wu Hao , "mdf@kernel.org" , "linux-fpga@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "luwei.kang@intel.com" , "yi.z.zhang@intel.com" , Tim Whisonant , "Enno Luebbers" , Shiva Rao , Christopher Rauer , Xiao Guangrong Subject: RE: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device Thread-Topic: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device Thread-Index: AQHTZ0zlT9aHswbrXkGWaDG3vrBCQaMoBU+ggA3ViiqAAEPYIIAAYL4AgAAKYJA= Date: Wed, 6 Dec 2017 16:28:55 +0000 Message-ID: References: <1511764948-20972-1-git-send-email-hao.wu@intel.com> <1511764948-20972-9-git-send-email-hao.wu@intel.com> <20171128031519.GA25705@hao-dev> <20171205033330.GA19730@hao-dev> <20171206053015.GA19023@hao-dev> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.33] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuMS.aculab.com X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vB6GSq8v004217 From: Alan Tull > Sent: 06 December 2017 15:30 > On Wed, Dec 6, 2017 at 3:44 AM, David Laight wrote: > > From: Wu Hao > >> Sent: 06 December 2017 05:30 > > ... > >> > Regarding file names, it seems like the files added to drivers/fpga > >> > could be uniformly named dfl-*.[ch]. Some are fpga-dfl-*.[ch] while > >> > other are currently dfl-*.[ch] currently. > > > > They don't even want to do into a drivers/fgpa directory. > > Maybe drivers/dfl or drivers/dfl/intel > > It's plugged into the fpga framework in drivers/fpga. This patchset > also handles reprogramming the fpga, not just the dfl style > enumeration. But your points about this being not just for FPGA are > interesting to me. Do you have a use for this that isn't > FPGA-centric? That all just seems wrong to me. If you've managed to invent some common code for reprogramming fpga I'd have though it would be library functions. The driver ought to sit somewhere related to its functionality. Our fpga loads from a serial EEPROM, the image is about 6.5MB. We can rewrite it from userspace by mmap()ing part of one of the BARs to access some very locally written (by me) VHDL that does most of the required bit-banging for 32it word accesses. You really wouldn't want to load 6.5MB into kernel space! We also had to solve the problem of 9 separate driver modules that want to access different parts of the BARs. I think we have 46 separate slaves in the fpgas BARs (most are in 1 BAR). Some of these are common between different boards (or completely different memory maps for the same board. I can imagine some generic method of having a 'board' driver for a specific PCI-id that knows the BAR offsets of various functions so that other sub-drivers could be loaded to access those functions. But that is some kind of pseudo-bus not fpga specific in any way. David