From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933875AbdDELkN (ORCPT ); Wed, 5 Apr 2017 07:40:13 -0400 Received: from mga06.intel.com ([134.134.136.31]:20077 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933452AbdDELkL (ORCPT ); Wed, 5 Apr 2017 07:40:11 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,278,1486454400"; d="scan'208";a="83425252" From: "Wu, Hao" To: Alan Tull CC: Moritz Fischer , "linux-fpga@vger.kernel.org" , linux-kernel , "Kang, Luwei" , "Zhang, Yi Z" , "Whisonant, Tim" , "Luebbers, Enno" , "Rao, Shiva" , "Rauer, Christopher" , "Tull, Alan" , Xiao Guangrong Subject: RE: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support Thread-Topic: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support Thread-Index: AQHSqU9tFdGDtuaQHkCwuwcoS0kCaqGuzBwAgAcJyseAANTO4A== Date: Wed, 5 Apr 2017 11:40:05 +0000 Message-ID: References: <1490875696-15145-1-git-send-email-hao.wu@intel.com> <1490875696-15145-12-git-send-email-hao.wu@intel.com> <20170401110803.GA4804@hao-dev> <20170404060516.GD13968@hao-dev> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 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 mail.home.local id v35Beutd028778 > >> The fpga_image_info struct started life as just image specific info, > >> but I want it to go in the direction of including parameters needed to > >> program it this specific time. Otherwise we are stuck having to keep > >> adding parameters as our use of FPGA develops. It probably could be > >> documented better as 'information needed to program a FPGA image' > >> rather than strictly 'information about this particular FPGA image'. > >> My patch "fpga-mgr: pass parameters for loading fpga in image info" > >> goes in this direction by having the buf, firmware name, or sg list > >> passed in the info for the added fpga_mgr_load() function. Actually I > >> should probably simplify the API and get rid of fpga_mgr_buf_load, > >> fpga_mgr_buf_load_sg, and fpga_mgr_firmware_load and require people to > >> use fpga_mgr_load (passing all parameters in fpga_image_info). > >> > > > > Make sense. > > > >> > It may be a > >> > little confusing. One rough idea is that keep this info under fpga region > >> > (maybe its private data), and pass the fpga-region to fpga_mgr_buf_load, > >> > >> Yes, keep this info in fpga-region. When the region wants to program > >> using fpga-mgr, add the region id to fpga_image_info. I propose > >> calling it region_id. > > > > Hm.. Do we need a function which moves info from region to image info? > > No, just code that sets that variable in the struct before calling the > fpga_region_program_fpga function. > > > > > Another idea is, add a priv to fpga_image_info, and use a common function > > to pass the fpga_region's priv to fpga_image_info's priv before PR. > > fpga-mgr then knows fpga_region priv info from the fpga_image_info. > > > > Adding priv would make the interface for fpga-mgr non-uniform. The point > of having a fpga-mgr framework is that there > is the potential of the upper layers working for different FPGA devices. > If the interface for each FPGA device were different, that would then > be broken. > I mean drivers can register their own fpga-mgr ops, and handle priv of fpga_image_info in driver specific way for pr (e.g write_init function). We don't need to change the any upper layer interfaces. If you prefer the region_id for fpga_image_info, we can go with region_id for sure. : ) Thanks Hao