Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754311AbdDFT2e (ORCPT ); Thu, 6 Apr 2017 15:28:34 -0400 Received: from mail.kernel.org ([198.145.29.136]:35712 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752592AbdDFT20 (ORCPT ); Thu, 6 Apr 2017 15:28:26 -0400 MIME-Version: 1.0 In-Reply-To: <20170406105758.GA15513@hao-dev> 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> <20170406105758.GA15513@hao-dev> From: Alan Tull Date: Thu, 6 Apr 2017 14:27:42 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support To: Wu Hao 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5835 Lines: 125 On Thu, Apr 6, 2017 at 5:57 AM, Wu Hao wrote: > On Wed, Apr 05, 2017 at 10:39:05AM -0500, Alan Tull wrote: >> On Wed, Apr 5, 2017 at 10:26 AM, Alan Tull wrote: >> > On Wed, Apr 5, 2017 at 6:40 AM, Wu, Hao wrote: >> >>> >> 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. >> > >> > I'm trying to avoid driver specific ways of doing things. Think of this >> > all as a set of blocks and we want to be able to switch out individual >> > blocks in the future. It's future-proofing and also making code more >> > generally usable. >> > >> > fpga_mgr_info is part of the interface for calls to fpga-mgr to do >> > reprogramming. My patchset will push it further in that direction >> > as pointers to the image are added to fpga_mgr_info. >> > >> > Adding 'priv' to fpga_mgr_info makes that interface specific to a this driver. >> > It's better to add a region_id variable to fpga_mgr_info that may not be used by >> > all fpga-mgr drivers. The current model is that a fpga-mgr driver checks >> > fpga_mgr_info flags to see if its correct. The fpga-mgr driver can check >> > any other needed fpga_mgr_info variables and return error if the params >> > look invalid. And ignore any it doesn't need. >> > >> > I don't think priv belongs in fpga_image_info. priv tends to be information >> > for a specific instance of a driver that can have several instances. priv >> > usually stores a driver's memory mappings, interrupts, etc for that instance. >> > It's called private info as it is info that other blocks don't need to know >> > and don't get to look at. It's private. So priv as in interface strikes me as >> > not private any more and is sort of a red flag. > > Thanks a lot for the details. It's more clear to me now. :) > >> > >> > Alan >> >> Besides that, I see that region_id is needed both for the fme_pr and >> for determining which port to disable/enable. So adding it to the >> fpga_image_info would allow the fpga-region to figure out which >> bridge to control as well as pass it to the mgr. >> > > Do we need to add an 'id' to fpga-bridge too? You don't have to, but you could. See below. > > Per my understanding this FME driver should create fpga-region for each > accelerator, and make sure each fpga-region has correct region_id. When > this fpga-region wants to be programmed by fpga-mgr, then it add this > info to fpga_image_info, and fpga-mgr knows which region to program via > this fpga_image_info. The fpga_image_info is passed both to fpga-mgr and fpga-bridge. So both will get the region_id through the info. > > For each fpga-region, FME driver needs to create one fpga-bridge and link > it to region's bridge_list. When fpga_region_program_fpga is invoked for > PR. This fpga-bridge could be disabled before PR and re-enabled after PR > automatically. If fpga-bridge contains this 'id' information, then driver > knows which port to enable/disable to implement of the enable_set function > under this fpga-bridge. Could implement it either way: the bridge could either use the bridge_id that has been passed to it in the info or code that creates the bridge could create private data and pass it to fpga_bridge_register(). But the bridge will have the id because it will be passed in the info, so it's not really needed. Alan > > Thanks > Hao > >> > >> >> >> >> If you prefer the region_id for fpga_image_info, we can go with region_id >> >> for sure. : ) >> >> >> >> Thanks >> >> Hao