> >> 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
