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. > > 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. > >> >> If you prefer the region_id for fpga_image_info, we can go with region_id >> for sure. : ) >> >> Thanks >> Hao
