On Thu, Apr 06, 2017 at 02:27:42PM -0500, Alan Tull wrote: > On Thu, Apr 6, 2017 at 5:57 AM, Wu Hao <hao...@intel.com> 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 <at...@kernel.org> wrote: > >> > On Wed, Apr 5, 2017 at 6:40 AM, Wu, Hao <hao...@intel.com> 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.
Thanks for the suggestion. :) The reason I was considering adding id to fpga_bridge is, in the case driver creates all bridges (and regions/manager) in the initialization code, but at that time, nobody knows the actual fpga_image_info. In order to pass fpga_image_info to the bridges of give region during PR (e.g in fpga_region_program_fpga function), then driver must implement region->get_bridges function, but I feel we may not need get_bridges function for this case, as all bridges have already been linked to fpga-region during initialization. So I prefer the second method that keep this id in the private data. :) Thanks Hao > > Alan > > > > > Thanks > > Hao > > > >> > > >> >> > >> >> If you prefer the region_id for fpga_image_info, we can go with > >> >> region_id > >> >> for sure. : ) > >> >> > >> >> Thanks > >> >> Hao > -- > To unsubscribe from this list: send the line "unsubscribe linux-fpga" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
